[PATCH, i386]: Fix PR target/35553, -fkeep-inline-functions and -O errors our in SSE headers

Richard Guenther richard.guenther@gmail.com
Thu Mar 13 14:24:00 GMT 2008


On Thu, Mar 13, 2008 at 3:12 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Mar 13, 2008 at 10:01:29AM -0400, Jonathan Lennox wrote:
>  > On Thursday, March 13 2008, "Jakub Jelinek" wrote to "Jonathan Lennox, Uros Bizjak, Richard Guenther, gcc patches" saying:
>  >
>  > > -fno-inline is a non-issue, as always_inline attribute is stronger than
>  > > -fno-inline.
>  >
>  > Why is #ifdef __OPTIMIZE__ needed in these files, then?  If always_inline
>  > functions are inlined even at -O0, it seems like the inline functions ought
>  > to work even for the functions which need immediate arguments.
>
>  Please reread what I've said earlier today, or try the testcase I posted:
>
> extern void baz (int);
>  extern __inline __attribute__((__gnu_inline__, __always_inline__, __artificial__))
>  void foo (int i)
>  {
>   baz (i);
>  }
>  void bar (void)
>  {
>   foo (6);
>  }
>
>  Compile that with -O0 -fdump-tree-apply_inline and also with -O1 -fdump-tree-optimized.
>  You'll see that in apply_inline dump which is the last before expansion you
>  have
>   i = 6;
>   baz (i);
>  and therefore the builtin expansion won't see that the argument is
>  INTEGER_CST.  In the optimized dump there is baz (6);, so the expander sees
>  it.

That could be fixed if we were going into-SSA for -O0 via the constant
propagation done at inlining time.  Then you'd get the same behavior
as for the macro.

Richard.



More information about the Gcc-patches mailing list