| Summary: | libgcc's __cpu_indicator_init does not check for avx correctly | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Andy Lutomirski <luto> |
| Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | areg.melikadamyan, hjl.tools, izamyatin, noloader, ubizjak |
| Priority: | P3 | ||
| Version: | 4.8.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2012-11-13 00:00:00 | |
GCC 4.8.0 is being released, adjusting target milestone. GCC 4.8.1 has been released. GCC 4.8.2 has been released. Forgive my ignorance... Is __builtin_cpu_supports really __builtin_os_supports? If we want to test CPU support (rather than OS support), then can it be done with the built-ins? Also, the documentation at https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/X86-Built-in-Functions.html does not mention that this is in fact OS support, and not CPU support. This was fixed in #85100. Dup. |
[this is a libgcc bug, and I haven't tested it -- the test is a PITA.] One might expect that __builtin_cpu_supports("avx") would only return true if avx is usable. Unfortunately, it returns true iff avx is implemented by the cpu, regardless of whether it should be expected to work. The code should check for osxsave and then use xgetbv to see if ymm state is available. This is more or less the same bug as glibc bug 13007 [1]. There's an intel blog post on the subject at [2]. It's likely to result in crashes if old kernels are run on new hardware. Curiously, the code in gcc/testsuite/gcc.target/i386/avx-check.h appears correct. I suspect it's never been run with ymm state disabled. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=13007 [2] http://software.intel.com/en-us/blogs/2011/04/14/is-avx-enabled/