Summary: | www-client/chromium-107.0.5304.29: AVX vector return of type '__m512' (vector of 16 'float' values) without 'avx512f' enabled changes the ABI | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Zoltan Puskas <zoltan> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ashley.blue.skye, mattst88 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Compressed build.log |
Description
Zoltan Puskas
2022-10-26 22:30:51 UTC
Please attach the full build.log. Created attachment 825545 [details]
Compressed build.log
Raw build log is 101MB in size, and gz or bz2 were insufficient, so I had to compress it with zstd to fit into the 1000kB limit.
This build log comes from my last ditch attempt with custom-cflags enabled (in the hopes that -mno-avx512f would maybe help, since my CPU has no AVX512 instructions), but the error is exactly the same as when I built it with the default USE flags previously.
> System uname: Linux-6.0.0-gentoo-x86_64-x86_64-Intel-R-_Core-TM-_i7-8650U_CPU_@_1.90GHz-with-glibc2.36 > ... > -march=broadwell 8650U is a Kaby Lake, but -march=broadwell is fine because there are basically no differences between it and -march=skylake (which would be the closest thing to Kaby Lake) > -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -msgx -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid Why do you think you need all this? -march=broadwell turns on/off these for you. Specifying -mno-* flags basically only serves to break runtime-enabled code that uses specific instruction set features (like what I suspect is happening here). > -mtune=generic Now you've *completely* lost me. Since I use distcc, and my build box is of a different model, I need to be explicit about my CFLAGS. When I set up my machine back in 2017, I've used the $ gcc -v -E -x c /dev/null -o /dev/null -march=native 2>&1 | grep /cc1 | grep mtune trick to obtain the CFLAGS, that's why I have what I have there. I'll change the CLFAGS to -march=skylake -mabm --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=8192 that I've obtained from app-misc/resolve-march-native just now, and will retry the build and see if I get a different result. I'll report back with the results once the build has finished/failed. I've retried with the new CFLAGS, and it has successfully finished the build. It seems the problem was my overly specific ancient compiler flags that I've obtained years ago from a previous version of GCC. We need to add something like -mno-avx512* to the filter-flags list. (In reply to Stephan Hartmann from comment #6) > We need to add something like -mno-avx512* to the filter-flags list. We can, but people putting -mno-* in their CFLAGS is a problem across all of ::gentoo. (In reply to Stephan Hartmann from comment #6) > We need to add something like -mno-avx512* to the filter-flags list. I think filtering -mno-xxx flags is a probably a bad idea, and we should probably stop doing it in the chromium ebuild. For example see bug 863563. The user has an ivybridge chip which is supposed to support AVX2, but this specific variant of the chip actually lacks support for AVX2 instructions. Blame Intel for the inconsistency I guess. If we filter -mno-avx2 and similar flags, the compiler may end up generating invalid opcodes for the user's system. Currently, the only workaround is for the user to pick less featureful -march setting. (In reply to Mike Gilbert from comment #8) > (In reply to Stephan Hartmann from comment #6) > > We need to add something like -mno-avx512* to the filter-flags list. > > I think filtering -mno-xxx flags is a probably a bad idea, and we should > probably stop doing it in the chromium ebuild. > > For example see bug 863563. The user has an ivybridge chip which is supposed > to support AVX2, but this specific variant of the chip actually lacks > support for AVX2 instructions. Blame Intel for the inconsistency I guess. > > If we filter -mno-avx2 and similar flags, the compiler may end up generating > invalid opcodes for the user's system. > > Currently, the only workaround is for the user to pick less featureful > -march setting. nodejs does runtime CPU features detection: https://github.com/nodejs/node/blob/main/deps/base64/base64.gyp#L41 Again the build systems adds -mavx2 and the user overwrites with -mno-avx2. A possible workaround is to force inside the sources with "#pragma GCC target ...". But I don't think it is upstreamable. *** Bug 890593 has been marked as a duplicate of this bug. *** |