On x86_64 we have two failures in tst-audit10 and tst-audit4. version: 1 objopen: 0, objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/ld-linux-x86-64.so.2 activity: add objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod10a.so, LA_SET_ORIG objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod10a.so objsearch: libc.so.6, LA_SET_ORIG objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6, LA_SER_LIBPATH objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6 activity: consistent symbind64: symname=__libc_start_main, st_value=0x7f89ce53bfd0, ndx=2118, flags=0 pltenter: symname=__libc_start_main, st_value=0x7f89ce53bfd0, ndx=2118, flags=0 preinit symbind64: symname=mallopt, st_value=0x7f89ce5a6a60, ndx=1784, flags=0 pltenter: symname=mallopt, st_value=0x7f89ce5a6a60, ndx=1784, flags=0 symbind64: symname=getopt_long, st_value=0x7f89ce60f900, ndx=1439, flags=0 pltenter: symname=getopt_long, st_value=0x7f89ce60f900, ndx=1439, flags=0 symbind64: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0 pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0 symbind64: symname=strtoul, st_value=0x7f89ce558e80, ndx=1172, flags=0 pltenter: symname=strtoul, st_value=0x7f89ce558e80, ndx=1172, flags=0 pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0 symbind64: symname=setvbuf, st_value=0x7f89ce591e00, ndx=1882, flags=0 pltenter: symname=setvbuf, st_value=0x7f89ce591e00, ndx=1882, flags=0 symbind64: symname=__cxa_atexit, st_value=0x7f89ce557d20, ndx=815, flags=0 pltenter: symname=__cxa_atexit, st_value=0x7f89ce557d20, ndx=815, flags=0 pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0 symbind64: symname=fork, st_value=0x7f89ce5f0250, ndx=411, flags=0 pltenter: symname=fork, st_value=0x7f89ce5f0250, ndx=411, flags=0 symbind64: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0 pltenter: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0 symbind64: symname=alarm, st_value=0x7f89ce5f0110, ndx=1347, flags=0 pltenter: symname=alarm, st_value=0x7f89ce5f0110, ndx=1347, flags=0 pltenter: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0 symbind64: symname=waitpid, st_value=0x7f89ce5eff70, ndx=1674, flags=0 pltenter: symname=waitpid, st_value=0x7f89ce5eff70, ndx=1674, flags=0 symbind64: symname=strsignal, st_value=0x7f89ce5af0d0, ndx=176, flags=0 pltenter: symname=strsignal, st_value=0x7f89ce5af0d0, ndx=176, flags=0 symbind64: symname=printf, st_value=0x7f89ce576200, ndx=603, flags=0 pltenter: symname=printf, st_value=0x7f89ce576200, ndx=603, flags=0 Didn't expect signal from child: got `Illegal instruction' symbind64: symname=exit, st_value=0x7f89ce557ad0, ndx=128, flags=0 pltenter: symname=exit, st_value=0x7f89ce557ad0, ndx=128, flags=0 objclose objclose objclose objclose Notice the: "Didn't expect signal from child: got `Illegal instruction'" version: 1 objopen: 0, objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/ld-linux-x86-64.so.2 activity: add objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod4a.so, LA_SET_ORIG objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod4a.so objsearch: libc.so.6, LA_SET_ORIG objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6, LA_SER_LIBPATH objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6 activity: consistent symbind64: symname=__libc_start_main, st_value=0x7fba692eefd0, ndx=2118, flags=0 pltenter: symname=__libc_start_main, st_value=0x7fba692eefd0, ndx=2118, flags=0 preinit symbind64: symname=mallopt, st_value=0x7fba69359a60, ndx=1784, flags=0 pltenter: symname=mallopt, st_value=0x7fba69359a60, ndx=1784, flags=0 symbind64: symname=getopt_long, st_value=0x7fba693c2900, ndx=1439, flags=0 pltenter: symname=getopt_long, st_value=0x7fba693c2900, ndx=1439, flags=0 symbind64: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0 pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0 symbind64: symname=strtoul, st_value=0x7fba6930be80, ndx=1172, flags=0 pltenter: symname=strtoul, st_value=0x7fba6930be80, ndx=1172, flags=0 pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0 symbind64: symname=setvbuf, st_value=0x7fba69344e00, ndx=1882, flags=0 pltenter: symname=setvbuf, st_value=0x7fba69344e00, ndx=1882, flags=0 symbind64: symname=__cxa_atexit, st_value=0x7fba6930ad20, ndx=815, flags=0 pltenter: symname=__cxa_atexit, st_value=0x7fba6930ad20, ndx=815, flags=0 pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0 symbind64: symname=fork, st_value=0x7fba693a3250, ndx=411, flags=0 pltenter: symname=fork, st_value=0x7fba693a3250, ndx=411, flags=0 symbind64: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0 pltenter: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0 symbind64: symname=alarm, st_value=0x7fba693a3110, ndx=1347, flags=0 pltenter: symname=alarm, st_value=0x7fba693a3110, ndx=1347, flags=0 pltenter: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0 symbind64: symname=waitpid, st_value=0x7fba693a2f70, ndx=1674, flags=0 pltenter: symname=waitpid, st_value=0x7fba693a2f70, ndx=1674, flags=0 symbind64: symname=strsignal, st_value=0x7fba693620d0, ndx=176, flags=0 pltenter: symname=strsignal, st_value=0x7fba693620d0, ndx=176, flags=0 symbind64: symname=printf, st_value=0x7fba69329200, ndx=603, flags=0 pltenter: symname=printf, st_value=0x7fba69329200, ndx=603, flags=0 Didn't expect signal from child: got `Illegal instruction' symbind64: symname=exit, st_value=0x7fba6930aad0, ndx=128, flags=0 pltenter: symname=exit, st_value=0x7fba6930aad0, ndx=128, flags=0 objclose objclose objclose objclose Similarly for tst-audit4. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz stepping : 5 microcode : 0x11 cpu MHz : 1995.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm dtherm tpr_shadow vnmi flexpriority ept vpid bugs : bogomips : 5066.89 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: There are 16 processors. Perhaps we have avx instruction leakage into the dynamic loader? This is a serious issue that needs review.
As Joseph explained in the upstream bug, the tests is invalid. We tell GCC to use instructions the host does not support: AVX-CFLAGS=-mavx -mno-vzeroupper CFLAGS-tst-audit4.c += $(AVX-CFLAGS) CFLAGS-tst-auditmod4a.c += $(AVX-CFLAGS) CFLAGS-tst-auditmod4b.c += $(AVX-CFLAGS) CFLAGS-tst-auditmod6b.c += $(AVX-CFLAGS) CFLAGS-tst-auditmod6c.c += $(AVX-CFLAGS) CFLAGS-tst-auditmod7b.c += $(AVX-CFLAGS) ifeq (yes,$(config-cflags-avx512)) AVX512-CFLAGS = -mavx512f CFLAGS-tst-audit10.c += $(AVX512-CFLAGS) CFLAGS-tst-auditmod10a.c += $(AVX512-CFLAGS) CFLAGS-tst-auditmod10b.c += $(AVX512-CFLAGS) endif endif And it turns out that sufficiently new GCC makes use of this permission. I'm downgrading the urgency. We need to fix this, but it is not a release blocker. I'm going to ask for advice what we can do so that GCC can use the built-ins, but will not generate code for the new instructions.
(In reply to Florian Weimer from comment #2) > I'm downgrading the urgency. We need to fix this, but it is not a release > blocker. Agreed. > I'm going to ask for advice what we can do so that GCC can use the > built-ins, but will not generate code for the new instructions. This test needs to be marked UNSUPPORTED if the host lacks the instructions to execute it, just like C++ tests etc.
(In reply to Carlos O'Donell from comment #3) > > I'm going to ask for advice what we can do so that GCC can use the > > built-ins, but will not generate code for the new instructions. > > This test needs to be marked UNSUPPORTED if the host lacks the instructions > to execute it, just like C++ tests etc. Not host, but target rather (clarification required for cross-compiling).
(In reply to Carlos O'Donell from comment #3) > (In reply to Florian Weimer from comment #2) > > I'm downgrading the urgency. We need to fix this, but it is not a release > > blocker. > > Agreed. > > > I'm going to ask for advice what we can do so that GCC can use the > > built-ins, but will not generate code for the new instructions. > > This test needs to be marked UNSUPPORTED if the host lacks the instructions > to execute it, just like C++ tests etc. There already is a run-time CPU feature test which causes the actual testing to be skipped if the CPU lacks the required micro-architecture support. This should be good enough. It doesn't work because it runs too late. Our test harness currently does not support marking tests as UNSUPPORTED at run time, unfortunately. It's just not powerful enough. Related gcc-help query: https://gcc.gnu.org/ml/gcc-help/2016-03/msg00003.html
(In reply to Florian Weimer from comment #5) > (In reply to Carlos O'Donell from comment #3) > > (In reply to Florian Weimer from comment #2) > > > I'm downgrading the urgency. We need to fix this, but it is not a release > > > blocker. > > > > Agreed. > > > > > I'm going to ask for advice what we can do so that GCC can use the > > > built-ins, but will not generate code for the new instructions. > > > > This test needs to be marked UNSUPPORTED if the host lacks the instructions > > to execute it, just like C++ tests etc. > > There already is a run-time CPU feature test which causes the actual testing > to be skipped if the CPU lacks the required micro-architecture support. > This should be good enough. It doesn't work because it runs too late. > > Our test harness currently does not support marking tests as UNSUPPORTED at > run time, unfortunately. It's just not powerful enough. It does support UNSUPPORTED at run time. You must exit with reserved code 77 and scripts/evaluate-test.sh will mark it UNSUPPORTED. The test can do whatever testing it needs to determine at runtime (on the target) if it's unsupported.
Patch posted upstream: https://sourceware.org/ml/libc-alpha/2016-03/msg00147.html
glibc-2.22-15.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-68abc0be35
glibc-2.22-15.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-68abc0be35
New 2.23 backports: commit 4cf055a2a331b7361622dc9ac8993b59c6f0ef59 Author: Florian Weimer <fweimer> Date: Fri Mar 25 11:11:42 2016 +0100 tst-audit10: Fix compilation on compilers without bit_AVX512F [BZ #19860] [BZ# 19860] * sysdeps/x86_64/tst-audit10.c (avx512_enabled): Always return zero if the compiler does not provide the AVX512F bit. (cherry picked from commit f327f5b47be57bc05a4077344b381016c1bb2c11) commit d603d94994a1d326ebc9e93c8be892acc834a114 Author: Roland McGrath <roland.com> Date: Tue Mar 8 12:31:13 2016 -0800 Fix tst-audit10 build when -mavx512f is not supported. (cherry picked from commit 3bd80c0de2f8e7ca8020d37739339636d169957e) commit 7fa9775594b1592dfcdad5bc32ea449882ca9d9a Author: Florian Weimer <fweimer> Date: Mon Mar 7 16:00:25 2016 +0100 tst-audit4, tst-audit10: Compile AVX/AVX-512 code separately [BZ #19269] This ensures that GCC will not use unsupported instructions before the run-time check to ensure support. (cherry picked from commit 3c0f7407eedb524c9114bb675cd55b903c71daaa)
glibc-2.23.1-6.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74
glibc-2.22-15.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
glibc-2.23.1-6.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74
glibc-2.23.1-7.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74
glibc-2.23.1-7.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74
glibc-2.23.1-7.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.