Possible issue with availability macros #4
Comments
|
does the patch I pushed onto the 14.1 branch fix this? edit: The availability handling was on trunk and also on the pre-releases - so there was a chance to catch this before we shipped .. but such is life ... |
|
The current Homebrew patch for 14.1 is https://raw.githubusercontent.com/Homebrew/formula-patches/82b5c1cd38826ab67ac7fc498a8fe74376a40f4a/gcc/gcc-14.1.0.diff. I tried some quick searches and apparently your patch was not included. If so, @fxcoudert, can you update the Homebrew patch to include it? |
it would be a good idea to check that it fixes your issue first, perhaps? |
|
You mean to append a patch based on 75ff8c3 to the large homebrew patch? I'll try to do this today and report the result. |
yes, that would be great; thanks! |
|
The new macOS Intel binaries built on 10.14 with TARGET 10.13 passed all tests on:
The macOS arm64 binaries built on 11.7 with TARGET 11.0 also passed the tests on GitHub 14.5. From my point of view I would say that the problem was fixed. Thank you for your quick reply. When do you plan to add a |
|
this is the only report against the r0 so far - so I am happy to tag an r1. as for whether homebrew / macports etc. update - I cannot comment (but note: @fxcoudert) |
ok, please do it, for now I'll assume there will be no further immediate commits and I'll proceed with my 14.1 release. |
|
I think I was a bit too hasty, the arm64 tests were not performed on the GitHub 14.5, but on my own 11.7, and thus passed. When I tried on GitHub 14.5, some of the tests failed; I'll open a separate issue with the findings. But this issue related to the availability macros seems fixed. |
|
I'm in the middle of releasing 13.3, using the official archive and the Homebrew patch, I encountered the following error while running the binaries generated for 10.13 on a more recent macOS: A similar error occurs while testing the arm64 binaries. Is it possible to back-port the fix to the 13 branch? |
|
The problem is, in my opinion, more general. The "hacking" of headers through GCC's fixincludes is fragile: it means that, for some a limited number of headers, we read the local (patched) copy generated during gcc build instead of read the system one. The logical consequence is: if you run against a different SDK than you compiled for, you introduce a mismatch of headers. And we won't be able to guarantee that it works for most cases. The long-term solution is: making GCC able to parse SDK headers better, and Iain has done great work on that. |
Fully agree, Iain has done a great work, and, on long term, if a more robust solution can be implemented, it is welcome. On short term, according to my tests, the solution used in the 14 branch seems functional. It would be great to be able to back-port it to the 13 branch too. |
Yes, I'm testing the back port. as @fxcoudert says, the long-term solution is to be able to consume the SDKs without changes - or, equivalently, to provide our own SDK. Neither of these is very easy:
We're making some progress on the first, GCC-14 has two huge steps (handing __has_extension/feature and the availability attribute)... but some things remain and some are quite hard. |
Any progress on this? |
most of the runs are complete - hopefully the remainder will complete tonight. |
|
As discussed in iains/gcc-13-branch#1, the issue was caused by a misunderstanding, the HB patch is not identical to tagged commits here, and the commit fixing the availability macros was not included in HB 13.3. |
Here during overload resolution we have two strictly viable ambiguous candidates #1 and #2, and two non-strictly viable candidates #3 and #4 which we hold on to ever since r14-6522. These latter candidates have an empty second arg conversion since the first arg conversion was deemed bad, and this trips up joust when called on #3 and #4 which assumes all arg conversions are there. We can fix this by making joust robust to empty arg conversions, but in this situation we shouldn't need to compare #3 and #4 at all given that we have a strictly viable candidate. To that end, this patch makes tourney shortcut considering non-strictly viable candidates upon encountering ambiguity between two strictly viable candidates (taking advantage of the fact that the candidates list is sorted according to viability via splice_viable). PR c++/115239 gcc/cp/ChangeLog: * call.cc (tourney): Don't consider a non-strictly viable candidate as the champ if there was ambiguity between two strictly viable candidates. gcc/testsuite/ChangeLog: * g++.dg/overload/error7.C: New test. Reviewed-by: Jason Merrill <jason@redhat.com> (cherry picked from commit 7fed7e9bbc57d502e141e079a6be2706bdbd4560)
As I previously reported, I had successful builds of GCC 14 on
In all cases I used the Homebrew patches, and running the extensive tests locally passed.
However, when making the final distribution binaries, I noticed that running the 10.13 binaries on newer machines fails during preprocessing, with errors related to the availability macros.
I isolated a preprocessor command for a simple hello program, and the result is:
If I understand this right, the fixed
stdio.hinvokes the__API_AVAILABLEmacro with 4 arguments, and, after a sequence of headers, the call ends somehow in a more recent header which expects 6 arguments.To make things worse, the same binaries are no longer functional even on a macOS 10.13 but having a different SDK (xcode10.1), for example the one available on Travis CI:
Here the system header expects 3 arguments, and receives 4, plus other errors.
Did I misconfigured my build or is this a compatibility issue with older systems, that was introduced with the recent changes in 14.x?
For the xPack distribution this issue is a show stopper; all other binaries (Windows, Linux Intel, Linux aarch64, Linux arm, macOS arm64) are functional, only the macOS Intel, which is expected to run on everything from macOS 10.13 up, is failing.
Any suggestions?
The text was updated successfully, but these errors were encountered: