- User Since
- Apr 25 2018, 1:47 PM (143 w, 1 d)
Almost there! Just a few more comments on my end.
Hi. It seems this commit is causing this failure on our aarch64 bulder (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-arm64/b8857452110716658368):
Wed, Jan 20
Also, this probably isn't very important, but just as a heads up: if we were to depend on the environment component in the triple as the flag for selecting which multilib to use, then the multilib would be stored in a directory containing that environment.
Tue, Jan 19
Fri, Jan 15
Locally I'm able to build and run the bringup.arm64 config (that is launch the shell and run some commands).
Thu, Jan 14
Looking good. Just a few more comments on my end.
Tue, Jan 12
Mon, Jan 11
Thu, Jan 7
Dec 21 2020
Dec 7 2020
Ok this time I remembered the email. Unsure why the bug isn't automatically closed though.
Committed in 155fca3cae275562e626d3e4fbfac70b4b75d2e7. (Sorry, I forgot to change the author email in the commit)
Sorry. I accidentally missed this in my emails. Will commit these.
Dec 1 2020
Nov 30 2020
@phosek This shouldn't affect supporting riscv with our toolchain, right?
Nov 25 2020
Thanks for catching this. LGTM
Removed formatting for existing code.
Nov 24 2020
Nov 23 2020
Hi, it seems that p2.cpp is failing on our production builder (https://luci-milo.appspot.com/p/fuchsia/builders/prod/clang-linux-x64/b8862835022166171808):
Nov 19 2020
*ping* any more comments on this patch?
*ping* Any more comments on this patch?
@rjmccall This might've changed a bit since you last accepted the revision. Will wait a couple of days before submitting if you have any more comments on this.
Nov 17 2020
Hi. I suspect it might be this patch or D90984 that might be leading to the test failure we're seeing on our arm64 builders
Welp, it turns out that if I went with the approach of adding the constant manually everywhere the macro was used, I'd be adding a lot of special cases everywhere. The only case I needed to cover was in Core which depends on Value.def:
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-1/llvm/lib/IR/Core.cpp:832:12: note: expanded from macro 'HANDLE_VALUE' return LLVM##Name##ValueKind; ^ <scratch space>:239:1: note: expanded from here LLVMDSOLocalEquivalentValueKind
The only way I could think of preventing the constant from being used here while still being used in other places HANDLE_VALUE/CONSTANT are used is a "banlist" approach via more macros in Value.def. Open to other ideas if it doesn't look that good.
Nov 16 2020
Nov 13 2020
Are there any OpenACC specific tests?
There was an inconsistency in the LLVMBuild.txt for LLVM Frontend: OpenACC wasn't listed but it was part of the CMake infrastructure. A side effect of the llvmbuildectomy has been to remove that inconsistency and register OpenACC as a regular component.
Looking at the error log, there is a missing libLLVMFrontendOpenACC.a
But I cannot see any reference to FrontendOpenACC in the build log, just as if it wasn't build, which is odd.
I failed to reproduce your issue, but does that OpenACC stuff rings any bell? Can you force building that component and see what happens?
Hi, it looks like this might be leading to some test failures on our toolchain builders:
Nov 12 2020
Nov 11 2020
Updated some renamed variables that I didn't check prior.
Nov 6 2020
Updated to use LIT_OPTS.
Nov 5 2020
Abandoned since https://reviews.llvm.org/D90695 fixes this
@MaskRay any more comments?
Nov 3 2020
Unsure if this is the best way to go about it, so open to other solutions.
Nov 2 2020
Oct 27 2020
I'd recommend splitting this into two patches, one for LLVM changes and another for Clang changes.
*ping* for other comments. I'll probably commit this at the end of the week unless others have more to add.
Oct 23 2020
Update to use dso_local_equivalent instead of emitting stubs in the frontend. dso_local_equivalent should emit a stub automatically if one is required for the target (ie. it does not support PLTs).
Oct 19 2020
Updated to use the -fexperimental-relative-c++-ab-vtables flag now that D85802 was reverted. This will be used for the purpose of testing the relative vtables ABI in Fuchsia CQ builders to ensure all tests are run, accounting for flakes. The end goal will involve not having a relative vtables multilib, but instead making it the default for the fuchsia ABI, and instead having a separate Itanium multilib for supporting GCC.