In D68824#1704942, @rsmith wrote:

This seems to be missing a CodeGen test for what IR we generate on an overly-large alignment. (The warning says the alignment is ignored, but I don't see where you're actually doing anything different in that case when generating IR.)

cant use llvm::Value in Sema without some linker issues.

Hal's comments

Remove unused code

Ah, Ugg... GCC must implement the target parsing handling different on a per-architecture basis (ARM vs X86). We've only got parsing in place to do the x86 way. That ends up making this a much more difficult thing to maintain I suspect.

Seems your test changes have disappeared as well? Otherwise, 1 comment then I'm ok with this.

Also, can you add a test for GNUCmpXchg in both situations (inside a template, and outside)? It is the most complicated, and would best reflect the issue.

It kinda stinks that we have to do this at such a late step. I'd have much preferred doing this as a part of the rebuild, but it appears that the 'form' takes quite a bit to calculate. Also, I'd likely have preferred that the initial reordering happened in codegen instead of this early, though perhaps thats too large of a change to do here.

Yikes, good catch!

In D67854#1678982, @erichkeane wrote:

In D67854#1678236, @RKSimon wrote:

@erichkeane The atomic-expr.cpp test is failing on some MSVC buildbots, please can you take a look? http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/

On it. Buildbot never emailed me I guess *shrug*.

In D67854#1678236, @RKSimon wrote:

@erichkeane The atomic-expr.cpp test is failing on some MSVC buildbots, please can you take a look? http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/

Fixed in r371985.

In D67368#1669818, @plotfi wrote:

I think this change might be breaking builds: http://lab.llvm.org:8011/builders/clang-aarch64-linux-build-cache/builds/16888

I think I've changed everything @aaron.ballman suggested. Despite the size of this patch, it actually removes ~1020 lines of code!

Actually... I think it might need to be weak_odr based on https://llvm.org/docs/LangRef.html#linkage-types

I prefer this to be in the place where the ifunc gets created, otherwise we definitely need tests. There are sufficient tests for this that show the ifunc having been created, so I'd suggest just adding to them.

In D67058#1654347, @lebedev.ri wrote:

Tests missing.
Is that what gcc does? I'd personally thought those should be internalized.

Craig topper pointed out to me that constexpr cannot throw exceptions, and at least the rints can raise some exceptions, which aren't allowed in Constexpr. The round functions similarly hit unspecified behavior, so we need to match that behavior.

Small nit, just default construct the APFloats.

In D66800#1647121, @ldionne wrote:

If your system only has libc++ available but the compiler shipped with it doesn't work out of the box (i.e. without passing -stdlib=libc++), isn't your compiler broken? In other words, it seems to me that your system compiler should always work out of the box without having to pass -stdlib=XXX -- do we agree? If so, I think the bug should be reported to whoever vends the compiler on the platform where you encountered this issue.

I would MUCH prefer that the compiler checker actually use the right library. Also, this isn't completely correct, MacOS Clang doesn't have libstdc++ available at all, yet works fine.

I don't have a good idea of the intent of this patch. It seems to me that this could do some pretty nasty damage to C code, right?