https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #17 from Thiago Macieira <thiago at kde dot org> --- (In reply to comment #8) > 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. Sorry, that's a misunderstanding of the problem. __RDRND__ was *not* defined for -march=native. The problem was that Qt's definition of the __haswell__ macro (which Qt #defines as a stand-in for __x86_64_v3__) and the CpuArchHaswell bit flag were mismatched on the presence of __RDRND__. The design was that if __haswell__ was defined, qCpuHasFeature(Haswell) would be a constant true, but the mismatch caused the macro to be defined and yet the qCpuHasFeature() call to return false. If those users had built with -march=bdver4, Qt would not have crashed in the painting engine. But as a consequence, I thought the random number generator would have (though see comment #16 why it wouldn't). That's *this* bug report. (In reply to Jonathan Wakely from comment #12) > The bug report is frustratingly unclear. Sorry. Hopefully the above clarifies a bit. Instead of reporting it myself, I asked the OP in the Qt bug report to do so, because he'd have "skin in the game" for owning an affected AMD processor. But it looks like my explanation requesting it be done wasn't clear. I apologise. > So should this bug report be a request to change the meaning of bdver4? > Because it's behaving as documented currently. > > Can we fix the summary to be more accurate? > > Would "-march=bdver4 should not enable RDRND" be better? Yes, please.
