Ping. Any other comments/concerns?

FWIW, the pre-merge checks failed due to a problem with git-clang-format, not the tests themselves (they are all green).

Address issues from the last revision.

Fix builtin definition and tests

Fix ppc bcopy test

Ping?

This change seems to be breaking one of the buildbots (https://lab.llvm.org/buildbot/#/builders/179/builds/6704). This is a Neoverse N1, which doesn't have SVE. So I believe this should be checking whether the CPU supports SVE or not.

LGTM.

Actually, this test only fails on aarch64 using GNU ld. With lld, it works fine: https://lab.llvm.org/buildbot/#/builders/185/builds/4357

In D149685#4474512, @jdenny wrote:

In D149685#4471532, @cseo wrote:

I think there's a corner case you may have missed. I'm still seeing this on aarch64:

/llvm-project/openmp/libomptarget/test/mapping/target_derefence_array_pointrs.cpp:28:12: error: CHECK: expected string not found in input
 // CHECK: 3
           ^
<stdin>:1:103: note: scanning from here
Libomptarget message: explicit extension not allowed: host address specified is 0x0000ffffd26ff7c0 (12 bytes), but device allocation maps to host at 0x0000ffffd26ff7c0 (8 bytes)
                                                                                                      ^
<stdin>:1:104: note: possible intended match here
Libomptarget message: explicit extension not allowed: host address specified is 0x0000ffffd26ff7c0 (12 bytes), but device allocation maps to host at 0x0000ffffd26ff7c0 (8 bytes)

Your patch fixes most failures, except this one. Fails with and without LTO enabled. Could you please check?

I'm not testing on aarch64, but that test fails for me both before and after this patch. This patch is about padding generated for a partial struct mapping, which is irrelevant to that test, as far as I can tell.

I think there's a corner case you may have missed. I'm still seeing this on aarch64:

Thanks. If no one else objects, I'll commit it later today.

In D144654#4381893, @nickdesaulniers wrote:

In D144654#4380488, @john.brawn wrote:

gcc has the same warning so I wasn't expecting this cause to change problems, but looking more closely at gcc's behaviour it looks like it only warns for some builtin macros and not others (though glancing over the gcc source code it's not clear which macros and for what reason).

I'll look at this some more and see if I can improve the behaviour.

Based on
https://lore.kernel.org/llvm/6475a837.170a0220.77d4a.116a@mx.google.com/T/#u
I think the following macros aren't warned on: https://godbolt.org/z/dfqnG7bae

#undef __INT32_TYPE__
#undef __UINT32_TYPE__
#undef __UINTPTR_TYPE__
#undef __i386__
#undef __UINT64_TYPE__
#undef __INT64_TYPE__

In D151118#4368717, @vdonaldson wrote:

In D151118#4368244, @cseo wrote:

@vdonaldson btw, I don't have commit access. So, whenever you think this change is good to go, feel free to push it.

@cseo The preferred approach is to request commit access: obtaining-commit-access

(Don't forget to update the test details!)

Updated the testcase to remove a hardcoded SSA register variable.

@vdonaldson btw, I don't have commit access. So, whenever you think this change is good to go, feel free to push it.

Moved the fix from the generic genFIR code to SelectTypeConstruct/CaseConstruct

In D151118#4362665, @vdonaldson wrote:

I recommend fixing the problem in construct code, rather than generic genFIR code. Something like the following, where the second set of diffs is for the genFIR SelectTypeConstruct function, which is also at risk for the same problem.

Added extra checks to select-case-statement.f90

In D43025#1067279, @dvyukov wrote:

Looks good to me.
Do you have commit access, or you want me to commit it?

Version 3: fixed OSCFLAGS for amd64 in buildgo.sh and some comments in tsan_platform.h.

Version 3: new mappings, dropped unneeded memory areas.

Version 2: update memory mappings, changed buildgo.sh FLAGS.