[Bug c/116854] New: GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

2024-09-26 Thread ipsum.te.futue at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854

Bug ID: 116854
   Summary: GCC incorrectly assumes all CPUs where -march=native
resolves to -march=bdver4 will have RDRND support
   Product: gcc
   Version: 13.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ipsum.te.futue at gmail dot com
  Target Milestone: ---

Summary: GCC enables __haswell__ on certain AMD Excavator CPUs that
'-march=native' resolves to '-march=bdver4 -mno-rdrnd' despite the fact that
RDRND should be checked for and required in order to enable __haswell__.

While investigating segfaults within Qt, compiled with GCC 13.3.1, it has been
discovered that GCC is attempting to compile for RDRND on bdver4 arch CPUs.
Affected users specify -march=native, which resolves to -march=bdver4.

Docs state that bdver4 is a superset of Haswell, which implies the presence of
RDRND:

~ $ gcc -dM -E -march=bdver4 -xc /dev/null | grep RDRND
#define __RDRND__ 1


To quote from this
[https://bugreports.qt.io/browse/QTBUG-129193?focusedId=825891&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-825891]
comment, in the original Qt bug:

"Ok, so the problem is that this CPU is missing the random number generator
instructions, which all Intel CPU have had since Ivy Bridge (2013). That is a
problem, but not our problem here. Our problem here is that we have a mismatch
between what features are required at compile-time to enable __haswell__ and
which ones are checked at runtime for that CPU."

It is important to note that the Gentoo tool `resolve-march-native` returns
'-mno-rdrnd' as part of its resolution for an affected machine, however it
seems that even with this being the case, GCC compiles the affected Qt
libraries expecting RDRND as part of the feature set.

A final quote from the Qt bug:
"Apparently, for AMD Excavator (Bulldozer 4), GCC says that the RDRND ISA
extension is mandatory. That means QtCore assumes it's always present if you
compile with -march=bdver4 and that is likely to crash with SIGILL if you use
that flag."

NB: Affected users compiled with '-march=native' in all documented cases, and
allowed GCC to resolve the CPU arch and features.

~ $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/configure
--host=x86_64-pc-lin
ux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13 --includedir=/usr/lib/
gcc/x86_64-pc-linux-gnu/13/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13
--mandir=/usr/share/gcc-data
/x86_64-pc-linux-gnu/13/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info
--with-gxx-include-dir=/usr/li
b/gcc/x86_64-pc-linux-gnu/13/include/g++-v13 --disable-silent-rules
--disable-dependency-tracking --with-python-dir=
/share/gcc-data/x86_64-pc-linux-gnu/13/python --enable-languages=c,c++,fortran
--enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-
checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 13.3.1_p20240614 p17' --w
ith-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-thr
eads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed
-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--enable-cet --disable-systemtap --di
sable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd
--without-isl --enable-default-pie -
-enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-lto
bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.3.1 20240614 (Gentoo Hardened 13.3.1_p20240614 p17)

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

2024-09-26 Thread ipsum.te.futue at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854

--- Comment #8 from Anonymous  ---
(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.

This is why I was asking in the Qt bug about the lack of definition for
__RDRND__ when GCC is supplied with -march=native, and whether the explanation
about __haswell__ still worked - because nobody involved is supplying
-march=bdver4 as a compiler argument, everyone is using -march=native and
trusting gcc to make a decision on the correct environment.

I had understood from our conversation in the Qt bug that gcc was resolving
native to bdver4, building Qt for bdver4 but somehow omitting -mno-rdrnd, or
ignoring it (i.e. omitting feature checks which should be mandatory), and that
was how we ended up with a Qt build configured requiring RDRND.

[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support

2024-09-26 Thread ipsum.te.futue at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854

--- Comment #7 from Anonymous  ---
(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.

This is why I was asking in the Qt bug about the lack of definition for
__RDRND__ when GCC is supplied with -march=native, and whether the explanation
about __haswell__ still worked - because nobody involved is supplying
-march=bdver4 as a compiler argument, everyone is using -march=native and
trusting gcc to make a decision on the correct environment.

I had understood from our conversation in the Qt bug that gcc was resolving
native to bdver4, building Qt for bdver4 but somehow omitting -mno-rdrnd, or
ignoring it (i.e. omitting feature checks which should be mandatory), and that
was how we ended up with a Qt build configured requiring RDRND.