I first noticed this issue very early Tuesday morning but have only gotten around to finishing collecting logs and reporting this issue now. I'm going to lay this out step by step to make things clear. In a WSL 2 instance under: - Host OS platform and version: Windows 11 Pro 23H2, build 22631.3527. - 'Experience:' Windows Feature Experience Pack v1000.22700.1003.0 - ```PowerShell PowerShell 7.4.2 PS …> wsl --version WSL version: 2.1.5.0 Kernel version: 5.15.146.1-2 WSLg version: 1.0.60 MSRDC version: 1.2.5105 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp ⁝ # (Snipped…) PS …> wsl --distribution Gentoo -- uname -srvmpio Linux 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz GenuineIntel GNU/Linux ``` when you're using Clang as your system compiler. Have at least the following under `/etc/portage`: - For `make.conf`: ``` # These settings were set by the catalyst build script that automatically # built this stage. # Please consult /usr/share/portage/config/make.conf.example for a more # detailed example. COMMON_FLAGS="-march=native -mtune=native -O2 -pipe" CFLAGS="${COMMON_FLAGS} -flto=thin" CXXFLAGS="${COMMON_FLAGS} -flto=thin" FCFLAGS="${COMMON_FLAGS}" FFLAGS="${COMMON_FLAGS}" # '`-O2`' in '`LDFLAGS`' refers to binary size optimization during linking; it is _not_ related to the compiler's '`-O`' levels. LDFLAGS="-fuse-ld=lld -rtlib=compiler-rt -unwindlib=libunwind -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now" # NOTE: This stage was built with the bindist Use flag enabled PORTDIR="/var/db/repos/gentoo" DISTDIR="/var/cache/distfiles" PKGDIR="/var/cache/binpkgs" # This sets the language of build output to English. # Please keep this setting intact when reporting bugs. LC_MESSAGES=C USE="clang llvm-libunwind" CC="clang" CXX="clang++" AR="llvm-ar" NM="llvm-nm" RANLIB="llvm-ranlib" MAKEOPTS="-j4" INPUT_DEVICES="evdev" # `PERL_FEATURES` may contain zero or more of `debug`, `ithreads`, and/or `quadmath`. PERL_FEATURES="" ACCEPT_KEYWORDS="${ACCEPT_KEYWORDS} amd64 ~amd64" ``` - Under `env/`, at least the following environment files: - `compiler-clang-no-lld`: ``` CC="clang" CXX="clang++" AR="llvm-ar" NM="llvm-nm" RANLIB="llvm-ranlib" COMMON_FLAGS="-march=native -mtune=native -O2 -pipe" CFLAGS="${COMMON_FLAGS}" CXXFLAGS="${COMMON_FLAGS}" LDFLAGS="-fuse-ld=ld --ld-path=/usr/bin/ld -rtlib=compiler-rt -unwindlib=libunwind -Wl,--as-needed -Wl,-z,relro,-z,now" USE="clang llvm-libunwind" ``` - At least the following lines in `package.env` (I have them at the top:) ``` ## Needed for a first pass when building or updating LLVM and friends, after which a second pass is needed to rebuild against the newly built `lld`; otherwise, these packages fail to link due to linker and linkage versioning issues: # sys-devel/llvm-common compiler-clang-no-lld # sys-devel/llvm compiler-clang-no-lld # sys-devel/llvm-toolchain-symlinks compiler-clang-no-lld # sys-devel/clang-common compiler-clang-no-lld # sys-devel/clang compiler-clang-no-lld # sys-devel/clang-toolchain-symlinks compiler-clang-no-lld # sys-libs/compiler-rt compiler-clang-no-lld # sys-libs/compiler-rt-sanitizers compiler-clang-no-lld # sys-devel/clang-runtime compiler-clang-no-lld # sys-devel/lld compiler-clang-no-lld # sys-devel/lld-toolchain-symlinks compiler-clang-no-lld # sys-libs/libcxx compiler-clang-no-lld # sys-libs/libcxxabi compiler-clang-no-lld # sys-libs/llvm-libunwind compiler-clang-no-lld # sys-libs/libomp compiler-clang-no-lld # dev-debug/lldb compiler-clang-no-lld # dev-libs/libclc compiler-clang-no-lld ``` - Under `package.mask/`: - In `LLVM-toolchain`: ``` <sys-devel/llvm-common-17.0.0 <sys-devel/llvm-17.0.0 <sys-devel/llvm-toolchain-symlinks-17 <sys-devel/clang-common-17.0.0 <sys-devel/clang-17.0.0 <sys-devel/clang-toolchain-symlinks-17 <sys-libs/compiler-rt-17.0.0 <sys-libs/compiler-rt-sanitizers-17.0.0 <sys-devel/clang-runtime-17.0.0 <sys-devel/lld-17.0.0 <sys-devel/lld-toolchain-symlinks-17 <sys-libs/libcxx-17.0.0 <sys-libs/libcxxabi-17.0.0 <sys-libs/llvm-libunwind-17.0.0 <sys-libs/libomp-17.0.0 <dev-util/lldb-17.0.0 <dev-libs/libclc-17.0.0 ``` (Likely not relevant to this issue, but I've listed it for completeness's sake. These would all mask `<18.0.0` or `<18` instead, but I still have some packages that dpeend on LLVM and friends v17.x, last I checked. I should go back and review that at some point soon, but, again, this isn't relevant here. Anyway, I bump these every time a new LLVM toolchain suite version has been released and I no longer have any packages that depend on the previous version.) - Under `pakcage.use/`: - For `LLVM-toolchain`: ``` sys-devel/llvm xar zstd sys-devel/clang-common default-compiler-rt default-lld llvm-libunwind -cet sys-libs/libcxx llvm-libunwind sys-libs/libcxxabi llvm-libunwind sys-devel/clang-runtime libcxx sys-devel/lld zstd dev-debug/lldb lzma -libedit sys-libs/llvm-libunwind static-libs sys-libs/libomp llvm_targets_NVPTX dev-libs/libclc -video_cards_radeonsi video_cards_nvidia ``` (`sys-devel/clang-common`'s `-cet` is left over from the otherwise-unrelated <https://bugs.gentoo.org/927652>.) Before the update when you still have a a previous version of `sys-devel/llvm`, such as 18.1.4: 1.) Change the lines I showed from `/etc/portage/package.env` above so that they're all uncommented as hence now read as follows: ``` # Needed for a first pass when building or updating LLVM and friends, after which a second pass is needed to rebuild against the newly built `lld`; otherwise, these packages fail to link due to linker and linkage versioning issues: sys-devel/llvm-common compiler-clang-no-lld sys-devel/llvm compiler-clang-no-lld sys-devel/llvm-toolchain-symlinks compiler-clang-no-lld sys-devel/clang-common compiler-clang-no-lld sys-devel/clang compiler-clang-no-lld sys-devel/clang-toolchain-symlinks compiler-clang-no-lld sys-libs/compiler-rt compiler-clang-no-lld sys-libs/compiler-rt-sanitizers compiler-clang-no-lld sys-devel/clang-runtime compiler-clang-no-lld sys-devel/lld compiler-clang-no-lld sys-devel/lld-toolchain-symlinks compiler-clang-no-lld sys-libs/libcxx compiler-clang-no-lld sys-libs/libcxxabi compiler-clang-no-lld sys-libs/llvm-libunwind compiler-clang-no-lld sys-libs/libomp compiler-clang-no-lld dev-debug/lldb compiler-clang-no-lld dev-libs/libclc compiler-clang-no-lld ``` 2.) Run: ``` emerge --verbose --update --oneshot --newuse --changed-slot=y --with-bdeps=y sys-devel/llvm-common sys-devel/llvm sys-devel/llvm-toolchain-symlinks sys-devel/clang-common sys-devel/clang sys-devel/clang-toolchain-symlinks sys-libs/compiler-rt sys-libs/compiler-rt-sanitizers sys-devel/clang-runtime sys-devel/lld sys-devel/lld-toolchain-symlinks sys-libs/libcxx sys-libs/libcxxabi sys-libs/llvm-libunwind sys-libs/libomp dev-debug/lldb dev-libs/libclc ``` This should succeed. Now: 1.) Revert the changes you made to `/etc/portage/package.env` above so that those lines are commented out again. 2.) Run: ``` emerge --verbose --update --oneshot --newuse --changed-slot=y --with-bdeps=y --reinstall-atom="sys-devel/llvm-common sys-devel/llvm:18 sys-devel/llvm-toolchain-symlinks:18 sys-devel/clang-common sys-devel/clang:18 sys-devel/clang-toolchain-symlinks:18 sys-libs/compiler-rt:18 sys-libs/compiler-rt-sanitizers:18 sys-devel/clang-runtime:18 sys-devel/lld:18 sys-devel/lld-toolchain-symlinks:18 sys-libs/libcxx sys-libs/libcxxabi sys-libs/llvm-libunwind sys-libs/libomp dev-debug/lldb dev-libs/libclc" sys-devel/llvm-common sys-devel/llvm sys-devel/llvm-toolchain-symlinks sys-devel/clang-common sys-devel/clang sys-devel/clang-toolchain-symlinks sys-libs/compiler-rt sys-libs/compiler-rt-sanitizers sys-devel/clang-runtime sys-devel/lld sys-devel/lld-toolchain-symlinks sys-libs/libcxx sys-libs/libcxxabi sys-libs/llvm-libunwind sys-libs/libomp dev-debug/lldb dev-libs/libclc ``` This should fail with the following error: ``` ⁝ [156/3501] /usr/lib/llvm/18/bin/clang -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm_build-abi_x86_64.amd64/lib/Support/BLAKE3 -I/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm/lib/Support/BLAKE3 -I/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm_build-abi_x86_64.amd64/include -I/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm/include -DNDEBUG -march=native -mtune=native -O2 -pipe -flto=thin -fPIC -mavx512vl -MD -MT lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o -MF lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o.d -o lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o -c /var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm/lib/Support/BLAKE3/blake3_avx512_x86-64_unix.S FAILED: lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o /usr/lib/llvm/18/bin/clang -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm_build-abi_x86_64.amd64/lib/Support/BLAKE3 -I/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm/lib/Support/BLAKE3 -I/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm_build-abi_x86_64.amd64/include -I/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm/include -DNDEBUG -march=native -mtune=native -O2 -pipe -flto=thin -fPIC -mavx512vl -MD -MT lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o -MF lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o.d -o lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_avx512_x86-64_unix.S.o -c /var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm/lib/Support/BLAKE3/blake3_avx512_x86-64_unix.S clang -cc1as: fatal error: error in backend: ZMM registers are not supported without EVEX512 ⁝ ninja: build stopped: subcommand failed. * ERROR: sys-devel/llvm-18.1.5::gentoo failed (compile phase): * ninja -v -j4 -l0 distribution failed * * Call stack: * ebuild.sh, line 136: Called src_compile * environment, line 3871: Called multilib-minimal_src_compile * environment, line 2675: Called multilib_foreach_abi 'multilib-minimal_abi_src_compile' * environment, line 2942: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_compile' * environment, line 2635: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_compile' * environment, line 2633: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_compile' * environment, line 552: Called multilib-minimal_abi_src_compile * environment, line 2669: Called multilib_src_compile * environment, line 3162: Called tc-env_build 'cmake_build' 'distribution' * environment, line 4106: Called cmake_build 'distribution' * environment, line 1364: Called eninja 'distribution' * environment, line 1840: Called die * The specific snippet of code: * "$@" || die -n "${*} failed" * * If you need support, post the output of `emerge --info '=sys-devel/llvm-18.1.5::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-devel/llvm-18.1.5::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-devel/llvm-18.1.5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-devel/llvm-18.1.5/temp/environment'. * Working directory: '/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm_build-abi_x86_64.amd64' * S: '/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm' >>> Failed to emerge sys-devel/llvm-18.1.5, Log file: >>> '/var/tmp/portage/sys-devel/llvm-18.1.5/temp/build.log' * Messages for package sys-devel/clang-runtime-18.1.5: * You seem to be using clang as a system compiler. As of clang-16, * upstream has turned a few warnings that commonly occur during * configure script runs into errors by default. This causes some * configure tests to start failing, sometimes resulting in silent * breakage, missing functionality or runtime misbehavior. It is * not yet clear whether the change will remain or be reverted. * * For more information, please see: * https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213 * Messages for package sys-devel/llvm-18.1.5: * ERROR: sys-devel/llvm-18.1.5::gentoo failed (compile phase): * ninja -v -j4 -l0 distribution failed * * Call stack: * ebuild.sh, line 136: Called src_compile * environment, line 3871: Called multilib-minimal_src_compile * environment, line 2675: Called multilib_foreach_abi 'multilib-minimal_abi_src_compile' * environment, line 2942: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_compile' * environment, line 2635: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_compile' * environment, line 2633: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_compile' * environment, line 552: Called multilib-minimal_abi_src_compile * environment, line 2669: Called multilib_src_compile * environment, line 3162: Called tc-env_build 'cmake_build' 'distribution' * environment, line 4106: Called cmake_build 'distribution' * environment, line 1364: Called eninja 'distribution' * environment, line 1840: Called die * The specific snippet of code: * "$@" || die -n "${*} failed" * * If you need support, post the output of `emerge --info '=sys-devel/llvm-18.1.5::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-devel/llvm-18.1.5::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-devel/llvm-18.1.5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-devel/llvm-18.1.5/temp/environment'. * Working directory: '/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm_build-abi_x86_64.amd64' * S: '/var/tmp/portage/sys-devel/llvm-18.1.5/work/llvm' * GNU info directory index is up-to-date. ``` Optionally, after that, run: ``` emerge --verbose --resume ``` This should fail with the same error as before. I'd attach a `.tar.xz` of or link to the full logs, but: 1.) The compressed tarball's too big, at a size of about 124 MB. 2.) GitHub won't let me push the commit adding said logs to my logs repository (at <https://github.com/RandomDSdevel/Gentoo-in-WSL2-emerge-Logs>.) (I guess the packfile Git's generating is too big? I keep getting the message `fatal: the remote end hung up unexpectedly`. Please advise, maybe?)
Oops, forgot to add this to my OP: there's a known upstream issue report for this at <https://github.com/llvm/llvm-project/issues/91076>.
As also noted in <https://bugs.gentoo.org/931623#c16>, upstream has now landed <https://github.com/llvm/llvm-project/pull/91694> as a PR to fix this issue, but only to `main`. Backporting to the LLVM v18.x is still a work-in-progress at the PR <https://github.com/llvm/llvm-project/pull/91705>.
I appreciate there's an upstream fix for this now, but in general, a build.log (compressed if necessary) as an attachment & emerge --info is needed.
Like I said, the logs are too big for either an attachment, even compressed, or to upload to a Git Web host; does a OneDrive share link to the `.tar.gz` work for this? https://1drv.ms/u/s!AkojRV5BNJUozipy-_LMxV2xLPsD?e=274SAZ
(A little bit belatedly:) Some small corrections: In the OP: > Optionally, after that, run: > > ``` > emerge --verbose --resume > ``` > > This should fail with the same error as before. The last sentence should actually read as follows: > This should: > > 1.) successfully resume and continue on to build `sys-devel/clang-common`, then > 2.) fail to build `sys-devel/llvm` with the same error as before. --- > …does a OneDrive share link to the `.tar.gz` work for this? Sorry, a `.tar.xz` is what I actually meant and what that actually is.
Applying the changes from <https://github.com/llvm/llvm-project/pull/91705> as a user patch while waiting for it to get merged doesn't appear to be sufficient. Trying using a new Portage environment with `-mno-evex512` set.
> …Trying using a new Portage environment with `-mno-evex512` set. No luck. …Wait, why's Clang's `-march=native -mtune=native` enabling AVX-512 when my CPU — an Intel Core i9-9880H (Coffee Lake) — only supports a maximum of AVX2? ``` … ~ # clang++ -march=native -mavx512f -dM -E - </dev/null | grep "AVX512" #define __AVX512F__ 1 ``` (Perhaps the same upstream bug(s).) This CPU misdetection is kind of weird. Anyway, I'll try disabling AVX-512 altogether.
Maybe because my current Clang installation was built against LLVM when my copy of that still had the bug in it…?
Lot of packages enable some instructions for specific files regardless of what you support and will check whether it's usable at runtime rather than build time (aka, this works out better to be optionally usable on a binary-only distribution). It's not always easily configurable without modifying the build system and is harmless, so we don't go out of our way to force this off. Also, it's not -mno-evex512 that you need as a workaround, but rather -mevex512 (I know, it's kind of confusing). Worry not, it won't actually enable avx512 in this special case.
> ``` > … ~ # clang++ -march=native -mavx512f -dM -E - </dev/null | grep "AVX512" > #define __AVX512F__ 1 > ``` . .. … (_Head-desks._) The correct invocation, of course, is: ``` … ~ # clang++ -march=native -dM -E - </dev/null | grep "AVX512" #define __AVX512F__ 1 ``` (No output, as is correct and should be expected.)
(In reply to Ionen Wolkens from comment #9) > Also, it's not -mno-evex512 that you need as a workaround, but rather > -mevex512 (I know, it's kind of confusing). Worry not, it won't actually > enable avx512 in this special case. Thanks for pointing that out! Yeah, that's unintuitive.
(In reply to Ionen Wolkens from comment #9) > Also, it's not -mno-evex512 that you need as a workaround, but rather > -mevex512 (I know, it's kind of confusing). Worry not, it won't actually > enable avx512 in this special case. ftr, the workaround that was used in qtwebengine ironically only pass it when avx512 is *not* enabled: use amd64 && tc-is-clang && is-flagq -march=native && [[ $(clang-major-version) -ge 18 ]] && tc-cpp-is-true "!defined(__AVX512F__)" ${CXXFLAGS} && append-flags -mevex512 Should be fixed in 18.1.6 assuming #91705 gets merged, albeit people may not be able to build it using 18.1.5 without the workaround so it'll still be needed either way (could add an upper bound w/ the full version though).
I tried re-`emerge`ing/re-building LLVM and friends again last night with the correct flags and let the job run overnight, and it worked and was done this morning! Thanks, Ionen!
<https://github.com/llvm/llvm-project/pull/91705> was merged yesterday.
I've: - Stopped carrying the upstream fix for this as a user patch now that <https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0e73e8a0f491d248e6a6dacb879ea502c22501a6>'s been merged into `::gentoo`. - Removed the temporary environment I was using to add `-mevex512` to LLVM's compiler flags with and switched LLVM and friends back to my default environment as defined in my local copy of `/etc/portage/make.conf`. - Successfully updated `sys-devel/llvm` to `18.1.5-r1`. I'd call this issue resolved.
(In reply to Bryce Glover from comment #15) > I've: > > - Stopped carrying the upstream fix for this as a user patch now that > <https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=0e73e8a0f491d248e6a6dacb879ea502c22501a6>'s been merged into `::gentoo`. > > - Removed the temporary environment I was using to add `-mevex512` to > LLVM's compiler flags with and switched LLVM and friends back to my default > environment as defined in my local copy of `/etc/portage/make.conf`. > - Successfully updated `sys-devel/llvm` to `18.1.5-r1`. > > I'd call this issue resolved. Debatable given everyone using the old version have to do a manual workaround to update to the fixed one.
(In reply to Ionen Wolkens from comment #16) > > I'd call this issue resolved. > Debatable given everyone using the old version have to do a manual > workaround to update to the fixed one. Well, "everyone" was a big word, I meant clang ~arch users using -march=native without avx512 that is :)
Having the same issue, thank you for report and the work
(In reply to Ionen Wolkens from comment #16) > Debatable given everyone using the old version have to do a manual > workaround to update to the fixed one. I don't know how the situation regarding this issue could get improved to the point where manual user intervention isn't required. I also wouldn't know if this issue might be something that warranted creating and publishing a new news entry for users who: - have set Clang as their system compiler, either by use of a profile or manually; - have `-march=native` in their compiler flags; and - use systems whose processors don't support AVX-512. --- (In reply to Davide Palma from comment #18) > Having the same issue, thank you for report and the work No problem; you're welcome!
(In reply to Bryce Glover from comment #19) > (In reply to Ionen Wolkens from comment #16) > > Debatable given everyone using the old version have to do a manual > > workaround to update to the fixed one. > I don't know how the situation regarding this issue could get improved to > the point where manual user intervention isn't required. Well, the same way we did it for chromium and qtwebengine:6 should work (users been reporting it's fine), not that I tried it with llvm: use amd64 && tc-is-clang && is-flagq -march=native && [[ $(clang-major-version) -ge 18 ]] && has_version '<sys-devel/llvm-18.1.5-r1' && tc-cpp-is-true "!defined(__AVX512F__)" ${CXXFLAGS} && append-flags -mevex512
(In reply to Ionen Wolkens from comment #20) > Well, the same way we did it for chromium and qtwebengine:6 should work > (users been reporting it's fine), not that I tried it with llvm: (albeit at this point I imagine people been working around it manually, should've been done during the -r1 bump rather than after)
Alternatively there's also the more sledgehammer variant of just stripping -march=native if using an affected version, it's a one-time thing so it wuoldn't be that bad. At least stable, avx512, or gcc users were not affected so scope is still kind of limited.
(In reply to Ionen Wolkens from comment #21) > (albeit at this point I imagine people been working around it manually, > should've been done during the -r1 bump rather than after) Recall that `sys-devel/llvm-18.5.1-r1` as introduced by <https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0e73e8a0f491d248e6a6dacb879ea502c22501a6> includes a backport for the upstream patch from <https://github.com/llvm/llvm-project/pull/91705>. This bug only affected `sys-devel/llvm` at version `-18.1.5` 'r0.' Compiler flags don't need modification any more.
(In reply to Bryce Glover from comment #23) > This bug only affected `sys-devel/llvm` at version `-18.1.5` 'r0.' > Compiler flags don't need modification any more. I know, the workaround in comment #20 even has: has_version '<sys-devel/llvm-18.1.5-r1' && So the modification is only done while have -r0. This is about being able to build this -r1 while being stuck with -r0 to build it.
(In reply to Ionen Wolkens from comment #24) > (In reply to Bryce Glover from comment #23) > > This bug only affected `sys-devel/llvm` at version `-18.1.5` 'r0.' > > Compiler flags don't need modification any more. > I know, the workaround in comment #20 even has: > > has_version '<sys-devel/llvm-18.1.5-r1' && > > So the modification is only done while have -r0. This is about being able to > build this -r1 while being stuck with -r0 to build it. (_Head-desks._) Sorry, guess I had a bit of a moment there. I missed reading the relevant finer details of that conditional the first time around. Apologies for the noise.
