This is fine with me.

In D85630#2220694, @ro wrote:

Ping? It's been a week, the patch fixes ca. 250 testsuite failures and is this a candidate for LLVM 11.0.0 rc2.

LGTM. Thanks.

In D74051#2017115, @mgorny wrote:

Nevermind, I figured out good enough workaround.

Reverting this patch seems to fix the error for me. Are you still seeing this same error in trunk?

This commit appears to be causing an error when I run CMake:

I can confirm that this patch also fixes the full test case.

In D79279#2200916, @rsmith wrote:

In D79279#2197176, @rjmccall wrote:

I thought part of the point of __builtin_memcpy was so that C library headers could do #define memcpy(x, y, z) __builtin_memcpy(x, y, z). If so, the conformance issue touches __builtin_memcpy as well, not just calls to the library builtin.

They would have to declare it as well (because C code can #undef memcpy and expect to then be able to call a real function), so the #define would be pointless. It doesn't look like glibc does anything like this; do you know of a C standard library implementation that does?

If we want to follow that path, then we'll presumably (eventually) want address-space-_overloaded versions of all lib builtins that take pointers -- looks like that's around 60 functions total. That said, I do wonder how many of the functions in question that we're implicitly overloading on address space actually support such overloading -- certainly any of them that we lower to a call to a library function is going to go wrong at runtime.

+@tstellar, who added this functionality in r233706 -- what was the intent here?

Add volatile test.

Here is the assembly comparison for the 64-bit test I added between gcc and clang trunk + patch: https://reviews.llvm.org/P8227

This is the test driver I used for testing. I compared the clang 11 + this patch with gcc 10 and saw no differences: https://gist.github.com/tstellar/80dae2ab8a18d810b10b8e42777f4fe4

Add 64-bit test.

In D84405#2170110, @vsk wrote:

How were you able to show that the specialized IRGen is equivalent to the generic kind? I tried doing this with direct inspection (https://godbolt.org/z/o5WEn3), but wasn't able to convince myself. In the past I used a test driver to compare the before/after compiler output -- you might find that useful (https://gist.github.com/vedantk/3eb9c88f82e5c32f2e590555b4af5081).

Remove stray comment.

Add example for tagging the -init tag.

LGTM.

LGTM.

LGTM. Thanks.