[Bug other/104683] New: -march=haswell generates invalid instructions on Celeron Haswell CPUs

[Bug other/104683] New: -march=haswell generates invalid instructions on Celeron Haswell CPUs

[pc-gcc22 at crowcastle dot net]

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

            Bug ID: 104683
           Summary: -march=haswell generates invalid instructions on
                    Celeron Haswell CPUs
           Product: gcc
           Version: 10.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pc-gcc22 at crowcastle dot net
  Target Milestone: ---

Many of the -march options enable instruction types like AVX that are not
available on Pentium and Celeron processors in that family.

I encountered this on a Haswell Celeron system running gcc 10.3.1.  I suspect
this is the same on many other versions.

gcc --version
gcc (Gentoo 10.3.1_p20211126 p0) 10.3.1 20211126

diff <(gcc -march=haswell -Q --help=target) <(gcc -march=native -Q
--help=target)
12c12
<   -mabm                                       [disabled]
---
>   -mabm                                       [enabled]
26,27c26,27
<   -mavx                                       [enabled]
<   -mavx2                                      [enabled]
---
>   -mavx                                       [disabled]
>   -mavx2                                      [disabled]
48,49c48,49
<   -mbmi                                       [enabled]
<   -mbmi2                                      [enabled]
---
>   -mbmi                                       [disabled]
>   -mbmi2                                      [disabled]
65c65
<   -mf16c                                      [enabled]
---
>   -mf16c                                      [disabled]
70c70
<   -mfma                                       [enabled]
---
>   -mfma                                       [disabled]
186c186
<   -mxsave                                     [enabled]
---
>   -mxsave                                     [disabled]
188c188
<   -mxsaveopt                                  [enabled]
---
>   -mxsaveopt                                  [disabled]

Fortunately, -march=native is fine, but I encountered a project that detects
the processor family and was setting -march=haswell, which failed with illegal
instructions.

While I would argue that -march=[family] should compile only using instructions
available for all processors in [family], I could also see an argument for this
being a documentation bug where the definition for -march=[family] should warn
that it will enable features only available on some CPUs in that family, which
is not what many users would expect.  (There might be cause for separate -march
definitions for lower-end processors, but I don't have brilliant ideas for
syntax, and that might be just adding too much complexity.)

[Bug target/104683] -march=haswell generates invalid instructions on Celeron Haswell CPUs

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-02-25
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I don't think we should fix anything in GCC here - the family names are really
aliases and while we now have skylake-avx512 nobody thought of haswell-avx2
(or haswell-noavx2).  I really blame Intel here for very bad product
segmentation here ...

Can you please provide the exact CPU model here, maybe cut&pasting from
/proc/cpuinfo?

[Bug target/104683] -march=haswell generates invalid instructions on Celeron Haswell CPUs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Same for -march=broadwell and -march=skylake (G3900) btw (just browsing Intel
Ark database).  Can't figure what's the "celeron/pentium" successor to the
skylake family is to check if even newer SKUs are affected.

As said changing -march=skylake to not include AVX2 would be a bad idea, adding
-march=skylake-noavx might work but then nobody would use that so I'm not sure
what's the point.

But again - fun ... let's see if Intel manages to fuse of AVX for some
Alderlake SKUs ...

[Bug target/104683] -march=haswell generates invalid instructions on Celeron Haswell CPUs

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
G5905 aka Comet Lake also has no AVX (but that's just skylake++ and we don't
have any -march= for those).

Note that our documentation says:

@item haswell
Intel Haswell CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE and HLE instruction set support.

so it explicitely mentions AVX2 - that means you cannot match Intel Product
Names and GCC -march= identifiers 1:1.  So I'd say it works as intended.

[Bug target/104683] -march=haswell generates invalid instructions on Celeron Haswell CPUs

[pc-gcc22 at crowcastle dot net]

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

--- Comment #4 from Preston Crow <pc-gcc22 at crowcastle dot net> ---
I can see how it's documented, but many people reading that won't realize that
the instruction sets don't match all Haswell chips.  Simply adding a line below
that to say "Note: Some lower-end Haswell processors do not include all of the
above instruction sets."  And do the same for the others.  Then at least anyone
reading the documentation will immediately be aware of the potential problem
and hopefully avoid using them in inappropriate situations.