Update compiler-builtins and enable f128 tests on all non-buggy platforms

[tgross35]

Update compiler_builtins to 0.1.138 and pin it. This updates to a new version of builtins that includes 1, which was
the last blocker to us enabling f128 tests on all platforms.

With that, we now provide symbols necessary to work with f128 everywhere. This means that we are no longer restricted to systems that provide f128 symbols themselves, and can enable tests by default.

There are still a handful of platforms that need to remain disabled because of bugs and some that had to get updated.

Math support is still off by default since those symbols are not yet available.

try-job: test-various
try-job: i686-gnu-nopt

[rustbot]

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

[tgross35]

This includes #132433 which includes #132206, so the chain is a bit deep (I'm keeping updates separate from rust-lang/rust changes so we aren't blocked from updating further if something goes wrong here). But that doesn't mean we can't start some tests.

@bors try

[tgross35]

Those are quite a few try jobs but it still doesn't cover everything that will be newly enabled here.

@bors rollup=never

[bors]

⌛ Trying commit 15075bf with merge ec0220a...

[tgross35]

Also cc @beetrees

[bors]

☀️ Try build successful - checks-actions
Build commit: ec0220a (ec0220aadb3398fa8aa480a8d4a0f8e3e6d48e20)

[workingjubilee]

This has a merge conflict, it seems.

[workingjubilee]

I have rebased it.

[beetrees]

I think the f128 tests need to be disabled on 32-bit x86 due to llvm/llvm-project#77401 (although tests might pass anyway if the symbols from the LLVM-compiled compiler-builtins get picked by the linker instead of those from a GCC-compiled system library).

Also mips64/mips64r6 currently doesn't have f128 builtins built for it due to llvm/llvm-project#96432.

[workingjubilee]

I do not believe we run the relevant tests on mips64?

[workingjubilee]

I decided to change up the suite of tests slightly and rerun this. In particular, I noticed we didn't run the infamous test-various.

@bors try

[bors]

⌛ Trying commit 95998ee with merge ad17ccb...

[beetrees]

I do not believe we run the relevant tests on mips64?

All MIPS targets are tier 3, so no builds or tests of any kind are run by rust-lang/rust. The benefit of adding it to the match statement is just for those running tests locally/Linux distros with a MIPS64 port etc. 32-bit sparc is also tier 3 only and is already on the list.

[beetrees]

Mention of #125102 can be removed from the PowerPC arm of the match statement as that issue is now fixed. The other PowerPC-related bugs currently unfixed that aren't currently listed in the match arm are llvm/llvm-project#98126, llvm/llvm-project#92866 (powerpc64 little-endian only), and llvm/llvm-project#101545 (powerpc64-ibm-aix only); since there are four open issues in total linking to the f16/f128 tracking issue (#116909) instead of listing them all in the source code individually also seems reasonable.

[tgross35]

I updated this to skip x86 and mips as mentioned. Indeed we don't test this (and try job only allow the jobs listed here, though I wish it was possible to do try jobs for tier 3 targets) but I know there are people running the test suite locally, e.g. #127235.

Also adjusted some comments.

Updated try jobs to those that have been mentioned but not yet tested.

@bors try

[bors]

⌛ Trying commit 898ecf0 with merge 2ec481c395b83f7d7eb0b3521f6ab25f23a6360d...

[beetrees]

LGTM. Thanks

[workingjubilee]

All MIPS targets are tier 3, so no builds or tests of any kind are run by rust-lang/rust. The benefit of adding it to the match statement is just for those running tests locally/Linux distros with a MIPS64 port etc. 32-bit sparc is also tier 3 only and is already on the list.

mmh. my usual inclination is that we should leave known-failing-on-tier-3 tests on, so that people who are doing just that are aware that the platform's support is incomplete... and if they run the tests and then are bothered by it, we're usually amenable to exclusions.

as this is a nightly feature though I'm not strongly motivated either way.

[workingjubilee]

let's get this show on the road:
@bors r+

[bors]

📌 Commit c0fc25c has been approved by workingjubilee

It is now in the queue for this repository.

[bors]

⌛ Testing commit c0fc25c with merge 706eec8...

[bors]

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing 706eec8 to master...

[rust-timer]

Finished benchmarking commit (706eec8): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.5%	[1.5%, 1.5%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.4%	[-1.4%, -1.4%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.2%, secondary 1.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.8%	[1.2%, 4.8%]	3
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-1.2%	[-1.2%, -1.2%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 780.005s -> 778.282s (-0.22%)
Artifact size: 335.27 MiB -> 335.31 MiB (0.01%)

[jethrogb]

Is it correct that compiler-builtins/libm doesn't define fmodl (for f128)?

[jethrogb]

I see in your first message you mention:

Math support is still off by default since those symbols are not yet available.

However, the compiler does appear to be generating references to fmodl with this PR merged.