Summary: | sys-devel/llvm-18.1.5 Fails to emerge Using lld Under WSL 2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bryce Glover <RandomDSdevel> |
Component: | Current packages | Assignee: | LLVM support project <llvm> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | dpfuturehacker, ionen, RandomDSdevel |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | https://github.com/llvm/llvm-project/issues/91076 | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=931623 https://github.com/llvm/llvm-project/pull/91705 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Bryce Glover
2024-05-10 03:36:36 UTC
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. |