-
Notifications
You must be signed in to change notification settings - Fork 38
gcc 12 to 14 updates with libsanitizer and Distribution=13.0, 14.0, 15.0 variants #1080
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Version: 12.3.0 | ||
Revision: 1 | ||
Type: gccver (12) | ||
Distribution: 13.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps also add 14.0 here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fink's naming scheme only allows for a single Distribution in a %v-Dist.info named file afaict, so this needs additional info files (added in next commit) – but a less prolific solution would be much preferred!
Source: mirror:gnu:gcc/gcc-%v/gcc-%v.tar.xz | ||
Source-Checksum: SHA256(949a5d4f99e786421a93b532b22ffab5578de7321369975b91aec97adfda8c3b) | ||
PatchFile: %n.patch | ||
PatchFile-MD5: 7d533489637df18650d997f3139c5772 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incorrect MD5 for patch - should be e245cee9fa6aa2fd5298d7712358e8e1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, fixed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PatchFile-MD5's still don't seem to match in gcc12-13.0.info, and between gcc13.info, gcc13-13.0.info, and gcc13-14.0.info
4051225
to
de95d59
Compare
I have now tried the following combinations:
Both compile and appear to work as intended (at least to the point where fftw3 and cfitsio build). There is still a mistake in the PatchFile-MD5 field in gcc12-13.0.info, and mismatches in this field between the different gcc13 variants (I'm not sure which is correct - I haven't got around to building GCC13 yet, and probably won't for a few days). Thank you for submitting this PR! |
de95d59
to
4417407
Compare
|
I tried testing this PR on Big Sur with Xcode 13, but got these results:
|
Does this PR make PR #928 obsolete? |
Yes, I think everything relevant especially for the first gcc11 and gcc12 ports has already been cherry-picked, and the rest must be outdated by now. |
On Sonoma with Xcode 15.1 the gcc12 build fails with various, generally random internal compiler errors after Stage 3; status with Xcode 15 on Ventura is unclear – might be best to pull the Distribution 12.0/13.0 versions. Update: on High Sierra gcc 13.2 fails to build on a missing header in stage 3:
So this might be a blocker for updating past gcc11 on older systems. |
I just compiled gcc11, and gcc12 with these package definitions on the following systems |
Thanks for confirming the build on Ventura! |
I have issues with blas on arm64. It crashes when executing tests. Haven't examined if that is a blas or with gcc. |
Anything related to #908 (comment)? |
Do you mean related to it being merged, or related to the problem that it was meant to address? |
I've updated gcc12 and gcc13 to their latest releases, but with Xcode 16 (now also on macOS 14.7) a new aarch64 assembly failure for
which I only found fixed in gcc14. My assembly skills did not allow me to isolate the exact fix, so I backported the entire file and its associated Tested so far on Sonoma 14.7 with Xcode 16.0 and Monterey 12.7 with Xcode 14.2 (arm64) and on 10.13 - 10.14.7, Xcode 10.1 - 11.3 for x86_64 Tried to fix 12.4 with the same patch, which fixes the assembly error, but then fails on
so I am removing the 14.0 and 15.0 dists for now. Adding the gcc14 packages as well, 14.2 however fails to build on HighSierra 10.13 with Xcode 10.1.0.0.1.1539992718 on
(did not submit a bug report to Apple since I don't expect they have any further work on Xcode 10 scheduled ;-) Tested to build, and generally also to compile OpenBLAS, on macOS 10.14.7 - 15.1; I assume < 10.13 will fail as well, can't tell for sure for earlier versions of 10.14. |
I've tried building GCC 14.2 on an Intel processor, running MacOS 14.7.1 with command-line tools 16.1. And unfortunately it fails with a similar assembly issue to that mentioned above, while building libgcc:
|
Building gcc14 still fails with the same issue as before on an Intel processor, MacOS Sonoma 14.7.4 / Darwin 23.6.0, Xcode command-line tools 16.2. |
Those look similar to the errors in Is there any working gcc on 14.x and x86_64 then? For arm64 with Xcode 16 there definitely is none at this point, so it would be good to get this unblocked. I could remove the gcc14-14.0 distribution then; if so, should I do it for Intel only (apparently we have an |
f5c471e
to
cf99a0f
Compare
I have submitted the issue with Intel processors as iains/gcc-14-branch#19. I have now upgraded this machine to MacOS 15.3.2, but see the same errors as before. |
Following advice from @iains (on the thread linked above), it looks like the issue on Intel processors was related to the presence of GNU's objdump, as installed by Fink's objtools, on the path causing problems in the detection of clang's assembly features. This can be overridden by adding |
I can also confirm that GCC 13.3 builds on MacOS 15.4 on Intel with the same fix applied. |
It would be great if the change suggested above could be added, so this can be merged soon! |
The general version-bump of gcc12 seems fine. I see that it's only for up through OSX 13.0. Is the 13.0 trick also portable to 14.0 and 15.0? Adding new gccXX with whatever tricks are needed per platform seems fine. I see that gcc14 is only for OSX 13.0 and above. Is it not buildable on older OSX? We can obviously take what we have now and then spread it to those missing platforms as soon as someone figures out how, just want to make sure I understand what we have now. |
Answering one of my own questions... gcc14 FTBFS on 10.13 with a clang crash and
So at least for now, gcc13 will be the highest gccXX that is available on all OSX. |
Not quite sure what you are doing here. I test on x86_64-darwin17..24 (macOS10.13..macOS15) and i686-darwin9 and 17 (using available Xcode CLT installs). I sometimes test on 10.12 and earlier (but limited on what test hardware I have available) .. there's no reason to expect that there would be any build issues on versions >= 10.5. All of these platforms work with unpatched GCC 12.5, GCC-13.4, GCC-15.2 (soon to be released) and gcc-16 development. See, for example, the test results for 15.2 release candidate and for this weekend's trunk (gcc-16) You need a patched branch to build arm64 - but for x86_64/i686 it should "just work"... so you should look for fallout from some other component. |
I'm OS X 10.13 on an x86_64 Mac. I took the gcc14.info and adjusted Distribution to include 10.13, so that .info has all the patch/script magic that is used. Here's the fail:
but it seemed pointless to report something to them on a long-unsupported OS X. But in particular there is no .crash file in the Logs/DiagnosticReports in my homedir. The run script is:
The associated .c is about 7MB if you want it. |
Apologies, but I am not able to analyse or support the non-standard builds of the distribution(s) - simply not enough time :) ... the point I was making is that GCC is regularly tested on (at least) versions of macOS back to 10.13 (using the "standard" Apple-released Xcode CLTs for the assembler/linker/dsymutil) - so if it is not working in your configuration, the problem may lies with some replacement for those tools (or, perhaps some build-time tool).. It should be possible to have GCC up to current trunk working there. |
Thanks for dropping by, and continuing to support/test your mainline on our old platforms. I'm just testing the fink package, which obviously has a lot of patch and I don't know anything about that myself. |
Using patches from cf99a0f:
On 13.7.1/x86_64,
So looks like |
I've edited the top comment to add what I think are the current status of tested gcc versions from here against distritbutions. So far the only fail I'm sure of is gcc14/10.13 via @dmacks and the x86_64 problems on 15.x with objtools via @PovlAbrahamsen (which has a workaround). If you know a combination either passes or fails, please add so it's easier to know the situation |
For the record, I am probably no longer able to test things on 10.13. |
Counterpart of #1033 for gcc versions 12.3 and 13.2, with patches from the gcc arm64 team copied from Homebrew.
Adding the same experimental build of AddressSanitizer and ThreadSanitizer tools as for gcc11 – however libasan in particular is untested with gcc13.
Tested on 13.4 and 12.7 arm64 and x86_64/Rosetta, and on 10.14.6 x86_64; still needs testing on latest 13.x arm64 with Xcode 15.
gcc12
PASS 10.14.6/x86_64 @dhomeier @nieder
PASS 13.7/x86_64 @nieder
FAIL/PASS 15.4/x86_64 with
with-build-time-tools
comment @PovlAbrahamsenPASS arm64 @dhomeier
gcc13
PASS 10.14.6/x86_64 @dhomeier @nieder
PASS arm64 @dhomeir
gcc14
FAIL 10.13 comment @dmacks
PASS 10.14.6/x86_64 @dhomeier @nieder
FAIL/PASS 15.4/x86_64 with
with-build-time-tools
comment @PovlAbrahamsenPASS arm64 @dhomeir