Hi, it seems that this revision introduced the regression in https://bugs.llvm.org/show_bug.cgi?id=44585 that produces incorrect DWARF expressions when using safestack. Would you mind taking a look? Thanks.

LGTM with just one quick question

Hi, it seems that this commit also introduces libc++ headers that are incompatible with gcc 9.2:

LGTM for the code so far. Just want to confirm on my side that the codegen works as intended also.

Yup, was able to confirm this is the faulty patch. Would you mind looking into this or reverting in the meantime?

*Moved from the commit to here*

Hi! This seems to be causing some test failures on our bots: https://ci.chromium.org/p/fuchsia/builders/ci/clang-linux-x64/b8893521019883752048

LGTM. Could you commit this soon to get the bots green again?

Hi! I believe the commit for this (a3b2552575d3c333e928446fac10cc5b0b4092a9) is causing a test failure on our bots (https://ci.chromium.org/p/fuchsia/builders/ci/clang-linux-x64/b8894791990609720880) and some buildbots (can't find the link since it scrolled past the end of the console). Could you look into it when you get a chance?

Alrighty, it looks like everything in this patch should be ok after those 2 changes. I can send you the script I used to generate tests if you'd like to use it also.

Sorry for the holdup. Right now I'm just writing a bunch of tests to validate the IR expansion produces the correct division results. As of now, the patch LGTM, but I'd prefer holding off submitting the revision until I finish validating (unless you think it's better to submit now then fix any potential bugs that may be found later since I don't think anyone will be immediately using this). Here's a few comments I have so far:

Could you add a test to show that with a fuchsia target we end up returning this from constructors + destructors and ensure that this ABI is used?

LGTM. But just to confirm, did you test this on CQ/bots by adding ["now", "-z"] as linker flags to the config("compiler") in Fuchsia + Zircon?

Hi! I think this patch might be causing some test failures on our mac bots:

I reverted this commit in 66b6b92765213a6bde96aea7a393621426027543.

Hi! This patch seems to be causing test failures on our bots (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-x64/b8896419822706045584) and the llvm buildbots (http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/12040/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Axcoff-disassemble-all.test). Could you take a look into this? Thanks.

Hi. This patch seems to be causing a test failure for our clang x64 bots:

Hi. I think this patch is causing some test failures for us:

Yup, a bisect shows it was this patch that caused it. I filed a bug for tracking at https://bugs.llvm.org/show_bug.cgi?id=43950 and attached a reproducer. Could you look into this? Thanks.

Hi. I have a suspicion this patch is causing a segfault for us when building zircon: https://ci.chromium.org/p/fuchsia/builders/ci/fuchsia-x64-debug-clang/b8897388724384628544

Adding @chandlerc for review. I'm not very comfortable reviewing changes to the backend pipeline.

In D58238#1727932, @aprantl wrote:

Is the extra cost here, or is it more work being generated for LiveDebugValues?

Hi! This patch seems to drastically increase compile times for some fuchsia builds. I'm working on creating a small reproducer that I can share, but just wanted to raise awareness in the meantime.

Manually closed since git push didn't seem to automatically close this. Committed under https://github.com/llvm/llvm-project/commit/85b718f53a3575bca2f1b7fdb1b3aaa6df7c10e3.

Hello. I believe this patch is causing the assertion failure we see at https://bugs.llvm.org/show_bug.cgi?id=43794. Could you take a look? Thanks.

We're building a 2 stage build where the 1st stage is made using the fuchsia toolchain clang (which is just revision cea8882254f97ae82867e25e736959d1cfa31896) and the 2nd stage is made from the 1st stage clang. This is our cmake invocation:

Hi! I'm not sure how this change could've caused it, but do you have an idea of how this could've caused the following error:

Thanks for finding the root cause of this!

I think I found a false negative with this where if the member is accessed from a packed struct type returned from a function, the warning does not appear:

*ping* @rsmith

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:

Hi! I think this patch is causing a test failure for DebugInfo/X86/live-debug-vars-discard-invalid.mir on our bots:

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:

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

LGTM. Thanks for taking over this!

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:

*ping*

*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.

Sorry about that. Still LGTM.

Hi! I'm seeing a test failure on our bots that I think may originate from this patch:

I think this patch might be causing some test failures on our mac bots:

In D57836#1641679, @bjope wrote:

I'll try to finish the work on this patch (hence the commandeer action). I hope @leonardchan won't mind that.

Thanks for taking care of this! Sorry for not doing this earlier. Got caught up in other stuff.

In D44672#1637984, @vsk wrote:

In D44672#1637891, @leonardchan wrote:

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.

Sounds reasonable to me. It would be great to include a link to some master PR for the new PM porting effort with the test change.

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.

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.

I think this is causing this error on our mac builders: