Add LLVM 19.1.x support for LDC

[liushuyu]

This pull request adds LLVM 19.1.x support for LDC. It is based on previous work by @kinke and @thewilsonator in #4763 and #4735.

Some CI setup is required because it needs 19.1.3 binaries in the forked LLVM repository.

[kinke]

Cheers! I'm preparing the LLVM fork based on v19.1.3.

[kinke]

Okay not looking bad, just lit-test failures to look into, most apparently intrinsic-related too.

[liushuyu]

Done; now all tests passed on CI systems. I also "accidentally" fixed a D-Compute regression introduced in the LLVM 18 port.

[kinke]

Awesome! - I've released https://github.com/ldc-developers/llvm-project/releases/tag/ldc-v19.1.3, so we can switch back to v19.1.3 in the YAMLs.

[liushuyu]

Awesome! - I've released https://github.com/ldc-developers/llvm-project/releases/tag/ldc-v19.1.3, so we can switch back to v19.1.3 in the YAMLs.

Done. I have edited your commit to exclude the commit hash changes.

[liushuyu]

Done. CI passed again.

[liushuyu]

Oh, I think I accidentally shadowed #4726

[kinke]

@thewilsonator: Please take a look.

[kinke]

@thewilsonator: Is your approval a definitive this-is-OK, or rather a I-guess-it's-OK? :) - Just wondering wrt. #4772 (comment), the missing n parts that clang uses.

[liushuyu]

xcode-select: error: invalid developer directory '/Applications/Xcode_16.app

I don't know why the macOS ARM64 CI runner had a problem. According to https://github.com/actions/runner-images/blob/main/images/macos/macos-14-arm64-Readme.md, the CI runner image did not change. Maybe it is a temporary failure that can be fixed by a retry.

[kinke]

Yeah don't worry about that apparent GHA hickup. And note that I can take care of the remaining nits, I'll add a changelog entry anyway. Just waiting for @thewilsonator to confirm the SPIRV stuff. - Thanks!

[liushuyu]

Yeah don't worry about that apparent GHA hickup. And note that I can take care of the remaining nits,

I will need to rebase the pull request against the latest master branch anyways, I will just address those.

I'll add a changelog entry anyway. Just waiting for @thewilsonator to confirm the SPIRV stuff. - Thanks!

For the context, the new data layout string comes from: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L248-L276

[kinke]

For the context, the new data layout string comes from: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L248-L276

Ah thx. I see there are similar strings for SPIRV targets a bit below: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L321-L367. Those have an extra n8:16:32:64- before the G1 suffix.

[liushuyu]

For the context, the new data layout string comes from: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L248-L276

Ah thx. I see there are similar strings for SPIRV targets a bit below: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L321-L367. Those have an extra n8:16:32:64- before the G1 suffix.

I have tested both data layouts; the one with the n8:16:32:64- part will make LDC explode due to "mismatching data layout." I believe Clang have atomics enabled inside their configurations, while LDC doesn't. Correction: nxx part should mean the target has native registers for the sizes specified after the n character. I guess it's a format issue?

[liushuyu]

Rebased the pull request against the latest master branch.

[liushuyu]

The CI blew up because CircleCI recently upgraded their VM host to Ubuntu 24.04 which uses 6.8.0-1018-aws that changed how ASLR (Address Space Layout Randomization) works. This breaks the sanitizers in Ubuntu 20.04 container images because they can't function correctly in a high entropy ASLR environment.
Please see google/sanitizers#1716 (comment)

[kinke]

Thx for digging wrt. Circle! Keeping CI working can be tedious at times indeed. I lean towards trying to use the latest Ubuntu image (24.04 or 24.10) for Circle (the 2 jobs don't offer much value, not covering a lot that isn't covered by other CI jobs); hopefully their gdb is recent enough to not hit #4389, which is the main (only?) blocker for using more recent distros for CI.

[liushuyu]

Thx for digging wrt. Circle! Keeping CI working can be tedious at times indeed. I lean towards trying to use the latest Ubuntu image (24.04 or 24.10) for Circle (the 2 jobs don't offer much value, not covering a lot that isn't covered by other CI jobs); hopefully their gdb is recent enough to not hit #4389, which is the main (only?) blocker for using more recent distros for CI.

I see, Ubuntu 24.04 is the first release that got GDB regression fixed. Also Ubuntu 22.04 will also get this regression fixed very soon: https://launchpad.net/ubuntu/+source/gdb/12.1-0ubuntu1~22.04.3

[kinke]

Feel free to add a changelog entry yourself, analogous to

ldc/CHANGELOG.md

Line 33 in 00a4493

- Support for [LLVM 18](https://releases.llvm.org/18.1.0/docs/ReleaseNotes.html). The prebuilt packages use v18.1.5 (except for macOS arm64). (#4599, #4605, #4607, #4604, #4628, #4642)

and

ldc/CHANGELOG.md

Lines 37 to 38 in 00a4493

	#### Platform support
	- Supports LLVM 11 - 18.

Note that there's this already, please remove it (but maybe keep the PR reference):

ldc/CHANGELOG.md

Line 5 in 00a4493

- LLVM for prebuilt packages bumped to v18.1.8 (incl. macOS arm64). (#4712)

[liushuyu]

Done. Changelog entries added.

[kinke]

Thanks mate; I'll merge manually after CI has run - we've run out of free credits for Cirrus CI for this month.

[liushuyu]

Thanks mate; I'll merge manually after CI has run - we've run out of free credits for Cirrus CI for this month.

There's https://github.blog/news-insights/product-news/arm64-on-github-actions-powering-faster-more-efficient-build-systems/#github-and-arm-a-new-class-of-image; maybe we will be able to use these (hopefully) next year.

[kinke]

Yep that's exactly the announcement I'm waiting for; I assumed/hoped they'd open it to the public in this year still.

[liushuyu]

Update: https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/