[Bug driver/100347] New: GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[Bug driver/100347] New: GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[schnetter at gmail dot com]

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

            Bug ID: 100347
           Summary: GCC 11 does not recognize skylake; translates
                    "march=native" to "x86_64"
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schnetter at gmail dot com
  Target Milestone: ---

I just built GCC 11.1.0 (via Spack). I find that "-march=native" does not work
any more. It used to work with GCC 10.3 and earlier. The symptom is that
manually vectorized code does not compile any more.

This demonstrates the problem:

$ ./view-compilers/bin/gcc -march=native -Q --help=target | grep march
  -march=                               x86-64
  Known valid arguments for -march= option:

This outputs "x86-64" where I expect "skylake".

$ ./view-compilers/bin/gcc --version
gcc (Spack GCC) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

It works with an older version of GCC:

$ /opt/local/bin/gcc -march=native -Q --help=target | grep march
  -march=                               skylake
  Known valid arguments for -march= option:

$ /opt/local/bin/gcc --version
gcc (MacPorts gcc10 10.3.0_0) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My system is a

$ uname -a
Darwin redshift.local 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar  5 01:14:14
PST 2021; root:xnu-7195.101.1~3/RELEASE_X86_64 x86_64 i386 MacBookPro15,1
Darwin

[Bug driver/100347] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[schnetter at gmail dot com]

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

--- Comment #1 from Erik Schnetter <schnetter at gmail dot com> ---
Forgot to add: When I explicitly use "-march=skylake", everything works as
expected.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.2
             Target|                            |x86_64-*-* i?86-*-*
            Summary|GCC 11 does not recognize   |[11/12 Regression] GCC 11
                   |skylake; translates         |does not recognize skylake;
                   |"march=native" to "x86_64"  |translates "march=native"
                   |                            |to "x86_64"
                 CC|                            |hjl.tools at gmail dot com
          Component|driver                      |target

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you paste one entry of /proc/cpuinfo?  It works for me for znver2 and
haswell.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think Darwin doesn't have it (though I have no access to it, so can't check),
googling around shows that
sysctl -a | grep machdep.cpu
or MacCPUID utility might provide the information we need.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And it works fine for me on skylake-avx512 too.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[schnetter at gmail dot com]

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

--- Comment #5 from Erik Schnetter <schnetter at gmail dot com> ---
This is my hardware configuration:

$ sysctl -a | grep machdep.cpu
machdep.cpu.address_bits.physical: 39
machdep.cpu.address_bits.virtual: 48
machdep.cpu.arch_perf.events: 0
machdep.cpu.arch_perf.events_number: 7
machdep.cpu.arch_perf.fixed_number: 3
machdep.cpu.arch_perf.fixed_width: 48
machdep.cpu.arch_perf.number: 4
machdep.cpu.arch_perf.version: 4
machdep.cpu.arch_perf.width: 48
machdep.cpu.cache.L2_associativity: 4
machdep.cpu.cache.linesize: 64
machdep.cpu.cache.size: 256
machdep.cpu.mwait.extensions: 3
machdep.cpu.mwait.linesize_max: 64
machdep.cpu.mwait.linesize_min: 64
machdep.cpu.mwait.sub_Cstates: 286531872
machdep.cpu.thermal.ACNT_MCNT: 1
machdep.cpu.thermal.core_power_limits: 1
machdep.cpu.thermal.dynamic_acceleration: 1
machdep.cpu.thermal.energy_policy: 1
machdep.cpu.thermal.fine_grain_clock_mod: 1
machdep.cpu.thermal.hardware_feedback: 0
machdep.cpu.thermal.invariant_APIC_timer: 1
machdep.cpu.thermal.package_thermal_intr: 1
machdep.cpu.thermal.sensor: 1
machdep.cpu.thermal.thresholds: 2
machdep.cpu.tlb.data.small: 64
machdep.cpu.tlb.data.small_level1: 64
machdep.cpu.tlb.inst.large: 8
machdep.cpu.tsc_ccc.denominator: 2
machdep.cpu.tsc_ccc.numerator: 216
machdep.cpu.xsave.extended_state: 31 832 1088 0
machdep.cpu.xsave.extended_state1: 15 832 256 0
machdep.cpu.brand: 0
machdep.cpu.brand_string: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
machdep.cpu.core_count: 6
machdep.cpu.cores_per_package: 8
machdep.cpu.extfamily: 0
machdep.cpu.extfeature_bits: 1241984796928
machdep.cpu.extfeatures: SYSCALL XD 1GBPAGE EM64T LAHF LZCNT PREFETCHW RDTSCP
TSCI
machdep.cpu.extmodel: 9
machdep.cpu.family: 6
machdep.cpu.feature_bits: 9221960262849657855
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA
CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ
DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC
MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_feature_bits: 43806655 1073741824
machdep.cpu.leaf7_feature_bits_edx: 2617255424
machdep.cpu.leaf7_features: RDWRFSGS TSC_THREAD_OFFSET SGX BMI1 HLE AVX2 SMEP
BMI2 ERMS INVPCID RTM FPU_CSDS MPX RDSEED ADX SMAP CLFSOPT IPT SGXLC MDCLEAR
TSXFA IBRS STIBP L1DF SSBD
machdep.cpu.logical_per_package: 16
machdep.cpu.max_basic: 22
machdep.cpu.max_ext: 2147483656
machdep.cpu.microcode_version: 222
machdep.cpu.model: 158
machdep.cpu.processor_flag: 5
machdep.cpu.signature: 591594
machdep.cpu.stepping: 10
machdep.cpu.thread_count: 12
machdep.cpu.vendor: GenuineIntel

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[mytbk920423 at gmail dot com]

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

