- User Since
- Feb 9 2017, 3:56 PM (135 w, 6 d)
Fri, Sep 6
It's just that it seemed weird/hacky to use asm just to stick assembler directives in the middle of the generated code instead of actual assembly, so I generated an assembly version and cleaned it up a bit. I'm happy to go back to the original shorter C++ version if that's not a concern.
Added a test case that seems to work well with the existing testing setup if I rebuild LLVM with ASan enabled. I have checked out other usages of .cfi_* directives in other LLVM assembly test files and they seem to run them through some llvm tool with -triple <something including linux>, so I have added a REQUIRES: linux line to avoid breakage.
Fri, Aug 30
Looking into how to add a test now. I'm not familiar at all with libunwind code, so I have no idea how to cause this leak to happen from the outside (and then the test would only work when running under asan). Any pointers would be much appreciated.
Wed, Aug 28
Aug 2 2019
FYI we have detected a 2-3% performance regression on Haswell machines in test-suite/MicroBenchmarks/ImageProcessing/Interpolation that seems to be caused by this commit.
Jun 7 2019
Jun 6 2019
Hm, I just realized I'm undoing https://reviews.llvm.org/D58883.
About %T not working for "process launch", what about something like RUN: %lldb -b --one-line-before-file "process launch --stdout %T/x86-zmm-write.out" -s %s %t and then FileCheck-ing?
May 23 2019
May 22 2019
May 9 2019
Removed trailing blank lines from test case, will commit now. Thanks for the review!
Added a new test that checks that, when a full path to a compiler is specified:
May 8 2019
Apr 26 2019
Apr 22 2019
Thanks for the fix!
Apr 16 2019
Thanks! Please let me know if it happens again and I'll try my best to debug it.
Apr 3 2019
Increased wait time in test binary for TestVSCode_attach.py from 5 to 10 seconds.
Apr 2 2019
Apr 1 2019
Mar 26 2019
Mar 14 2019
I considered assigning it to a std::string, but GetCString() can return a null pointer and I'm not sure you can construct a std::string directly from that.
Mar 13 2019
Feb 15 2019
Feb 14 2019
Jan 14 2019
Jan 9 2019
I reverted this patch on r350787
Jan 8 2019
I think this change just broke the clang build:
Jan 7 2019
Nov 21 2018
Folded the two test cases (capturing an invalid type and capturing an invalid array type) into a single file.
Nov 20 2018
Added a test for the "capturing an array of incomplete type" case. See also responses to inline comments below.
Nov 14 2018
Fixed some issues pointed out in review comments:
- call to getBaseElementType before checking type validity.
- when the type is incomplete, mark not only the lambda closure type as invalid but also the field
Nov 8 2018
Nov 7 2018
Sep 21 2018
Sep 19 2018
Aug 17 2018
I think this change is breaking one of our builds. The attached reduced test case fails with the current trunk revision if built with "clang -x c -O2 -mavx -c crash.ii".