This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC does not support *mmintrin.h with function specific opts
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Sriraman Tallam <tmsriram at google dot com>, Jan Hubicka <hubicka at ucw dot cz>, Xinliang David Li <davidxl at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Diego Novillo <dnovillo at google dot com>
- Date: Fri, 14 Jun 2013 10:49:26 +0200
- Subject: Re: GCC does not support *mmintrin.h with function specific opts
- References: <CAAs8HmyBGJWjheiJZzpt0yRJTpmGngXn9jf9-G1u7g7rgZDGHw at mail dot gmail dot com> <CAAs8HmyuOuM_HkKoJ+s0LBb7946Db5M9wqAmnct=DL-O4eV2xg at mail dot gmail dot com> <CAAkRFZJ0pdRcNjSjykVYmo6uCakdh0pFY8mZSKCbbk2u500t=w at mail dot gmail dot com> <20130613170751 dot GA26413 at kam dot mff dot cuni dot cz> <CAAs8HmwQMsHq4nO44n2iagBitFKB0w-gyxUddUu6Kqip7Z5ETA at mail dot gmail dot com> <20130613171952 dot GA27483 at atrey dot karlin dot mff dot cuni dot cz> <CAAs8Hmz6Lav0DRx8Aw8TQ4Qm4=06Ok5ArL_h+YKZQMCk1hRLRw at mail dot gmail dot com> <20130613194035 dot GB26413 at kam dot mff dot cuni dot cz> <CAAs8HmyRK5OSFn7iq8_Ht6mFPBMjuy7cxAVCxajJjuo3aBfyrg at mail dot gmail dot com> <CAFiYyc1fhFLx6_+nU+V9acpmPmDmf0RR-A=q3Y39jndJ9Uk_NQ at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jun 14, 2013 at 10:43:34AM +0200, Richard Biener wrote:
> On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam <tmsriram@google.com> wrote:
> > On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >>> * tree-inline.c (expand_call_inline): Allow the error to be flagged
> >>> in early inline pass.
> >>> * ipa-inline.c (inline_always_inline_functions): Pretend always_inline
> >>> functions are inlined during failures to flag an error.
> >>> * gcc.target/i386/inline_error.c: New test.
> >
> >> This patch is OK if it passes testing.
> >
> > Two tests gcc.c-torture/compile/pr43791.c and pr44043.c are failing
> > because of always_inline functions being present that cannot be
> > inlined and the compiler is now generating error messages. I will fix
> > them and resend the patch.
>
> Quick look - pr43791.c is not expected to work at -O0, so skip -O0
> for example by guarding the whole thing with #if __OPTIMIZED__ > 0.
> Similar for pr44043.c.
>
> That we didn't error at -O0 before is a bug. Eventually I was suggesting
> to error if we end up outputting the body of an always_inline function,
> that is, any uses remain (including indirect calls or address-takens which
> is where we do not error right now).
Well, for indirect calls/address-takens and gnu_inline style extern inline
always_inline, it should be fine if we just emit calls to the library
function, otherwise you'd break a lot of code, because glibc uses
always_inline heavily for -D_FORTIFY_SOURCE wrapper inlines, open argument
checking etc. But that body supposedly doesn't inherit the always_inline
attribute.
Jakub