4 ms·

That's an interesting note. I wonder why they claim this. As far as I know, `[[gnu::optimize("-fno-tree-loop-distribute-patterns")]]` (or the equivalent #pragma

That's an interesting note. I wonder why they claim this. As far as I know, `[[gnu::optimize("-fno-tree-loop-distribute-patterns")]]` (or the equivalent #pragma) is required for implementing a memcpy function in C unless you do something funky with the build system.

leni536 2y ago
Maybe that's applied to the TU that defines it? I don't see it in the glibc sources.
- anarazel 2y ago
  It's indeed used: Definition of macro: https://sourceware.org/git/?p=glibc.git;a=blob;f=include/libc-symbols.h;h=4367aa6740bff6fc6b42b562f5d9a95b6690bc50;hb=HEAD#l808 https://sourceware.org/git/?p=glibc.git;a=blob;f=include/lib... Use: https://sourceware.org/git/?p=glibc.git;a=blob;f=string/memmove.c;h=3fad5f11acdf5d8a5ae1436c1e577f050c5d5193;hb=HEAD#l42 https://sourceware.org/git/?p=glibc.git;a=blob;f=string/memm... For a bunch of other places -fno-builtin-* seems to be used.
  - leni536 2y ago
    My guess is that the attribute interacts weirdly with optimizations spanning function calls, like inlining. It might be safe for TUs that define a single function, like with memmove above. Having said that applying the option to the TU itself would be equivalent, and not discouraged by GCC docs.
pertymcpert 2y ago
Because these optimizations are not supposed to be a part of the user interface. They're internal passes and may one day go away or be merged or subsumed etc.
cozzyd 2y ago
As far as I can tell it's due to some bugs