https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #8 from Anonymous <ipsum.te.futue at gmail dot com> --- (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.
