https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to David Brown from comment #7)
> (In reply to rguent...@suse.de from comment #6)
> > 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.
There is no way to do something like that for signed integer division because
the way GCC supports is using unsigned integer arithmetic and then an
unsigned to signed conversion.
GCC also currently does not support re-writing the inlined function
on-the-fly.
> 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.
Indeed what we are missing is a diagnostic on the cases where always_inline
(or any other exception) overrides the explicit list of problematic
option mismatches.
For an example I was more looking into a case where there it is not one of
the explicitly rejected cases. Like if people do
__attribute__((optimize("-fno-tree-pre")))
static inline int foo (...) { ... }
int bar (...) { ... foo (); ... }
there isn't a way to honor disabling PRE for the inlined code portion but
still enabling it for the code originating from bar. So we can't fulfil
users expectation honoring the optimize attribute and inlining at the same
time. Would you prioritize inlining here? We most of the time prioritize
the 'optimize' attribute and -Winline diagnoses this fact.
