*ping* @aaron.ballman. Would you be able to sign off on this? Otherwise, I'll probably commit this in the next few days.

• Renamed unnamedfunc to unnamed_func.
• Replaced "equivalent to the resolved function at runtime" with "equivalent to the resolved function as a call target".
• Added section to LangRef.

The IR differences were caused by the new pass manager which is on by default for the Fuchsia builder. I've re-landed the patch with a fix for CodeGen/attr-arm-sve-vector-bits-call.c to use the legacy pm with -fno-experimental-new-pass-manager.

Update to reflect comments in the RFC.

Hi! The attr-arm-sve-vector-bits-call.c test seems to be failing on our clang builders:

Hi! I believe our mac builders are failing after this change with

Clean up some of the code.

In D77248#2224589, @arsenm wrote:

Was there an RFC for this?

Missing GlobalISel support

CC @aaron.ballman who committed Features.def for signing off or knowing someone who can sign off.

Hi. I believe this patch is incompatible with cmake 3.13.5. We're seeing

In D77606#2215442, @ldionne wrote:

In D77606#2214538, @mcgrathr wrote:

Long-term, I think we want this to be keyed entirely on a compiler predefine and not chosen in cmake.

Actually, I'd like to use that approach now. @leonardchan is that possible?

Store a TargetCXXABI::Kind instead of a string in LangOpts.

Ok. Ready for review!

• Check for lowercase flag values
• Remove fuchsia-specific changes

LGTM for LLVM readability.

The patch seems straightforward. Other than moving code and trimming llvm:: from types, not sure if there's anything else I should expect. LGTM.

In D84202#2179618, @aaron.ballman wrote:

users can still disable the warning on line granularity with pragmas.

This makes me a bit uncomfortable because those pragmas extremely ugly (and not easily portable). Also, this will break code for users who were previously doing something that was explicitly allowed (but not explicitly documented, at least). How often do users need to (legitimately, rather than accidentally) use the C-style cast like this?

*ping*

Add a method to TargetCodeGenInfo the returns if the target supports PC relative PLT relocations,

In D81031#2159646, @sstefan1 wrote:

Just in case you haven't seen already, clang/test/OpenMP/barrier_codegen.cpp needs to be updated as well.

Hello. This test seems to be failing for us (https://luci-milo.appspot.com/p/fuchsia/builders/ci/clang-linux-x64/b8874608488579495664?) and other builders that use the new pass manager (http://lab.llvm.org:8011/builders/clang-x86_64-debian-new-pass-manager-fast/builds/11949). Would you mind updating the test or reverting for now? Thanks.

It wouldn't just be restricted to fixed-point intrinsics, though. It would have to be added to intrinsics like uadd.sat and usub.sat as well, which aren't really tied to fixed-point at all.

In D82663#2130355, @ebevhan wrote:

Well, it's not so much as adding the bit, but adding the information that the bit exists. That means either new intrinsics for all of the operations, or adding flags to the existing ones. That's a fair bit of added complexity. Also, <signed operation> + <clamp to zero> would do virtually the exact same thing as the new unsigned-with-padding operations, so the utility of adding all of it is a bit questionable.

In D76389#2120868, @arsenm wrote:

This seems like it covers a different case than D82735?

LGTM. Thanks for the fix.

LGTM

In D81184#2089657, @psmith wrote:

Looking good so far. Would be good to add a range extension thunk test case. For example:

 .section .text.1, "ax", %progbits
 .global _start
 .type _start, %function
_start: .word callee@PLT - .

 .section .text.2, "ax", %progbits
 .global callee
 .type callee, %function        
callee: ret

Using a linker script to get a > 4gb gap. The AT is there to stop a multi gigabyte file being written.

SECTIONS {
  .text.1 0x10000 : { *(.text.1) }
  .text.2 0x200000000 : AT(0x20000) { *(.text.2) }
}

The .word should be an offset to the range extension thunk instead of the target.

Rebased and updated tests with assembly instead of yaml.

Lemme know if there's any more feedback. Will aim for committing this sometime at the end of the day.

D81446 is the LLVM counterpart.

• Removed the llvm changes to be moved to a separate patch.
• Added a test for checking the relocation used with an undefined weak symbol. IIRC, the behavior of this is unspecified anyway.
• Added test for checking overflow.

@rjmccall Would it be fine to submit this since you gave LGTM on D72959?

Rebased

In D80452#2064445, @leonardchan wrote:

Hi! I think this patch might be the cause of the bug at https://bugs.llvm.org/show_bug.cgi?id=46137.

Essentially, we get an error when attempting to create std::array<S, 0> if S has a non-trivial destructor (full example at the bug link):

test.cc:20:20: error: call to implicitly-deleted default constructor of 'std::array<S, 0>'
  std::array<S, 0> x;  // bad
                   ^
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/install/bin/../include/c++/v1/array:252:7: note: default constructor of 'array<S, 0>' is implicitly deleted because field '__w' has a deleted destructor
    } __w;
      ^
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/install/bin/../include/c++/v1/array:248:9: note: explicitly defaulted function was implicitly deleted here
        ~__wrapper() = default;
        ^
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/install/bin/../include/c++/v1/array:251:13: note: destructor of '__wrapper' is implicitly deleted because variant field '__t' has a non-trivial destructor
        _Tp __t;
            ^
test.cc:20:20: error: attempt to use a deleted function
  std::array<S, 0> x;  // bad
                   ^

I believe std::arrays of size 0 should be legal regardless of constraints on the element type.

Hi! I think this patch might be the cause of the bug at https://bugs.llvm.org/show_bug.cgi?id=46137.

In D80692#2061739, @aeubanks wrote:

I foolishly submitted without running check-all, and it turns out this broke a test under check-clang.
Looks like https://reviews.llvm.org/D62888 added tests in sancov-new-pm.c to make sure that sancov + LTO work together, but they won't after this change since the (Thin)LTO pipeline doesn't run things under registerOptimizerLastEPCallback(). So I deleted those tests. Other sanitizers don't work under LTO right now (at least for non-O0) because of the same thing. Does this make sense?

Would be worthwhile to write a small test that asserts Sancov runs before the other sanitizers under the new PM?

*ping*