Bug 1313404
Summary: | Test suite failure: elf/tst-audit10 and elf/tst-audit4 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Carlos O'Donell <codonell> |
Component: | glibc | Assignee: | Florian Weimer <fweimer> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | arjun.is, codonell, dj, fweimer, jakub, law, mfabian, pfrankli, siddhesh |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | glibc-2.22-15.fc23, glibc-2.23.1-7.fc24 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-15 04:58:02 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Carlos O'Donell
2016-03-01 14:38:31 UTC
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. |