- User Since
- Jun 4 2020, 7:24 AM (9 w, 1 d)
Address the comment + misc fixes.
I suspect there might be some terminology clash, so clarifying a bit just in case.
@rjmccall Uploaded, thank you!
Wed, Aug 5
Mon, Aug 3
Fri, Jul 31
Here are the benchmark and fuzzing harness used to test this patch.
Thu, Jul 30
Tue, Jul 28
Fix some review comments.
Mon, Jul 27
Sun, Jul 26
Thu, Jul 23
Revert automatic formatting change.
Fri, Jul 17
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.
Tue, Jul 14
Thank you! Will probably land it tomorrow.
Thu, Jul 9
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.
Jul 8 2020
Support int/long/long long _Complex types (GCC extension). According to msp430-gcc v9.2.0, they behave identically.
Jul 7 2020
Fix path separators in unit test on Windows
Address the review comments.
Jul 1 2020
Jun 30 2020
- Rebase onto an up-to-date upstream commit
- Recheck against v9.2.0
- Misc fixes and improvements
Jun 29 2020
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.
Jun 26 2020
Meanwhile, msp430-gcc v9.2.0 was released on Jun 12. Will recheck against the new version slightly later.
Jun 25 2020
Move missed powitf2.c source as well.
Jun 24 2020
Jun 23 2020
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'?
Jun 22 2020
Thank you for the comments. Will send an update soon.
Fix compile error when building with older compilers.
Jun 20 2020
Unit test failure here is expected because D82055: [DebugInfo] Explicitly permit addr_size = 0x02 when parsing DWARF data have to be landed before.
Jun 19 2020
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.
Jun 18 2020
@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.
Rebase onto working upstream commit to (hopefully) make tests pass for my patch.
Fix test once again (replace more literal slashes with regex).
- 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
fix unit test: add another "-lgcc" and (hopefully) fix path separators on Windows
Unit test: fix backslash on Windows
Jun 17 2020
Implemented a test. Please note it depends on D82055: [DebugInfo] Explicitly permit addr_size = 0x02 when parsing DWARF data.
Jun 11 2020
Jun 9 2020
Jun 8 2020
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.
Jun 6 2020
Jun 5 2020
Sorry, forgot to add cfe-commits to CC. Will reopen soon.