- User Since
- Sep 24 2018, 3:51 AM (141 w, 6 d)
Fri, Jun 11
Momchil this is the patch to fix what we were talking about. Walking the whole type might be a bit much but it should exit early 99% of the time.
Though globalisel doesn't crash with the reported snippet, it does crash on the added tests when we spill to memory. I still need to look into that but I don't think it should block this. (unless the bug reporter turns out to be using globalisel)
Thu, Jun 10
I didn't see any bot fail mails (but that might be intentional?).
+1 to limiting it to new pass manager. (good spot btw, I was very confused why this was failing for me)
Also affecting riscv-v (riscvv?) so I've reverted the change.
Hi @pmatos, this has caused SVE related failures on our AArch64 bot (and probably others):
Wed, Jun 9
If you're using arc it doesn't update the description for you unfortunately. (I wish it did) You can "edit revision" and change it there, but either way the message that you push with is the one that ends up in the repo, the phab one is just for phab.
You should mention in the commit msg that this also removes the libcxx bot names, which moved to buildkite a while ago.
1 failure on MacOS "lldb-api :: commands/register/register/register_command/TestRegisters.py", http://green.lab.llvm.org/green/blue/organizations/jenkins/lldb-cmake/detail/lldb-cmake/32693/pipeline/, hence the revert.
Tue, Jun 8
I've gone ahead and landed it, will revert on failures.
Yes moving the bots to clang 12 did the trick.
Mon, Jun 7
Fri, Jun 4
I can run this for you on macOS and Linux x86 which I think should cover every test.
There are likely other tests that aren't enabled for x86/AArch64 or sets of registers that I don't have on my machines. So if this change is welcome then the plan would be to land this as is and monitor the bots for a week or so, revert and reland with test fixups as needed.
LGTM; any additional thoughts @DavidSpickett ?
Thu, Jun 3
The side effect here is that you do "memory read <tagged ptr>" and you see untagged addresses for the lines. It's not really that confusing but maybe something we should make a general decision about.
Use thumb feature instead.
Wed, Jun 2
Back to green https://lab.llvm.org/buildbot/#/builders/43/builds/6834, thanks!
I have implemented that requires for Arm in https://reviews.llvm.org/D103512.
Since this change LLVM :: Analysis/CostModel/AArch64/bitreverse.ll is failing.
This test is failing on our v7 bot: https://lab.llvm.org/buildbot/#/builders/59/builds/1938
Instead of adding CPUs to llvm, remove them from clang.
$ cat /tmp/test.s irg x0, x0 $ aarch64-unknown-linux-gnu-as -march=armv8.5-a+memtag -march=armv8.1-a /tmp/test.s -o /dev/null /tmp/test.s: Assembler messages: /tmp/test.s:1: Error: selected processor does not support `irg x0,x0'
I understand it's a little bit confusing here, but I was simply trying to match GCC's behavior (please see the example in my last comment) unless I misunderstood its output. I definitely agree having consistent behaviors between Arm and Aarch64 in Clang is more reasonable (in fact that was what I implemented at first) and maybe we should fork from gcc, WDYT?
Tue, Jun 1
https://lab.llvm.org/buildbot/#/builders/26/builds/2096, the sanitizer-common test needs to be handled in its own way since it's disabling things itself.
We have the same test failing on thumb because the fast unwinder doesn't (can't, for various reasons) work. Perhaps:
// REQUIRES: fast-unwinder-works
Thanks for taking this up! I never got the time for it.
Wed, May 26
One thing that you might think of would be the top bits set for kernel alloations. However if we're using the masks and TBI correctly those will be left intact.
Rebase, fix up SendPacketAndWaitForResponse use.
I was looking at the wrong file, this adds the header.
Rebase, which brings in the header pcc mentioned.
Resigning to remove my requested changes, if that works. Looks good from my point of view.
I realised my mistake, I thought this was adding a new core file but in fact it's using the one you added for the register tests. So now the outfile is there the test passes.
Tue, May 25
You could argue that one of them is actually "unused" but I tried -march which also takes the last value and that does not warn when it ignores earlier values.
David, could you please route that bug to whoever is now responsible for leading that group?
@nickdesaulniers Can you confirm whether the kernel CI report you got was intentionally setting armv3m? If the build isn't setting an mcpu then removing the CPUs won't actually break it, though what it generates likely wouldn't run correctly.
Mon, May 24
@nickdesaulniers With this you won't get warnings for https://github.com/ClangBuiltLinux/linux/issues/921.
GCC also doesn't recognise it: https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/ARM-Options.html