https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005
--- Comment #17 from Alejandro Colomar <alx at kernel dot org> --- (In reply to Jakub Jelinek from comment #15) > I think the current behavior is correct, noipa implies the function boundary > is an optimization barrier for the compiler, while inline is the exact > opposite of that, and we do have warnings for incompatible attributes, which > is the case here. Not really. '[[gnu::noipa]]' implies an optimization barrier for the compiler, as you say. However, (C99) 'inline' has a different meaning, which I'll describe below: """ Allow me to write a function definition in a header. If you, mighty compiler, decide that you want to use that information for extra optimization or diagnostics, please go ahead, unless some attributes tell you not to do it. """ And I use it in this case for a meaning compatible with that: All the function bodies are written in header files in my library. The .c files are just bureaucracy 'extern inline'. When compiling my library, the functions are 'inline', so that I ask the compiler to give me as many optimizations and diagnostics as the compiler feels like. When the library headers are installed and a user compiles against them, the '[[gnu::noipa]]' attribute is enabled (via #ifdef), asking the compiler to not go crazy about seeing the function bodies in a header, but please don't optimize, not create a symbol for the function definition. Please reconsider.
