https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
--- Comment #7 from David Brown <david at westcontrol dot com> --- (In reply to rguent...@suse.de from comment #6) > > Am 28.06.2022 um 14:53 schrieb david at westcontrol dot com > > <gcc-bugzi...@gcc.gnu.org>: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279 > > > > --- Comment #5 from David Brown <david at westcontrol dot com> --- > > (In reply to Richard Biener from comment #4) > >> (In reply to frankhb1989 from comment #3) > >>> There is a more specific instance here: can_inline_edge_by_limits_p in > >>> ipa-inline.cc treats flags and "optimize" attributes differently. > >> > >> A bit up there's a blacklist we maintain where inlining is not OK because > >> it > >> results in semantic differences. > >> > >> Generally we it's hard to second-guess the users intention when looking > >> at an inline edge with different optimization settings of caller and > >> callee. > >> For C++ comdats there might be even multiple variants with different > >> optimization level (but we only keep one, special-casing this a bit). > > > > I appreciate the "err on the side of caution" attitude. Perhaps there > > could be > > an extra "I know what I'm doing" attribute that lets you override the > > blacklisting in a particular case. This would only really make sense in > > cases > > where the attribute can be attached to the expressions and statements within > > the function (I think "-fwrapv" would be in this category). In cases where > > this is not possible, an error or warning message would be in order as the > > compiler can't do what the programmer is asking. > > Can you provide a specific example that you would allow this way? > > I'd go back to my original example : __attribute__((optimize("-fwrapv"))) static inline int wrapped_add(int a, int b) { return a + b; } int foo(int x, int y, int z) { return wrapped_add(wrapped_add(x, y), z); } If you want to disable inlining of "wrapped_add" due to the change in the semantics of integer arithmetic, that's fair enough. But if I /really/ want inlining, and write something like : __attribute__((optimize("-fwrapv"), always_inline)) static inline int wrapped_add(int a, int b) { return a + b; } then I want the code treated as : return (__wrapping_int) a + (__wrapping_int) b; or return __wrapping_add_int(a, b); If the way gcc marks and handles "-fwrapv" arithmetic does not support something like that, which would allow inline mixing with other code, then that would result in a compiler warning or error message. It might be best to have a new attribute name here rather than using "always_inline" - I have not thought through the consequences. It might also be that if the compiler can be changed to support inlining of a given optimisation attribute, then the attribute in question can be whitelisted for inlining for everyone. I suppose what I am saying is that if the compiler can't be sure that inlining is safe, then it could be cautious by default while letting the programmer override that caution explicitly.
