User Details
- User Since
- Jun 28 2018, 11:39 AM (274 w, 5 d)
Wed, Sep 13
Aug 29 2023
Aug 18 2023
Sorry, I don't want to mislead: I just mean there's a handy example in clang's unit tests. I don't see any instances of this in LLVM non-test code.
The other common breakage I'm seeing is code that hasn't yet migrated from the "PRI" format macros, of which there's an example in LLVM itself: https://github.com/llvm/llvm-project/blob/6a0e536ccfef1f7bd64ee4153b4efc0aeecf28d4/clang/test/SemaCXX/cxx11-compat.cpp#L38
Aug 7 2023
Aug 1 2023
Reduced:
struct a { a(decltype(nullptr)); long b; } *c; enum { d }; struct t { _Atomic(a) e; }; struct f : t {}; struct atomic { f g; void h() { f *j = &g; t *k = j; __c11_atomic_load(&k->e, d); } }; a l(a *addr) { reinterpret_cast<atomic *>(addr)->h(); return 0; } struct { void m(long v) { long w = sizeof(this); c = reinterpret_cast<a *>(w); a *o = c; l(&o[v]); } } p; a q(); long r; bool u(); a s() { if (u()) return q(); for (long i = r; i; i++) p.m(i); return nullptr; }
fyi, I bisected a crash during codegen prepare to this commit. I'm trying to reduce a repro now.
Jul 28 2023
Jul 24 2023
Jun 29 2023
LGTM, although this logic is already pretty obscure, so it's hard to follow. I wonder if we have fuzzers hooked up to this so we don't have to worry too much if this misses an edge case.
Jun 9 2023
Jun 7 2023
Jun 6 2023
The other tricky part I missed before is this bit in between pulling the event off the listener queue and deciding to show it:
Jun 5 2023
May 19 2023
May 18 2023
I forgot about this patch but I won't be around to watch it go through buildbots etc., so I'll plan to land it as soon as I get back in a couple weeks.
May 17 2023
This is a nice proof of concept, but I think we should go with a time-based approach to rate limit this. (Anyone else in LLDB know if we have some utils around to help with this?)
May 16 2023
WDYT about just replacing LLDB_CONFIGURATION_DEBUG with LLVM's EXPENSIVE_CHECKS in this case?
+1 to being surprised this is not already the case
May 11 2023
Is it expected that this patch would cause any differences in the final binary? It seems to be just a refactoring, but we bisected a runtime crash to this commit.
We're still using -Wno-enum-constexpr-conversion, although I'm not sure if we need that or if we just forgot to remove it after doing some cleanup. I'm trying it out now. (Sorry, I'm not sure we were aware that having a way to turn this off was just temporary).
Is there a test case you can add for this?
May 10 2023
- Fix some indentation
- Add a comment explaining __CORRECT_ISO_CPP_WCHAR_H_PROTO, and uncomment the actual fix now that I'm done testing CI
Sadly, when I commented out the fix & ran it through CI, the only failure was on the "no wide characters" bot because I didn't have the right XFAIL line for that. I guess we don't have any bots with an old enough glibc?
- Add XFAIL: no-wide-characters to fix CI, and update the comment with bug details
- Add some tests, and temporarily comment out the fix to see if CI catches it.
No existing test case that I'm aware of. Let me see if the repro Ray posted can be added to the test suite.
Restore to v1 of the patch
May 9 2023
No non-determinism detected with this on top of D150210, so LGTM. Thanks!
- Use #include instead of setting __CORRECT_ISO_CPP_WCHAR_H_PROTO again
Reverted in e08c397a88077c50dc25e71b39b9d5efbfc85a9a
This is causing a compiler crash, which looks like a div by zero. I'll start working on a repro, but I'd like to revert to keep trunk green.
May 8 2023
May 5 2023
I can't reproduce this outside of a modules-enabled build, and unfortunately I don't know how to write a modules test case. Anyway, here's the stderr I see:
wchar.h:316:29: error: functions that differ only in their return type cannot be overloaded extern "C++" const wchar_t *wmemchr (const wchar_t *__s, wchar_t __c, ~~~~~~~~~^ wchar.h:320:17: note: previous declaration is here extern wchar_t *wmemchr (const wchar_t *__s, wchar_t __c, size_t __n) ~~~~~~~~~^
May 1 2023
I'm not making very good progress with a test case. So far the only interesting insights I may have:
- This only reproduces in optimized builds. Setting -UNDEBUG makes the problem go away. Maybe debug builds are normalizing something?
- The problem obvious goes away with -mllvm -cgp-max-loop-inv-users-to-scan=0. One of my guesses was that V->uses() ordering might be non-deterministic, so you could get different answers in isUsedInLoop if the loop is terminated before you visit the instruction that would cause you to return true. That is not the case: the problem still exists with -mllvm -cgp-max-loop-inv-users-to-scan=10000.
Otherwise, if I do the usual process of getting clang to dump the IR and pipe that into opt, or various things like that, the process is deterministic. If you have any guess for what might get a reproducer, I can give it a shot.
Apr 28 2023
@chill, are you able to reproduce this?
Apr 27 2023
Apr 26 2023
Apr 21 2023
Apr 20 2023
SGTM, I'm not sure if LLVM has any policy w/ bazel versions like it does for host toolchains or CMake. (Probably not, since bazel is not an officially supported build system for LLVM). As long as CI passes, this should be fine. Any specific reason you're bumping it?
Apr 14 2023
Trying to get an actual reduction to share in case this isn't the right approach. The source is basically this:
Apr 12 2023
Apr 10 2023
Thanks!
Apr 7 2023
The pid plumbing looks fine for the happy case, but I think we could be more lenient if (for whatever reason) the pid flag isn't being set on non-Linux systems that won't actually be using it. Even on a Linux system, this is only needed if ptrace_scope != 0, so if the pid isn't being provided there, we could just skip the prctl call and hope the user's system has a value of 0 for that.
Apr 4 2023
Mar 31 2023
Note: this uses @platforms//os:android and not @bazel_tools//src/conditions:android because android is not one of the configs listed in @bazel_tools//src/conditions.
Mar 27 2023
Test are passing again after this patch, so I think we're all good now. Thanks!
Mar 24 2023
This relanded in e4ceb5a7bb9b8f6d730530345649286370dd3ff8, and we're seeing runtime errors in Halide when building with asan.
Mar 22 2023
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.
Mar 21 2023
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?
Mar 20 2023
Mar 17 2023
We're still seeing issues with this at trunk, even after the followup assertion fix in 874c49f55454cb285282e6d184f809945c0beca1.
Mar 7 2023
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.