Iru Cai <mytbk920423 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mytbk920423 at gmail dot com

--- Comment #6 from Iru Cai <mytbk920423 at gmail dot com> ---
I've checked host_detect_local_cpu() in gcc/config/i386/driver-i386.c. GCC
detects x86 host CPU micro architecture by cpuid instruction instead of the
APIs provided by the OS.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Iru Cai from comment #6)
> I've checked host_detect_local_cpu() in gcc/config/i386/driver-i386.c. GCC
> detects x86 host CPU micro architecture by cpuid instruction instead of the
> APIs provided by the OS.

But there shouldn't have been any functional changes in the code 10.x vs. 11.x

Erik - does GCC 10.3 actually still work?  Thus, isn't it maybe some OS
restriction on CPUID access, maybe a difference in whether the GCC binaries
are signed or not?

I wonder if you can try

int main()
{
  __builtin_cpu_init ();
  return __builtin_cpu_is ("skylake");
}

with both compilers?

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> (In reply to Iru Cai from comment #6)
> > I've checked host_detect_local_cpu() in gcc/config/i386/driver-i386.c. GCC
> > detects x86 host CPU micro architecture by cpuid instruction instead of the
> > APIs provided by the OS.
> 
> But there shouldn't have been any functional changes in the code 10.x vs.
> 11.x
> 
> Erik - does GCC 10.3 actually still work?  Thus, isn't it maybe some OS
> restriction on CPUID access, maybe a difference in whether the GCC binaries
> are signed or not?
> 
> I wonder if you can try
> 
> int main()
> {
>   __builtin_cpu_init ();
>   return __builtin_cpu_is ("skylake");
> }
> 
> with both compilers?

I recently went through the exercise of finding out what -march=native reported
for me across the machines I use for testing - AFAIR the Xeon W reported
cascadelake, and corei7s reported skyline, ivybridge or haswell.  I will need
to recheck.  

Are you on Darwin20 / macOS11 .. it seems that Apple are gradually trying to
tie things down more in line with iOS - however, I have not seen too much of
that on x86_64 - more on the Arm64 side.

I'll need a few days to check this out.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
You could as well step through the driver-i386.c and cpuinfo.h code in the
debugger.
>From the info you've provided, seems you have __cpu_family 6 and __cpu_model
0x9e, so get_intel_cpu should reach:
    case 0x4e:
    case 0x5e:
      /* Skylake.  */
    case 0x8e:
    case 0x9e:
      /* Kaby Lake.  */
    case 0xa5:
    case 0xa6:
      /* Comet Lake.  */
      cpu = "skylake";
      CHECK___builtin_cpu_is ("corei7");
      CHECK___builtin_cpu_is ("skylake");
      cpu_model->__cpu_type = INTEL_COREI7;
      cpu_model->__cpu_subtype = INTEL_COREI7_SKYLAKE;
      break;

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---

build of 11.1 on macOS11 with no patches and default options

$ ./gcc/xgcc -Bgcc /source/test/general/empty-main.c -S -fverbose-asm 
 head -5 empty-main.s 
# GNU C17 (GCC) version 11.1.0 (x86_64-apple-darwin20)
#       compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

# GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
# options passed: -fPIC -mmacosx-version-min=11.2.0 -mtune=core2



$ ./gcc/xgcc -Bgcc /source/test/general/empty-main.c -S -fverbose-asm
-march=native

 head -5 empty-main.s 
# GNU C17 (GCC) version 11.1.0 (x86_64-apple-darwin20)
#       compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

# GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
# options passed: -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f
-mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq
-mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma
-mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2
-mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16
-mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt
-mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mhle -msahf
-mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig
-mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed
-mrtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes
-mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile
-mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl
-mno-avxvnni --param=l1-cache-size=32 --param=l1-cache-line-size=64
--param=l2-cache-size=9216 -mtune=skylake -fPIC -mmacosx-version-min=11.2.0

This seems to DTRT - I will try on some more machines as time permits.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
I also tried on a xeon w machine with darwin19 (macOS 10.15), where it detects
skylake-avx512 (which is a reasonable description, although possibly
cascadelake would be slightly more accurate)

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[schnetter at gmail dot com]

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

--- Comment #12 from Erik Schnetter <schnetter at gmail dot com> ---
Yes, GCC 10.3 (built via MacPorts) still works. The sample program reports a
Skylake CPU with both compilers.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[schnetter at gmail dot com]

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

--- Comment #13 from Erik Schnetter <schnetter at gmail dot com> ---
The failing GCC 11.1.0 is built by Apple Clang 12.0.5 via Spack. Looking at
debug output, I see that Spack inserts a "-march=skylake" command line option.
(I was not aware of this before.) It does so by creating a compiler wrapper
(called "clang++" as well), which calls the actual compiler and adds this (and
some other) flags. 

I seem to recall having read somewhere that GCC's CPU detection code must be
built without any "-march=..." flag.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Erik Schnetter from comment #13)
> The failing GCC 11.1.0 is built by Apple Clang 12.0.5 via Spack. Looking at
> debug output, I see that Spack inserts a "-march=skylake" command line
> option. (I was not aware of this before.) It does so by creating a compiler
> wrapper (called "clang++" as well), which calls the actual compiler and adds
> this (and some other) flags. 
> 
> I seem to recall having read somewhere that GCC's CPU detection code must be
> built without any "-march=..." flag.

well, the GCC config makes sensible default choices for CPU (if there's no
--with-cpu=) - which is core2 mostly (so that the code should run anywhere).

As of this moment the only machines I've got builds with --with-cpu= specify
the correct CPU for the machine, so -march= isn't going to tell anything -
except I can say for sure that it doesn't report x86_64):

/src-local/gcc-master/configure
--prefix=/opt/iains/x86_64-apple-darwin16/gcc-12-0-0d
--build=x86_64-apple-darwin16
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
--enable-languages=all --with-cpu=corei7 --with-tune=skylake
CC=x86_64-apple-darwin16-gcc CXX=x86_64-apple-darwin16-g++

$ ./gcc/xgcc -Bgcc -march=native -Q --help=target | grep march
  -march=                               skylake

So that's reporting what was configures, but also what would be correct for the
hardware - it hasn't overridden the configuration settings.

can we get the output of "gcc -v" for the compiler that isn't working?

If this is a compiler built without bootstrap, and the bootstrap compiler is
clang, then that could be an unknown quantity.  Production compilers should be
bootstrapped.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[schnetter at gmail dot com]

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

--- Comment #15 from Erik Schnetter <schnetter at gmail dot com> ---
When I try to rebuild GCC 10.3 or 10.2, they end up having the same problem.
Also, when I enable bootstrapping, bootstrapping fails with differences in many
files. Given that this used to work on a previous version of the OS, the
problem isn't caused by GCC.

One thing that e.g. changed is that there is now a newer version of Apple
Clang.

Thank you for the help and suggestions.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[iains at gcc dot gnu.org]

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

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Erik Schnetter from comment #15)

> One thing that e.g. changed is that there is now a newer version of Apple
> Clang.

XCode 12.5 is broken, with compare-debug error : see PR100340 (already reported
to Apple, waiting for a response)

If it's something else, please let me know how to reproduce it and we can take
that up with Apple too.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
to complete the set:

/src-local/gcc-master/configure
--prefix=/opt/iains/x86_64-apple-darwin20/gcc-12-0-0
--build=x86_64-apple-darwin20
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
--enable-languages=all CC=x86_64-apple-darwin20-gcc
CXX=x86_64-apple-darwin20-g++ --with-cpu=native 

$ ./gcc/xgcc -Bgcc /source/test/general/empty-main.c -S -fverbose-asm

$ head -5 empty-main.s 
# GNU C17 (GCC) version 12.0.0 20210508 (experimental) [master revision
r12-637-g56103737f173] (x86_64-apple-darwin20)
#       compiled by GNU C version 12.0.0 20210508 (experimental) [master
revision r12-637-g56103737f173], GMP version 6.2.0, MPFR version 4.1.0, MPC
version 1.1.0, isl version isl-0.22-GMP

# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed: --param=l1-cache-size=32 --param=l1-cache-line-size=64
--param=l2-cache-size=9216 -mtune=skylake -fPIC -mmacosx-version-min=11.2.0

Which shows that the '--with-cpu=native' configuration option has also picked
up the right info (and overridden the default core2).  This is a bootstrap
using gcc.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |11.3

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2022-01-05

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
Going over the audit log it seems Iain cannot reproduce the observed failure of
-march=native, the only speciality the reporter mentions is that his build
system inserts a -march=skylake to each compiler command when building GCC (I
assume for stage1 only, and the reporter performs a bootstrap).

Erik, can you arrange for the compiler wrapper to not insert -march=skylake and
see whether that makes a difference?  Otherwise as suggested you need to step
through the -march=native code, see comment#9

I've verified building (not bootstrapping) with --with-cpu= doesn't break
-march=native handling on x86_64-linux.

[Bug target/100347] [11/12 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug target/100347] [11/12/13 Regression] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|WAITING                     |RESOLVED

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
No further response from reporter.