[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713
--- Comment #10 from James Addison ---
Hi folks,
Re-stating and confirming the bugreport details here: both gcc-11 (11.3.0) and
gcc-12 (12.2.0) emit bytecode instructions that aren't supported on all
i686-architecture CPUs.
This comment includes a demonstration/repro case to help verify the problem and
potential fixes, along with a suggested remediation approach that is a small
adjustment of Adrian's original suggestion.
As a recap, partly for my own understanding: the 'endbr32' instruction required
to implement Intel Control-flow Enforcement Technology (aka Intel CET) is a
renaming and repurposing of an existing long-NOP (aka NOPL) instruction that
was not documented in the original Pentium Pro specification and therefore is
not supported on all i686-class CPUs.
### Version information
$ gcc-11 --version
gcc-11 (Debian 11.3.0-12) 11.3.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.
$ gcc-12 --version
gcc-12 (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 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.
$ objdump --version
GNU objdump (GNU Binutils for Debian) 2.40
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
### Replicating the problem
$ cat repro.c
int main() {}
$ for prot in full branch return none check; do gcc-11 -m32 -march=i686
-fcf-protection=$prot -c repro.c -o gcc-11-$prot.o; gcc-12 -m32 -march=i686
-fcf-protection=$prot -c repro.c -o gcc-12-$prot.o; done;
### Checking the results
$ for binary in gcc-*.o; do echo $binary; objdump -d $binary | grep -w endbr32
; done;
gcc-11-branch.o
0: f3 0f 1e fb endbr32
gcc-11-check.o
gcc-11-full.o
0: f3 0f 1e fb endbr32
gcc-11-none.o
gcc-11-return.o
gcc-12-branch.o
0: f3 0f 1e fb endbr32
gcc-12-check.o
gcc-12-full.o
0: f3 0f 1e fb endbr32
gcc-12-none.o
gcc-12-return.o
### Remedy
Please could GCC be updated to reject attempts to build binaries for the i686
architecture when fcf-protection is configured to -- or implied to include --
'branch' protection?
Values for the fcf-protection flag were sourced from the GCC documentation at:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fcf-protection
(as noted: this does duplicate some of the original bugreport's suggestion, but
is intended to be slightly more granular because I believe it's important to
note that not all fcf-protection values are unsupported by the i686
architecture)
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 James Addison changed: What|Removed |Added CC||jay+g...@jp-hosting.net --- Comment #9 from James Addison --- (In reply to James Addison from comment #7) > Something that's unclear to me is whether fcf-protection requires NOPL > (multi-byte NOP). I understand that it requires endbr32. (and now I also understand that the endbr32 instruction is a repurposing of a previously-existing long-NOP - and that it's required to implement fcf-protection, aka Intel CET)
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 --- Comment #8 from James Addison --- (In reply to James Addison from comment #7) > (In reply to Adrian Bunk from comment #6) > > (In reply to James Addison from comment #5) > > > Could the findings indicate that there are two bugs here? > > > > > > - The Geode LX target capable of supporting fcf-protection but GCC-11 > > > currently rejects that architecture and flag combination > > > > The problem is the opposite. > > Ok, thank you. > > Something that's unclear to me is whether fcf-protection requires NOPL > (multi-byte NOP). I understand that it requires endbr32. > > Was my second statement (re: GCC-11 emitting NOPL for i686) correct? I haven't been able to replicate generation of NOPL instructions using GCC-11 (with GNU binutils); my apologies for the distraction.
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 --- Comment #7 from James Addison --- (In reply to Adrian Bunk from comment #6) > (In reply to James Addison from comment #5) > > Could the findings indicate that there are two bugs here? > > > > - The Geode LX target capable of supporting fcf-protection but GCC-11 > > currently rejects that architecture and flag combination > > The problem is the opposite. Ok, thank you. Something that's unclear to me is whether fcf-protection requires NOPL (multi-byte NOP). I understand that it requires endbr32. Was my second statement (re: GCC-11 emitting NOPL for i686) correct?
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 James Addison changed: What|Removed |Added CC||jay+g...@jp-hosting.net --- Comment #5 from James Addison --- Adrian wrote: > To support the Geode in OLPC, the toolchain definition of i686 does include > CMOV but it does not include multi-byte NOPs. ... > Sorry for being unclear, this is the historical reason why the binutils/gcc > definition of i686 does not include multi-byte NOPs. Jakub wrote: > Just build for those as -march=i586. preventing -fcf-protection with > -march=i686 would be a really bad idea, that would basically prevent all of > CET protection for 32-bit code, i686 is what is used as the supported lowest > common denominator of 32-bit code. Could the findings indicate that there are two bugs here? - The Geode LX target capable of supporting fcf-protection but GCC-11 currently rejects that architecture and flag combination (in the potentially-buggy code[1] that Adrian refers to) - Multi-byte NOPs are emitted for architecture i686 by GCC-11, despite some CPUs within that architecture lacking[2] support Also potentially relevant is bug 41989. [1] - https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-options.cc;h=805539364108eee07f5bda527acd6f39f3f7bf95;hb=HEAD#l2929 [2] - https://bugzilla.redhat.com/show_bug.cgi?id=579838#c32
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 --- Comment #21 from James Addison --- (In reply to Jakub Jelinek from comment #20) > (In reply to James Addison from comment #19) > > Would adding '-Wuninitialized -Werror=uninitialized' to the dg-options in > > 'gcc/testsuite/gcc.target/i386/avx-1.c' be possible, with these fixes in > > place? (as a regression safety net of sorts) > > I don't see what advantages it would have over -Wuninitialized on sse-23.c. > And, -Werror= isn't really needed, the testing infrastructure will mark as > FAILs any > excess diagnostics which isn't expected or pruned out, not just errors. Ok, that makes sense - thanks for the explanations.
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 --- Comment #19 from James Addison --- Thanks, Jakub! (I had begun developing a patch locally, but hadn't found all of the six locations, and learning some of the contributing guidelines was going to take me a while) Would adding '-Wuninitialized -Werror=uninitialized' to the dg-options in 'gcc/testsuite/gcc.target/i386/avx-1.c' be possible, with these fixes in place? (as a regression safety net of sorts)
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 --- Comment #16 from James Addison --- Does it make sense to update some of the other variable declarations (like this[1] one) within optimized blocks to use self-initialization as part of this bug, or should I create a separate bug for that? (or, an acceptable option three: no, that's wrong, don't bother) [1] - https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/avx512erintrin.h;h=7d6aecb70c27579a394360cc82f500acc4519430;hb=HEAD#l54
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 James Addison changed: What|Removed |Added CC||jay+g...@jp-hosting.net --- Comment #9 from James Addison --- A similar warning is raised when compiling avx512erintrin.h with optimization and -Wuninitialized enabled: /usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h:55:20: warning: ‘__W’ is used uninitialized [-Wuninitialized] The relevant GCC code can be found at https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/avx512erintrin.h;h=6b3b679a17675612f45a1090f227012b80b871a6#l54 The compilation command-line used was: gcc -O -Wuninitialized -mavx512er -mavx512pf The code-under-compilation can be found at https://github.com/numpy/numpy/blob/bb2769e12a8646f3d63097e9464592aa6e20058d/numpy/distutils/checks/cpu_avx512_knl.c
