https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Ganesh.Gopalasubramanian@am
                   |                            |d.com, hubicka at gcc dot 
gnu.org
         Resolution|INVALID                     |---
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2024-09-27
     Ever confirmed|0                           |1

--- Comment #9 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Anonymous from comment #7)
> (In reply to Thiago Macieira from comment #5)
> 
> > This has nothing to do with -march=native. In fact, for the Gentoo people
> > who are using -march=native, everything is fine because __RDRND__ is *not*
> > defined (I think; I don't have such a CPU to check, but on my TGL,
> > -march=native and -march=tigerlake differ).
> 
> I have to disagree. I specifically stated in the Qt bug that affected users
> were using -march=native and that was being resolved to -march=bdver4, so
> everything is not fine when using -march=native. You are correct that with
> -march=native on an affected CPU, __RDRND__ is not defined, but that's what
> I used to build Qt libraries that segfaulted. I only got working libraries
> by supplying -march=x86-64-v2 or omitting -march entirely.

So, the problem is not with -march=native, but when -march=bdver4 is passed
explicitly? This is different issue. As said before, -march=native will
fine-tune available ABIs, passing -mno-rdrnd if corresponding cpuid bit is
*NOT* set, while -march=bdver4 will blindly enable all listed ABIs.

These ABIs are listed in gcc/gcc/common/config/i386/i386-common.cc, which
currently defines bdver4 with the following ABIs:

  {"bdver4", PROCESSOR_BDVER4, CPU_BDVER4,
    PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
      | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
      | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_AVX2
      | PTA_FMA4 | PTA_XOP | PTA_LWP | PTA_BMI | PTA_BMI2
      | PTA_TBM | PTA_F16C | PTA_FMA | PTA_PRFCHW | PTA_FXSR
      | PTA_XSAVE | PTA_XSAVEOPT | PTA_FSGSBASE | PTA_RDRND
      | PTA_MOVBE | PTA_MWAITX,

Let's do some software archaeology. The original sumbission [1] defined bdver4
ABIs:

+     {"bdver4", PROCESSOR_BDVER4, CPU_BDVER4,
+        PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3
+        | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1
+        | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_AVX2 
+       | PTA_FMA4 | PTA_XOP | PTA_LWP | PTA_BMI | PTA_BMI2 
+       | PTA_TBM | PTA_F16C | PTA_FMA | PTA_PRFCHW | PTA_FXSR 
+       | PTA_XSAVE | PTA_XSAVEOPT | PTA_FSGSBASE},

and in the meantime the definition grew with

PTA_RDRND | PTA_MOVBE | PTA_MWAITX.

Let's CC author of the original patch for some authoritative answer which
definition is correct.

[1] https://gcc.gnu.org/legacy-ml/gcc-patches/2013-11/msg01237.html

Reply via email to