- User Since
- Apr 25 2018, 1:47 PM (73 w, 4 d)
Mon, Sep 16
Fri, Sep 13
Not sure if we're still mentioning false positives here, but if we have something like a multidimensional array of a specific type and we want to find the number of elements inside it, this warning would also appear:
Wed, Sep 11
Hi! I think this patch is causing a test failure for DebugInfo/X86/live-debug-vars-discard-invalid.mir on our bots:
Tue, Sep 10
You can see the bot at: https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-x64-linux/b8902661942095266432
Hi. I think this might be causing some linker failures on our x64 bots:
Sun, Sep 8
Hi! I think this might've broken the normal workflow for using this helper script shown in https://llvm.org/docs/GettingStarted.html#for-developers-to-commit-changes-from-git
Sat, Sep 7
Fri, Sep 6
LGTM. Thanks for taking over this!
Wed, Sep 4
Tue, Sep 3
Hi! We've noticed that for our arm bots, we're getting some flaky builds that sometimes fail with error: array designators are a C99 extension [-Werror,-Wc99-designator] and sometimes don't fail. 2 questions:
Fri, Aug 30
*ping* This patch also seems to fix an issue with mismatched PC table and inline counters:
Hi! After running a bisect, I believe this patch is causing the assertion error in https://bugs.llvm.org/show_bug.cgi?id=43171. Could you look into this? There is a reproducer attached to the bug.
Thu, Aug 29
Sorry about that. Still LGTM.
Tue, Aug 27
Hi! I'm seeing a test failure on our bots that I think may originate from this patch:
Aug 22 2019
I think this patch might be causing some test failures on our mac bots:
Aug 21 2019
Aug 20 2019
Thanks for taking care of this! Sorry for not doing this earlier. Got caught up in other stuff.
As of now, from running check-llvm and check-clang there's 2 failing tests, but I'm trying to get those addressed.
It seems that this test leads to an UNREACHABLE under the new pass manager (can check this by adding -fexperimental-new-pass-manager to the test. I think this is because the passes for lowering the llvm.coro intrinsics are not yet ported to the new PM. Would it be fine to add -fno-experimental-new-pass-manager to the test to indicate it should be run under the legacy PM only? Thanks.
Aug 19 2019
Could you temporarily revert this in the meantime? This is blocking our clang roll that we need to fix another Clang issue we're hitting.
Hi again. After some bisecting, we found that the relanding of this (rGf28e1128d9e) was causing a segfault on our aarch64 asan bots.
Aug 16 2019
I think this is causing this error on our mac builders:
I believe this patch is causing 2 test failures on our x64 clang bots:
This test seems to be failing on our mac builders:
Aug 15 2019
I have a suspicion that this might be causing the assertion error we see in https://bugs.llvm.org/show_bug.cgi?id=43015. Checking this now. Just wanted to raise awareness in the meantime.
Let me know if there's anything that you need from me to help diagnose this.
Hi. We believe this patch is causing a CMake error for out toolchian build:
Aug 12 2019
Hi. I noticed in our builders that both of the warnings introduced in this patch are being diagnosed for pointers that don't use GSL at all. I'm attempting to make a small reproducer now.
Jul 31 2019
*ping* We would like to bump up the priority of this since this allows us to enable the new PM when building fuchsia.
Jul 30 2019
LGTM but I'd wait a day to see if anyone else has comments they'd like to add before landing.
Jul 29 2019
Replaced with D65110
Jul 26 2019
Jul 25 2019
Jul 24 2019
Jul 22 2019
I created D65110 if we're ok with just using the new PM.
Jul 17 2019
Jul 15 2019
Jul 12 2019
Jul 11 2019
Jul 10 2019
*ping* Is it ok to proceed with only checking the new PM output for these tests? If so I could just edit my previous patch to remove the legacy PM run lines since they already include the bitcasts from the new PM.
Jul 8 2019
LGTM. Good catch
Jul 2 2019
Jul 1 2019
Jun 28 2019
Reverted in r364692
Understood. I'll revert this patch.
I mean, I'm happy for the patch to be reverted, but I still really don't understand why this fixes the test to work *exactly* the same as w/ the old pass manager and doesn't break any other tests if it is completely wrong? It seems like there must be something strange with the test coverage if this is so far off of correct without any failures...
I also don't understand what fix you are suggesting instead, but maybe you can show a patch?
Jun 27 2019
@t.p.northover Would you feel ok reviewing this?
Jun 26 2019
Any updates on this? I'm thinking that in the meantime maybe we could commit D63174 and work on this while that lands. If so, we could get an upstream new PM buildbot that can catch any new PM regressions.
Jun 24 2019
Hmm is there usually a protocol/etiquette for getting a new built-in submitted to compiler-rt?
Is there not a function for that already in compiler-rt? Or is the problem that it doesn't necessarily exist, e.g. if we're supporting a 64-bit scaled integer type but not a 128-bit integer type?