vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF0 0xBA 0x1 0x0 0x0 0x0 0x89 0x6 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==17999== valgrind: Unrecognised instruction at address 0x846054f. ==17999== at 0x846054F: QRandomGenerator::SystemGenerator::generate(unsigned int*, unsigned int*) (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x84609C8: QRandomGenerator::_fillRange(void*, void*) (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x84A2F55: qt_create_qhash_seed() (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x84A2FA3: qt_initialize_qhash_seed() (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x84A3210: QHashData::detach_helper(void (*)(QHashData::Node*, void*), void (*)(QHashData::Node*), int, int) (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x84B90B1: QHash<QRegExpEngineKey, QCache<QRegExpEngineKey, QRegExpEngine>::Node>::detach() (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x84B58D9: prepareEngine(QRegExpPrivate*) (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x84B5A87: QRegExp::QRegExp(QString const&, Qt::CaseSensitivity, QRegExp::PatternSyntax) (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x8507A2D: QDirIteratorPrivate::QDirIteratorPrivate(QFileSystemEntry const&, QStringList const&, QFlags<QDir::Filter>, QFlags<QDirIterator::IteratorFlag>, bool) (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x8507EDF: QDirIterator::QDirIterator(QString const&, QStringList const&, QFlags<QDir::Filter>, QFlags<QDirIterator::IteratorFlag>) (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x8504DE1: QDir::entryList(QStringList const&, QFlags<QDir::Filter>, QFlags<QDir::SortFlag>) const (in /usr/lib64/libQt5Core.so.5.11.1) ==17999== by 0x8504F3E: QDir::entryList(QFlags<QDir::Filter>, QFlags<QDir::SortFlag>) const (in /usr/lib64/libQt5Core.so.5.11.1) (checking the instruction (recompiling qtcore...), will follow-up in a few minutes)
It's rdrand32_step (used as a gcc built-in) vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF0 0xBA 0x1 0x0 0x0 0x0 0x89 0x6 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==30590== valgrind: Unrecognised instruction at address 0x846054f. ==30590== at 0x846054F: _rdrand32_step (immintrin.h:109) ==30590== by 0x846054F: qt_random_cpu (qrandom.cpp:114) ==30590== by 0x846054F: QRandomGenerator::SystemGenerator::generate(unsigned int*, unsigned int*) (qrandom.cpp:369)
Might be a duplicate of https://bugs.kde.org/show_bug.cgi?id=353370 but I'm not sure.
actually, that issues disables advertising rdrand in CPUID, but what if the program is hard-coded to use it...
Tested with the now's SVN, it's still unhandled.
Well running a program that's hard coded to use it on a CPU that doesn't support it is always going to fail, so don't do that... Valgrind runs your program on an emulated CPU that is normally close to, but not identical to, your actual CPU which is why we adjust the CPUID to indicate what features are actually available. Unless you're only planning to run your program on specific hardware then it really needs to check this kind of thing at run time anyway. *** This bug has been marked as a duplicate of bug 353370 ***
Workaround for the particular Qt 5.11 scenario: compiling qtcore with CXXFLAGS+=" -mno-rdrnd".