I have recently rebuilt world with gcc-8.2.0 and noticed a test failure of sys-apps/coreutil's misc/sort-u-FMR test which I haven't seen before (http://lists.gnu.org/archive/html/bug-coreutils/2018-08/msg00032.html): > + require_valgrind_ > + valgrind --error-exitcode=1 true > + echo 0 > + printf '%0900d\n' 1 > + valgrind --error-exitcode=1 sort --p=1 -S32b -u in > ==46265== Memcheck, a memory error detector > ==46265== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==46265== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info > ==46265== Command: sort --p=1 -S32b -u in > ==46265== > ==46265== Conditional jump or move depends on uninitialised value(s) > ==46265== at 0x49249CE: ??? (in /lib64/libc-2.27.so) > ==46265== by 0x48F4B31: ??? (in /lib64/libc-2.27.so) > ==46265== by 0x7FFFFFFFFFFFF: ??? > ==46265== > ==46265== Conditional jump or move depends on uninitialised value(s) > ==46265== at 0x491EE81: ??? (in /lib64/libc-2.27.so) > ==46265== by 0x1100D6: ??? (in > /var/tmp/portage/sys-apps/coreutils-8.30/work/coreutils-8.30/src/sort) > ==46265== by 0x2F: ??? > ==46265== by 0x402BCC2: ??? > ==46265== by 0x30: ??? > ==46265== by 0x5: ??? > ==46265== by 0x402A36F: ??? > ==46265== by 0x1FFEFF471F: ??? > ==46265== by 0xA00000000000009: ??? > ==46265== by 0x1FFEFF55A6: ??? > ==46265== by 0x402B84F: ??? > ==46265== by 0x402A7DF: ??? > ==46265== > ==46265== > ==46265== HEAP SUMMARY: > ==46265== in use at exit: 0 bytes in 0 blocks > ==46265== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==46265== > ==46265== All heap blocks were freed -- no leaks are possible > ==46265== > ==46265== For counts of detected and suppressed errors, rerun with: -v > ==46265== Use --track-origins=yes to see where uninitialised values come from > ==46265== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) I first suspected it had something to do with glibc-2.27 but this was wrong. It turned out this wasn't really a test failure caused by a bug. It was a test failure caused by valgrind which was unable to read debug info and therefore assumed "Conditional jump or move depends on uninitialised value". In the end this was triggered by binutils which now defaults to "ld -z". Please apply the following fix: https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=commit;h=64aa729bfae71561505a40c12755bd6b55bb3061 https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=commit;h=e752326cc050803c3bcfde1f8606bead66ff9642
I can confirm this issue. Please note the discussion here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903581
No need to add any AT.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e276088867d6e2493f445a332ab85811ec23a403 commit e276088867d6e2493f445a332ab85811ec23a403 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-09-05 12:24:48 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-09-05 12:25:11 +0000 dev-util/valgrind: fix reading debug info from binaries built with -z separate-code Closes: https://bugs.gentoo.org/664882 Package-Manager: Portage-2.3.48, Repoman-2.3.10 ...ept-read-only-PT_LOAD-segments-and-rodata.patch | 95 +++++++++++++++ ...further-mappings-after-read-all-debuginfo.patch | 70 +++++++++++ dev-util/valgrind/valgrind-3.13.0-r3.ebuild | 128 +++++++++++++++++++++ 3 files changed, 293 insertions(+)
