Enable outline-atomics by default on aarch64 Apple targets

[vini-fda]

Summary

This PR is related to #149634. Most of the credit goes to tgross35@76a4adc.

Tests

I haven't added any tests, but I enabled the tests in library/compiler-builtins/builtins-test/tests/lse.rs for all operating systems. It was previously gated to Linux-only, but with this change these tests work for Apple as well (I performed local tests). I'm hoping other OSes also pass the tests.

I ran the tests by running the following with rust-nightly (after running the x script and creating a stage 1 compiler):

cd rust/library/compiler-builtins
cargo +stage1 test -p builtins-test --test lse

I followed the contributing guide for the tests, though I'm still struggling with testing. I would appreciate some pointers to learn how to use the test tools effectively for compiler-builtins.

[vini-fda]

@bors2 try jobs=aarch64-apple

[rust-bors]

Unknown command "2". Run @bors help to see available commands.

[rust-bors]

@vini-fda: 🔑 Insufficient privileges: not in try users

[vini-fda]

@bors help

[rust-bors]

You can use the following commands:

PR management

• r+ [p=<priority>] [rollup=<never|iffy|maybe|always>]: Approve this PR on your behalf
  • Optionally, you can specify the <priority> of the PR and if it is eligible for rollups (<rollup>).
• r=<user> [p=<priority>] [rollup=<never|iffy|maybe|always>]: Approve this PR on behalf of <user>
  • Optionally, you can specify the <priority> of the PR and if it is eligible for rollups (<rollup>).
  • You can pass a comma-separated list of GitHub usernames.
• r-: Unapprove this PR
• p=<priority> or priority=<priority>: Set the priority of this PR
• rollup=<never|iffy|maybe|always>: Set the rollup status of the PR
• rollup: Short for rollup=always
• rollup-: Short for rollup=maybe
• delegate=<try|review>: Delegate permissions for running try builds or approving to the PR author
  • try allows the PR author to start try builds.
  • review allows the PR author to both start try builds and approve the PR.
• delegate+: Delegate approval permissions to the PR author
  • Shortcut for delegate=review
• delegate-: Remove any previously granted permission delegation
• try [parent=<parent>] [job|jobs=<jobs>]: Start a try build.
  • Optionally, you can specify a <parent> SHA with which will the PR be merged. You can specify parent=last to use the same parent SHA as the previous try build.
  • Optionally, you can select a comma-separated list of CI <jobs> to run in the try build.
• try cancel: Cancel a running try build
• retry: Clear a failed auto build status from an approved PR. This will cause the merge queue to attempt to start a new auto build and retry merging the PR again.
• info: Get information about the current PR

Repository management

• treeclosed=<priority>: Close the tree for PRs with priority less than <priority>
• treeclosed- or treeopen: Open the repository tree for merging

Meta commands

• ping: Check if the bot is alive
• help: Print this help message

[rustbot]

compiler-builtins is developed in its own repository. If possible, consider making this change to rust-lang/compiler-builtins instead.

cc @tgross35

These commits modify compiler targets.
(See the Target Tier Policy.)

[rustbot]

r? @mati865

rustbot has assigned @mati865.
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

[tgross35]

r? tgross35

I finished commenting at #149634 just after you marked this ready for review, but as the above message says, the compiler-builtins bit should go against that repo so it gets the better test coverage.

[tgross35]

For splitting the asm part to the c-b repo and sending it there,
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[tgross35]

This PR is related to #149634. Most of the credit goes to tgross35@76a4adc.

As a note: it's always fine to pick up somebody else's work or absorb somebody else's patches, but if you do this you should leave a Co-authored-by: Their Name <their@email> tag in the commit message.

Not just asking because the author of that patch happens to be me, I'm rigerous with this myself :)