[PATCH] x86: Skip ISA check for always_inline in system headers

[Richard Biener]

On Fri, Mar 26, 2021 at 11:26 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Fri, Mar 26, 2021 at 11:13:21AM +0100, Richard Biener wrote:
> > On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelinek via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> > >
> > > On Thu, Mar 25, 2021 at 11:36:37AM -0700, H.J. Lu via Gcc-patches wrote:
> > > > How can we move forward with it?  I'd like to resolve it in GCC 11.
> > >
> > > I think it is too late for GCC 11 for this.
> > > Especially if the solution would be that we change the behavior of existing
> > > attribute, we would need enough time to test everything in the wild that
> > > we don't break it badly,
> >
> > But isn't the suggested change only going to make programs we reject now
> > with an error accepted or ICEing?  Thus, no program that works right now
> > should break.
>
> That is true, but even
> accepts-invalid
> and
> ice-on-invalid-code
> would be important regressions.
> Changing the always_inline attribute behavior without at least avoiding
> the first of those for our intrinsics would be bad, and we need to look what
> people use always_inline in the wild for and what are their expectations.
> And for the intrinsics we need something maintainable, we have > 5000
> intrinsics on i386 alone, > 4000 on aarch64, > 7000 on arm, > 600 on rs6000,
> > 100 on sparc, I bet most of them rely on the current behavior.
> I think the world doesn't end if we do it for GCC 12 only, do it right for
> everything we are aware of and have many months to figure out what impact it
> will have on programs in the wild.

As said, my opinion is that this fallout doesn't "exist" in the wild
since it can
only exist for code we reject right now which in my definition of
"out in the wild" makes it not exist.  I consider only code accepted by
the compiler as valid "out in the wild" example.

See also the behavior of always-inline with regard to the optimize attribute.

So yes, a better solution would be nice but I can't see any since the
underlying issue is known since a long time and thus the pragmatic
solution is the best (IMHO), also from a QOI perspective.  For intrinsics
it also avoids differences with -O0 vs -O with what we accept and reject.

Richard.

>         Jakub
>