Address the comment + misc fixes.

I suspect there might be some terminology clash, so clarifying a bit just in case.

In D82014#2182436, @psmith wrote:

In D82014#2180015, @MaskRay wrote:

Ping @kamleshbhalui

I hope your or some reviewer can test the buildability on ARM.

If I get some time this week(end) I'll make a soft-float build. I don't want to hold the change up by insisting we test on a soft-float Arm. I am interested in whether these functions are tested at all in that case, which we ought to follow up with if they are not.

Ping.

@rjmccall Uploaded, thank you!

Ping.

Here are the benchmark and fuzzing harness used to test this patch.

Revert auto-linting

Fix some review comments.

In D84602#2176584, @rjmccall wrote:

Is there only one special calling convention, or is there any chance that different builtin functions would use different conventions?

Revert automatic formatting change.

If I get it right, the only thing this patch weakens about msp430-toolchain.c test is an assumption that libgcc is used by default.

After a final retesting, this patch was updated a bit.

Thank you! Will probably land it tomorrow.

Just an automatic rebase to (possibly) fix failing "Apply patch" step.

Just add the test on -rtlib=compiler-rt handling as everything other is ready for basic clang_rt.builtins support.

Support int/long/long long _Complex types (GCC extension). According to msp430-gcc v9.2.0, they behave identically.

Fix path separators in unit test on Windows

Address the review comments.

• Rebase onto an up-to-date upstream commit
• Recheck against v9.2.0
• Misc fixes and improvements

Just a note: using __mspabi_cmpf as a generic LibCall seems quite incorrect because __mspabi_cmpf does not accept NaNs according to MSP430 EABI. msp430-elf-gcc v9.2.0 just uses __nesf2 in the example above. I plan changing this later when doing more adjustments for libgcc/clang_rt.

Meanwhile, msp430-gcc v9.2.0 was released on Jun 12. Will recheck against the new version slightly later.

Move missed powitf2.c source as well.

Ping.

Thank you!

Unit test: fix for path separators on Windows

Address the review comments.

could you please clarify what exactly is wrong? Windows not building 'compiler-rt'?

Thank you for the comments. Will send an update soon.

Fix compile error when building with older compilers.

Unit test failure here is expected because D82055: [DebugInfo] Explicitly permit addr_size = 0x02 when parsing DWARF data have to be landed before.

In D81488#2104502, @aprantl wrote:

Meanwhile, is it acceptable that byte-sized and word-sized registers share the same DWARF register numbers such as r12 (16 bit) and r12b (8 bit) in this example?

These kinds of decisions are supposed to be specified by the ABI document for the platform (not in the DWARF standard), so you'd have to direct this question to whatever consortium defines the ABI for MSP430.

In D81408#2104572, @efriedma wrote:

Those flaky test failures seems to be due to ld.lld being not built from source as part of testing compiler-rt/-only patches.

That should be something we can fix in the build system. compiler-rt/test/CMakeLists.txt has a list of executables which the tests depend on. If that list isn't complete, it should be updated.

Meanwhile, is it acceptable that byte-sized and word-sized registers share the same DWARF register numbers such as r12 (16 bit) and r12b (8 bit) in this example?

Thanks! I have dropped the entire #0 and #1 attribute lists - that did not change the output. All the debug information nodes, on the other hand, were left intact (just in case) apart from omitting some parts of the producer string.

Replaced native_int by plain int, as @aykevl suggested.

Those flaky test failures seems to be due to ld.lld being not built from source as part of testing compiler-rt/-only patches.

@samsonov Something strange happens with the compiler-rt tests: when this patch was initially uploaded, the tests were failed with seemingly unrelated failures: B59287. Some tests are broken upstream, I concluded.

Thank you!

Rebase onto working upstream commit to (hopefully) make tests pass for my patch.

Fix test once again (replace more literal slashes with regex).

1. Since different quite unrelated patches failed on Jun 5 with quite the same messages, just rebase onto current master expecting build failure to go away
2. Ping

fix unit test: add another "-lgcc" and (hopefully) fix path separators on Windows

Unit test: fix backslash on Windows

Implemented a test. Please note it depends on D82055: [DebugInfo] Explicitly permit addr_size = 0x02 when parsing DWARF data.

In D81285#2082394, @aykevl wrote:

I'm not sure whether native_int is any clearer than just int. I'm afraid it only introduces more complexity ("What's native_int? Oh, it's just int").

I changed the integer types used in many builtins (si_int, du_int, etc) to specific integer widths. My rationale is that even though the libgcc documentation uses types such as int / long / long long, I believe their bit width is actually much more strictly defined.

Sorry, forgot to add cfe-commits to CC. Will reopen soon.