[PATH] PR/49139 fix always_inline failures diagnostics

[Richard Guenther]

On Tue, May 31, 2011 at 9:54 AM, Christian Bruel <christian.bruel@st.com> wrote:
> Hello,
>
> The attached patch fixes a few diagnostic discrepancies for always_inline
> failures.
>
> Illustrated by the fail_always_inline[12].c attached cases, the current
> behavior is one of:
>
> - success (with and without -Winline), silently not honoring always_inline
>   gcc fail_always_inline1.c -S -Winline -O0 -fpic
>   gcc fail_always_inline1.c -S -O2 -fpic
>
> - error: with -Winline but not without
>   gcc fail_always_inline1.c -S -Winline -O2 -fpic
>
> - error: without -Winline
>   gcc fail_always_inline2.c -S -fno-early-inlining -O2
>   or the original c++ attachment in this defect
>
> note that -Winline never warns, as stated in the documentation
>
> This simple patch consistently emits a warning (changing the sorry
> unimplemented message) whenever the attribute is not honored.
>
> My first will was to generate and error instead of the warning, but since it
> is possible that inlines is only performed at LTO time, an error would be
> inapropriate (Note that today this is not possible with -Winline that would
> abort).
>
> Another alternative I considered would be to emit the warning under -Winline
> rather than unconditionally, but this more a user misuse of the attribute,
> so should always be warned anyway. Or maybe a new -Winline-always that would
> be activated under -Wall ? Other opinion welcomed.
>
> Tested with standard bootstrap and regression on x86.
>
> Comments, and/or OK for trunk ?

The patch is not ok, we may not fail to inline an always_inline
function.  To make this more consistent I proposed to warn
whenever you take the address of an always_inline function
(because then you can confuse GCC by indirectly calling
such function which we might inline dependent on optimization
setting and which we might discover we didn't inline only
dependent on optimization setting).  Honza proposed to move
the sorry()ing to when we feel the need to output the
always_inline function, thus when it was not optimized away,
but that would require us not preserving the body (do we?)
with -fpreserve-inline-functions.

For fail_always_inline1.c we should diagnose the appearant
misuse of always_inline with a warning, drop the attribute
but keep DECL_DISREGARD_INLINE_LIMITS set.

Same for fail_always_inline2.c.

I agree that sorry()ing for those cases is odd.  EIther we
should reject the declarations upfront
("always-inline function will not be inlinable"), or we should
emit a warning of that kind and make sure to not sorry later.

Richard.

> Many thanks,
>
> Christian
>
> 2010-05-25  Christian Bruel  <christian.bruel@st.com>
>
>        PR 49139
>        * ipa-inline-transform.c (inline_transform):force call to
> optimize_inline_calls error if function is always_inline.
>        * tree-inline.c (tree_inlinable_function_p): always warn.
>        (expand_call_inline): Likewise.
>
> 2010-05-25  Christian Bruel  <christian.bruel@st.com>
>
>        * gcc.db/always_inline.c: Removed -Winline. Update checks
>        * gcc.db/always_inline2.c: Likewise.
>        * gcc.db/always_inline3.c: Likewise.
>        * gcc.db/fail_always_inline1.c: New test.
>        * gcc.db/fail_always_inline2.c: New test.
>
>
>
>
>