User Details
- User Since
- Jun 28 2018, 11:39 AM (247 w, 9 h)
Yesterday
Thanks! This indeed fixes the issue I'm seeing.
This seems to cause a regression on Linux where we no longer get the signal details.
Tue, Mar 21
Can you add a regression test that invokes lldb -o "script data=lldb.SBData(); data.SetDataFromUInt64Array([2**63])"? Just a simple shell test should suffice.
Seems like most xml-based tests like this are in lldb/test/API/functionalities/gdb_remote_client, is there a reason this is not in that package too?
Mon, Mar 20
Fri, Mar 17
We're still seeing issues with this at trunk, even after the followup assertion fix in 874c49f55454cb285282e6d184f809945c0beca1.
Tue, Mar 7
5195e14bc1222e1b3f1b7b43c04e1c1ac3504cb1 just landed the same thing as this, although it didn't put it in the sorted order. Feel free to land this if you remove the other entry.
Fri, Mar 3
Thu, Mar 2
Wed, Mar 1
Thanks! This seems to fix all the errors I was seeing before.
see: D145129
Thanks!
I think the issue is:
+ // Byte shifts can be slower so only match them on second attempt. + if (Order == 0 && + (Shuffle == X86ISD::VSHLDQ || Shuffle == X86ISD::VSRLDQ)) + continue;It comes before the check of
+ if (0 < ShiftAmt && (!ShuffleVT.is512BitVector() || Subtarget.hasBWI() || + 32 <= ShuffleVT.getScalarSizeInBits())) { + PermuteImm = (unsigned)ShiftAmt; + return true; + }and the 0 < ShiftAmt check if basically a check if actually found/set Shuffle.
Don't think the bug actually can change behavior but is bug none the less.Will post patch to fix.
After this patch, I see an msan issue running this test internally; strangely I don't see a failure on any sanitizer buildbot yet.
Here's one change this patch causes on "real" code (invalid code, but something a user might try to compile): we see is a static_assert in gmock that now fails to report a useful error message: https://godbolt.org/z/sPr1PYT9d
Tue, Feb 28
- Fix comment typo
Mon, Feb 27
Thu, Feb 23
This has already been reverted, but I found a breakage (not a crash) caused by this:
#include <type_traits>
All the things that were broken before are no longer broken, so LGTM
Wed, Feb 22
The total impact for us is ~400 files, but very trivial in most cases, and usually only a couple impacted lines per file.
Feb 14 2023
It isn't an option for us, but I don't think it's worth it to keep a non-conformant extension + complexity in libc++ just so we can avoid a little boilerplate to do tuple->pair manually in a couple places.
Feb 13 2023
The only other breakage I found so far that might be worthy of mention is that constructing containers requires begin/end iterators of pairs, not tuples, but frameworks for doing functional-style programming often tuples to be fully generic, so this breaks. This seems like an intended effect of this patch, but makes things a little less ergonomic. Is there an idiomatic way to do that w/o having to write your own tuple->pair boilerplate?
Still chugging away, looks like this is going to be at least 50 breakages. Most of them are trivial to fix (e.g. return std::make_tuple() in a method returning std::pair should be return std::make_pair()). There are a few that are a little surprising, such as this one which doesn't seem related to tuple compatibility:
Feb 9 2023
Feb 3 2023
Feb 2 2023
Hi, me again :)
Feb 1 2023
Jan 31 2023
The ABI tag approach fixes the ODR issue I was looking at
Jan 26 2023
Jan 25 2023
Not a breakage report, but just a comment in case it wasn't expected/intended: it looks like this increases the conformance requirement for custom iterators passed to std::copy and friends. From a couple tests, it seems like gcc/libstdc++ already has stricter requirements than libc++, so the conformance requirement is being matched between libc++ and libstdc++ now. As an example:
Jan 24 2023
Thanks!
Jan 19 2023
I think I see why we don't see this failure internally (maybe), but I'm clueless as to why the buildkite builder or local builds don't complain. Anyway, thanks!
Jan 17 2023
Jan 13 2023
LGTM
Jan 12 2023
Jan 11 2023
This looks like a nice improvement! Just one thing I noticed.
- Remove redundant comment
- Move annotations to a separate package entirely
Jan 6 2023
Jan 3 2023
I still see one behavior change (actually it was there before, but I missed it in the test results), but as far as I can tell, it's a good one? If I reduce it too much, I get the warning with the baseline toolchain, so it's not erroneous AFAICT. Although I won't pretend I know all the intricacies of static and inline.
// a.h static const std::pair<double, double>& GetFakePair() { static constexpr std::pair<double, double> kFakePair = {123.0, 456.0}; return kFakePair; }
If you want to keep this test but just not run it by default, can you put it in a separate target that the build bot doesn't run? I guess it's up to you.
Dec 29 2022
I threw this at the "test everything" test (some millions of targets) and it found only one breakage, so this is very very close. Without further ado, here is this silly looking thing:
Dec 28 2022
I'm not sure what to make of the new failure when I try it out this time. Given a source like this:
#include <functional>
All good now! The latest revision of this patch doesn't seem to break anything, unless I ran our tests wrong. From my perspective this is OK to reland now.
Dec 22 2022
Glad the test case made sense to you, it was convoluted to me :)
Dec 21 2022
ping :)
Dec 20 2022
Sorry for the delay, I was out on vacation for a bit. I have a repro for this new issue now:
Dec 15 2022
I applied this version of the patch and the crash is now gone 🎉
This is causing a test failure: https://buildkite.com/llvm-project/upstream-bazel/builds/48607#0185190c-43f8-43ff-b8bd-fa8ce0b6e2f5
(and likewise running ninja check-clang-unit locally, but I don't have a buildbot link to that)
I'm not sure what the libcxx failure was that caused you to revert this, but we also saw a clang crasher as a result of this. clang/lib/AST/Decl.cpp:4300 in unsigned int clang::FieldDecl::getBitWidthValue(const ASTContext &) const: isBitField() && "not a bitfield". I'll try to reduce it.
Dec 14 2022
Here's a well-formed reproducer:
Actually, that assertion failure is pre-existing. However, this is newly failing in a no-asserts clang, so I wonder if something about this patch is just surfacing an existing bug in clang. Anyway, I hope to have a better repro by EOD.
Ugh, I left cvise running overnight and forgot to include the validity check by building with a previous clang, so my reduction is invalid. I'm going to run it again, but here's the invalid crasher in the meantime:
Dec 13 2022
Looks like the latest reland still has some issue remaining. With asserts enabled, I get: assert.h assertion failed at clang/include/clang/AST/Type.h:752 in const ExtQualsTypeCommonBase *clang::QualType::getCommonPtr() const: !isNull() && "Cannot retrieve a NULL type pointer". I'm going to work on reducing it now.