On Tue, Mar 30, 2021 at 10:14 AM Uros Bizjak <ubiz...@gmail.com> wrote: > > On Fri, Mar 26, 2021 at 6:24 PM H.J. Lu <hjl.to...@gmail.com> wrote: > > > > On Fri, Mar 26, 2021 at 5:09 AM Richard Biener > > <richard.guent...@gmail.com> wrote: > > > > > > On Fri, Mar 26, 2021 at 11:26 AM Jakub Jelinek <ja...@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. > > > > Here is a simple patch for GCC 11 by defining __rdtsc and __rdtscp > > as macros. OK for master? > > I don't want to step on anyone's toes by approving this approach, so > I'd like to ask Richard and Jakub if they agree with the solution.
I'm OK with the solution for __rdtsc & friends. I suppose there's nothing that guarantees taking the address of an intrinsic is going to work? It of course still leaves the more general problem unsolved. Richard. > Uros,
