[Bug c++/113968] ICE: in create_tmp_var, at gimple-expr.cc:488 with -fcontracts and invalid member in contract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113968 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Sandoe --- fixed on trunk, no back port planned.
[Bug c++/116490] ICE in build_contract_condition_function, at cp/contracts.cc:1463 for explicitly instantiated Function Contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116490 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||iains at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- fixed on trunk, no back port planned.
[Bug c++/98935] [coroutines] co_await on statement expressions causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98935 Iain Sandoe changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Iain Sandoe --- It has indeed regressed on trunk
[Bug c++/116914] [15 regression] ICE when building plasma-nm-6.1.5 (gimplify_var_or_parm_decl, at gimplify.cc:3309)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116914 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-10-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Iain Sandoe --- I suspect this is a DUP of 115851 (to be confirmed).
[Bug c++/116880] [15 Regression] too early coroutine destruction of co_await on nix-2.24.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880 --- Comment #5 from Iain Sandoe --- Created attachment 59220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59220&action=edit patch under test Here is what I'm testing - if you have a chance to test it in your scenario that would be great.
[Bug c++/116880] [15 Regression] too early coroutine destruction of co_await on nix-2.24.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2024-09-28 00:00:00 |2024-9-29 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe --- (In reply to Sergei Trofimovich from comment #3) > Bisected it down to r15-3146-g47dbd69b1b31d3. That was what I expected as noted on IRC. I will not make this a dup - as it's a different manifestation (of the same issue). > The real test is a bit involved as it requires a running an > installtestsuite, relies on boehm-gc and an interpreter language on top if > it. I build it as: OK let's not worry about that then - 116506 has a test case too (and I think to make one that covers this more generally). I have a fix in progress (v1 was review and needed rework).
[Bug c++/116880] [15 Regression] too early coroutine destruction of co_await on nix-2.24.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880 Iain Sandoe changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116506 Target Milestone|--- |15.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-09-28 --- Comment #2 from Iain Sandoe --- I think it's more likely related to 116506 than 102217 - but let's see when we analyse more.
[Bug c++/116880] [15 Regression] too early coroutine destruction of co_await on nix-2.24.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116880 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- thanks for the report however - the revision mentioned seems to be a change in documentation? It is possibly related to PR116506 (to be confirmed) - is it possible to attach the original (executable) test case?
[Bug libstdc++/116853] [15 regression] Bootstrap fails on Darwin, Solaris after r15-3859-g63a598deb0c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853 --- Comment #4 from Iain Sandoe --- fixed on Darwin, if it also works for Solaris then please feel free to close the BZ.
[Bug libstdc++/116853] New: [Regression 15] Bootstrap fails on *-darwin* after r15-3859-g63a598deb0c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853 Bug ID: 116853 Summary: [Regression 15] Bootstrap fails on *-darwin* after r15-3859-g63a598deb0c9 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: jason at gcc dot gnu.org, redi at gcc dot gnu.org Target Milestone: --- Three fails of the form: /scratch/12-mon-rosetta/gcc-master/prev-x86_64-apple-darwin21/libstdc++-v3/include/bits/basic_string.h:4410:43: error: argument of function call might be a candidate for a format attribute [-Werror=suggest-attribute=format] 4410 | return __gnu_cxx::__to_xstring(&std::vsnprintf, __n, |~~~^~ 4411 |"%f", __val); | (line 4420 and 4430 the same). This does not appear to be bogus - but in ext/string_conversions.h we have only a template for this which does not accept the attribute. I am testing the following work-around - but that might not be the preferred solution: diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h index 976577f8f22..e9b17ea48b5 100644 --- a/libstdc++-v3/include/bits/basic_string.h +++ b/libstdc++-v3/include/bits/basic_string.h @@ -4399,6 +4399,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 return __str; } #elif _GLIBCXX_USE_C99_STDIO +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wsuggest-attribute=format" // NB: (v)snprintf vs sprintf. _GLIBCXX_NODISCARD @@ -4430,6 +4432,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 return __gnu_cxx::__to_xstring(&std::vsnprintf, __n, "%Lf", __val); } +#pragma GCC diagnostic pop #endif // _GLIBCXX_USE_C99_STDIO #if defined(_GLIBCXX_USE_WCHAR_T) && _GLIBCXX_USE_C99_WCHAR
[Bug libstdc++/116853] [Regression 15] Bootstrap fails on *-darwin* after r15-3859-g63a598deb0c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853 Iain Sandoe changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116847 Target Milestone|--- |15.0 Last reconfirmed||2024-9-26
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 --- Comment #4 from Iain Sandoe --- (In reply to Rainer Orth from comment #3) > The patch also broke Solaris bootstrap; will report that separately. likewise *-darwin* (also have a report in preparation).
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #30 from Iain Sandoe --- (In reply to Chris Jones from comment #29) > Iains, I was not trying to suggest with my last post what you should > support, that is entirely up to you and we are very grateful for what you do > do. > > I was simply trying to expand on (and correct a bit) some of the points > raised by Mark. Sure .. and if it appears I am grumpy, then apologies - that's not the intent. The bottom line is that we have to have some "supported" configuration set (and try to make that as wide as possible). I completely accept that end-users will do whatever they choose - but I think we all (at least those of us responsible for producing and distributing the toolchains) need to have position that "the following set of things, which are readily available on your platform work, correctly together - if you move outside of that you might be on your own". I have some ideas about how we can improve our lives re. the SDKs - but they need some moderate lifting coding-wise. Likewise we could isolate ourselves from dependency on Xcode for the assembler and linker - but also at the cost of extra maintenance (which, so far, we have chosen not to take on).
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #28 from Iain Sandoe --- Folks - we all want ponies... ... but remember this is a toolchain - it is quite complex; expecting any random permutation of things that you happen to choose to DTRT will probably disappoint you. Xcode does not attempt this with a team of people working on it for $dayjob - so we should really really not expect it for a 'team' of one working on it for $hobby. My thinking is that downstream is free to do whatever that they choose - but there has to be a limit on what we can support - all the permutations are simply not feasible ether to test or reason about. I want GCC to be an excellent compiler for Darwin - but that does mean being willing to operate within _some_ constraints.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #25 from Iain Sandoe --- (In reply to Mark Mentovai from comment #24) > (In reply to Iain Sandoe from comment #23) > > OK. I don't want to argue about the details / usability etc. etc. ( but note > > that __symbols are for the implementation and the compiler is part of the > > implementation ). In principle, we should have dialogue between the > > compiler 'vendors' (we do upstream) - but usually the first we know about > > what's happening with SDKs is when something does not work. > > I mentioned the __ thing only to illustrate how these are a little outside > of the normal application of the SDK. > > Apple’s made it pretty clear over the years that they consider themselves to > own the entire implementation, end-to-end, privately. > > This isn’t just a GCC problem. They’ve bought into clang in a very big way > and contribute to open-source LLVM. Trunk clang still has incompatibilities > with the newly released macOS 15 SDK (example: > https://chromium-review.googlesource.com/c/5622510/comments/ > 04615850_0139eb2f). 1. but you have identified that this cannot work when symbols are removed from a library .. as we see here 2. That is definitely not the case for CLT - and I do not install Xcode (i have too many test boxes) $ ls /XC/14.1/CommandLineTools/SDKs/ MacOSX.sdk MacOSX12.3.sdk MacOSX12.sdkMacOSX13.0.sdk MacOSX13.sdk $ ls /XC/15.1b/CommandLineTools/SDKs/ MacOSX.sdk MacOSX13.3.sdk MacOSX13.sdkMacOSX14.0.sdk MacOSX14.sdk > > So, the solutions that work are: > > > > 1. when building for macOS 14, use the macOS 14 SDK (that is actually my > > default action on all OS versions - use the last SDK provided for it). > > Infeasible, though. It’s been a very long time since Apple bundled more than > one SDK per platform in Xcode. (The last time they did was Xcode 6.4 in > 2015, with 10.9 and 10.10 SDKs, and some early Xcode 7.0 betas.) I really > liked picking-and-choosing an appropriate SDK, but Apple decided that > availability annotations were good enough for developer purposes and moved > everything over to a single SDK only. this solution manifestly does work - since i use it - and the downstream projects like HB and macports, I thought recommended installing the CLT? .. however > > 2. Drop the legacy lib from macOS 14 as well. > > > > given that users will probably just use what xcrun gives them, 2 (as you > > propose) is probably least likely to get us a lot of bogus bug reports. > > Yeah, exactly. It’s not even going to be a matter of “what xcrun gives > them”, there will be a large enough number of macOS 14 systems with > developer tools but a macOS 15 SDK instead of a macOS 14 SDK. The SDKs are > going to be updated in the wild, I don’t think GCC has much of an option to > try to require that macOS 14 stick with that exact SDK. You need to be very careful here - because of the fixincludes we have not been able to drop yet (and some that will be very hard to drop because the SDKs are incompatible with legal C and C++) this does mean that the SDK that the compiler was built with does matter to them. In some cases, this means the compiler will not function with a different SDK from the one it was built with. I wish we could drop all the fixincludes - or find an alternate solution - but until then we're stuck with this. Anyway - the bottom line is that I agree with removing the legacy lib from macOS 14 (even if we do not completely agree on the reasons) .. will try to test & push the patch ASAP
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #23 from Iain Sandoe --- (In reply to Mark Mentovai from comment #22) > (In reply to Iain Sandoe from comment #21) > > Thta is quite surprising - since the SDK should reflect the symbols exported > > by the libraries installed on the target system. Therefore, they should be > > present when the target is macOS 14; > > For the purposes of having appropriate declarations available for compiling, > the declarations in the SDK’s headers generally are annotated with > availability and obsolescence annotations. Apple is fairly good about this. > > For the purposes of linking, the SDK simply exposes the set of global > symbols exported by loadable modules, previously in stripped-down Mach-O > format containing little more than a symbol table, but nowadays (since SDK > 10.11) in .tbd format. Neither the Mach-O symbol table nor the .tbd format > have a way to express partial availability. The .tbd files are produced as a > simple export of the source Mach-O’s symbol table. (In reply to Mark Mentovai from comment #22) > (In reply to Iain Sandoe from comment #21) > > Thta is quite surprising - since the SDK should reflect the symbols exported > > by the libraries installed on the target system. Therefore, they should be > > present when the target is macOS 14; > > For the purposes of having appropriate declarations available for compiling, > the declarations in the SDK’s headers generally are annotated with > availability and obsolescence annotations. Apple is fairly good about this. > > For the purposes of linking, the SDK simply exposes the set of global > symbols exported by loadable modules, previously in stripped-down Mach-O > format containing little more than a symbol table, but nowadays (since SDK > 10.11) in .tbd format. Neither the Mach-O symbol table nor the .tbd format > have a way to express partial availability. The .tbd files are produced as a > simple export of the source Mach-O’s symbol table. OK. I don't want to argue about the details / usability etc. etc. ( but note that __symbols are for the implementation and the compiler is part of the implementation ). In principle, we should have dialogue between the compiler 'vendors' (we do upstream) - but usually the first we know about what's happening with SDKs is when something does not work. === So, the solutions that work are: 1. when building for macOS 14, use the macOS 14 SDK (that is actually my default action on all OS versions - use the last SDK provided for it). 2. Drop the legacy lib from macOS 14 as well. given that users will probably just use what xcrun gives them, 2 (as you propose) is probably least likely to get us a lot of bogus bug reports. I'll push this after a little more testing (and likewise on 14.2-darwin) other gcc versions can follow along once we've seen this bake a little on those.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #21 from Iain Sandoe --- (In reply to Mark Mentovai from comment #20) > Created attachment 59189 [details] > Patch for macOS 14/Xcode 16 > > (In reply to GCC Commits from comment #19) > > The master branch has been updated by Iain D Sandoe : > > > > https://gcc.gnu.org/g:d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > > > > commit r15-3839-gd9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3 > > Author: Iain Sandoe > > Date: Sun Sep 22 11:43:32 2024 +0100 > > > > libgcc, Darwin: Drop the legacy library build for macOS >= 15 > > [PR116809]. > > Unfortunately, this doesn’t resolve the bug in every place that it might be > encountered. > > The bootstrapping problem occurs when targeting x86_64 and using the macOS > 15 SDK. The macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. > libgcc_s.1 can no longer be built on macOS 14 using Xcode 16 by the same > logic that the above change disabled it for macOS 15. Thta is quite surprising - since the SDK should reflect the symbols exported by the libraries installed on the target system. Therefore, they should be present when the target is macOS 14; Perhaps something not conditional in the way it should be - or it is depending on support for attribute ((availability)) which is only currently committed on darwin branches. If we build a compiler targeting macOS 15, but using xcode 16 on macOS 14 - then we should still eliminate the library.
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #7 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #6) > (In reply to Jonathan Wakely from comment #5) > > > #if defined(__has_feature) && __has_feature(modules) > > > > This is a bug. If __has_feature is _not_ define, then __has_feature(modules) > > would not compile > > Definitely agree, I had missed that, thanks for highlighting it. Every year > some more examples crop up into the SDKs, and every year I report them. > > Reported the examples in macOS 15.0 SDK as FB15255066 > A copy of that report is available there: > https://gist.github.com/fxcoudert/1e3ed3470febf220a392152189c143a3 > > > It looks like the header now assumes that if __has_feature(modules) is > > true, then they're compiling with Clang. Which is not true because GCC > > supports __has_feature now. > > Before I report this to Apple, I want to have an opinion: Iain, what do you > think is the best fix there? Do we want to suggest Apple not bypass > USE_CLANG_TYPES on GCC? At this point (with no other evidence) it would seem to me to be best if clang-specific stuff used __clang__ in the tests (we do _not_ set that in GCC, whereas testing __GNUC__ needs other checks to disambiguate). We might well want to reconcile or add pp defines to match the clang ones if that is creating problems - but I'd expect the underlying types to be unchanged (since that's going to break ABI otherwise). It's not clear to me yet why the change has been made (sorry this is not probably very helpful)
[Bug c++/116775] C++20 Coroutine await_suspend is unexpectedly executed when using in __builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775 --- Comment #6 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #4) > So, e.g. co_await_find_in_subtree/await_statement_expander/find_any_await > and maybe other coroutines.cc cp_walk_tree callbacks could use some helper > for CALL_EXPR and in that case if it is a BUILT_IN_CONSTANT_P call and the > argument has TREE_SIDE_EFFECTS, set *walk_subtrees = 0. that seems reasonable. (In reply to Jakub Jelinek from comment #5) > On the other side, perhaps completely ignoring CO_AWAIT_EXPR in there (dunno > about others) might not be correct either, I guess the function is supposed > to be still considered a coroutine. > So perhaps it needs to be treated more like 0 && co_await ... or if (false) > co_await ... or something similar. > Also note there are other functions which ignore their argument > side-effects, I think e.g. __builtin_classify_type does. > And wonder about [[assume (co_await ...)]]; A lot of these interactions are not spelled out (and were probably not really throught about much, I guess). I am not sure that an await_expression can be BUILT_IN_CONSTANT_P because its value is the output of awaiter.await_resume() - so that, even if awaiter.await_ready() is always true - there is still a function call to obtain the result. Having said that ... I wonder about constexpr on await_resume () [coroutines cannot be constexpr, but thay can contain constexpr].
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #16 from Iain Sandoe --- FAOD: - The current patch is to remove at macOS-15 - I have tested on systems that need to keep the lib - FX is testing on macOS 15. * I have already pushed the dependent patch that limits the libgcc range to 11+ from 11. * IFF we find that there are end-user issues with some weird way in which they are dependent on the GCC-installed libgcc_s.1 (that should really not happen) - then we will investigate pruning the symbols list (but that pruning would be matched to the system versions that it relates to - so there should be no concern in anyone's mind that we would be altering the behaviour for earlier ones). so .. as soon as I get a confirmation that this is working on macOS 15 (and likewise I have a queued patch on gcc-14-2-darwin) .. I'll land the fix.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #14 from Iain Sandoe --- (In reply to Mark Mentovai from comment #12) > Created attachment 59179 [details] > Drop removed unwind symbols > > This implements what I referred to as my preferred option in comment 10. It > should apply on the trunk and to all active branches. as specified, I think this will break Darwin <= 9 (and maybe ppc on 10) which still look up the frame info. the long-term goal here is to simplify the GCC as much as possible - we have such limited resources - so any removal is a bonus. --- NP about the mid-airs :) it happens...
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #11 from Iain Sandoe --- Indeed, all of this is well-known; NOTE: there is no change proposed for any OS < macOS 15. We actually bumped our libgcc_s version some time ago because GCC has for a while now been pulling the unwinder directly from libSystem (or /usr/lib/libgcc_s.1.dylib on darwin9). So GCC will not (for several releases now) be emitting any reference to libgcc_s.1.dylib - and on darwin9 (which actually needs the installed /usr/lib/libgcc_s.1.dylib) as said, there's no change proposed To use the GCC legacy lib - you'd have to use DYLD_LIBRARY_PATH to force point to an installation - otherwise the installed version in /usr/lib would (and should) be used anyway .. My view is that we want to remove this sometime - like Apple, eventually "legacy" has to be "we no longer care" .. so my preference is to remove it - and if we should get fallout - then we can consider an alternate solution with an edited symbols list.
[Bug target/116237] gcc does not accept -weak_framework without -Wl on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116237 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2024-09-22 Ever confirmed|0 |1 --- Comment #3 from Iain Sandoe --- fixed on trunk, leaving open for back ports
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #9 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #8) > (In reply to Iain Sandoe from comment #2) > > Created attachment 59176 [details] > > Patch under test > > Does not apply to upstream GCC. I think it needs "libgcc: limit to 11 from > 11" > https://github.com/iains/gcc-darwin-arm64/commit/ > 1fa7e9c16c259be8d1e2110df5d317ca6ef69635 > > I've started a test of trunk with the two patches applied, on > x86_64-apple-darwin24, and will report here. I'd argue that it makes a > compelling case to push "libgcc: limit to 11 from 11" to trunk. yeah - that is pretty well-backed now .. let me test it individually. I'm limited at the moment because I'm already doing the weekly rebase build/test + limited hardware ( and even if I had more hardware limited enthusiasm for paying a higher electricity bill ;) )
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #7 from Iain Sandoe --- Created attachment 59177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59177&action=edit patch for GCC-14 (***untested) this is against the current darwin gcc-14 branch - it is completely untested.
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #4 from Iain Sandoe --- (In reply to Chris Jones from comment #3) > CN you prepare a version of the patch for the current gcc14 release ? I guess you tried applying the attached patch and it does not ? you mean for the Arm64 development branch - or for upstream releases/gcc-14? (I will do both of course - but testing on trunk first)
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #2 from Iain Sandoe --- Created attachment 59176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59176&action=edit Patch under test Please could folks with access to macOS 15 on x86_64 - test this (I will test on the older boxes where it is more likely to be a problem,
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #1 from Iain Sandoe --- yeah.. the compiler will not (for some several revisions) actually refer to libgcc_s.1.dylib - it is only there to support existing built exes from older compilers. Probably dropping it after macOS 14 is the best option - I'll look at amending the libgcc config to fix this. I don't have a macOS 15 install yet - running out of suitable hardware that is not already busy
[Bug libstdc++/116777] error: 'current_zone' is not a member of 'std::chrono' with -D_GLIBCXX_USE_CXX11_ABI=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777 --- Comment #7 from Iain Sandoe --- as noted in several places; the long-term solution for Darwin (in general since there's an installed /usr/lib/libstdc++.6.dylib even on modern systems) - is for use to use an inline namespace for libstdc++ (always). When that is done, there's no conflict with the older installed .6.dylib s. This work is not finished yet, I have some hacks but not coherent enough to want to put them in the wild. This and Apple blocks are the two biggest issues in making GCC better on Darwin.
[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 --- Comment #14 from Iain Sandoe --- (In reply to Iain Sandoe from comment #13) > looking like a GTY issue: > > (gdb) p target->u.fld[1]->rt_mem > $7 = (mem_attrs *) 0xafafafaf > (gdb) p target->u.fld[1]->rt_mem->align > > that seems to be the tell-tale value for a free ptr. The report issue is not related to the fix for this PR - or any recent coroutine change, I've backed out back to f4915e6c4cd and the ICE remains. NOTE: the test case should still compile with earlier GCC versions, it will not execute correctly - but the ICE is at compile-time. Please, if you are able, could you see if earlier GCC versions ICE in the same way. I guess we need a new PR and some attempt to locate the cause...
[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 --- Comment #13 from Iain Sandoe --- looking like a GTY issue: (gdb) p target->u.fld[1]->rt_mem $7 = (mem_attrs *) 0xafafafaf (gdb) p target->u.fld[1]->rt_mem->align that seems to be the tell-tale value for a free ptr.
[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 --- Comment #12 from Iain Sandoe --- hmm .. this is initialising the ramp return object (which is a handle) and when I look at the to and from trees they seem to have the requisite alignment (the from value is a return from operator new). I'm also pretty sure that there are other test cases with a ramp return which is a coroutine handle... I'm wondering if the patch for this issue has exposed something rather than actually causing it - but I need to build a debuggable compiler next.
[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 --- Comment #10 from Iain Sandoe --- unfortunately, (or ...) I Have not succeeded in reproducing this - so will need some help to identify what's being done differently from you. I built: r15-3667-gf5448384a213 (also on my Darwin17+ set, which includes a 32b host - which also seems fine). On cfarm216 : ../src/configure --prefix=/home/iains/gcc-master/gcc-15-0-0 --with-as=/usr/ccs/bin/as --without-gnu-as --enable-languages=c,c++ --build=sparc-sun-solaris2.11 CC='gcc -m32' CXX='g++ -m32' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240916 (experimental) [master f5448384a21] (GCC) gmake check-gcc-c++ RUNTESTFLAGS="coroutines.exp coro-torture.exp" Running /home/iains/gcc-master/src/gcc/testsuite/g++.dg/coroutines/coroutines.exp ... Running /home/iains/gcc-master/src/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp ... === g++ Summary === # of expected passes2275 # of expected failures 1 # of unsupported tests 1 /home/iains/gcc-master/bld/gcc/xg++ version 15.0.0 20240916 (experimental) [master f5448384a21] (GCC) Your report seems to be a compile-time SIGBUS, which is somewhat surprising for the changes to address this bug - but always one can be surprised, of course.
[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 --- Comment #8 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #7) > > --- Comment #6 from Iain Sandoe --- > > (In reply to Rainer Orth from comment #5) > >> The new test causes a SIGBUS on 32-bit Solaris/SPARC > >> (sparc-sun-solaris2.11): > > > > Is this reproducible on any current cfarm machine? > > I guess so: cfarm216 is current Solaris 11.4/SPARC, the same I use for > my builds. Thanks - could you post your config here, (there's two modes IIRC - with gnu or native binutils - does that make any difference?)
[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 --- Comment #6 from Iain Sandoe --- (In reply to Rainer Orth from comment #5) > The new test causes a SIGBUS on 32-bit Solaris/SPARC (sparc-sun-solaris2.11): Is this reproducible on any current cfarm machine? (or, I guess, on a cross?)
[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-08-29 Status|UNCONFIRMED |NEW CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- after discussion, we are all agreed that the current behaviour is not per standard (or any supposed intent thereof).
[Bug c++/108620] coroutines: ICE: in instantiate_type, at cp/class.cc:8742 when assign the return value of co_yield to a member of class/struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620 --- Comment #7 from Iain Sandoe --- (In reply to Arsen Arsenović from comment #6) > I think it'd be okay to just add the testcase as a regression test consider > this resolved. WDYT, Iain? yes - if it's no longer reproducible - then adding the test case would catch any reappearance (in case it became latent). Let's do that and move on.
[Bug c++/116506] [15 Regression] Destructors of temporary awaitables are executed too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116506 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-08-29 --- Comment #1 from Iain Sandoe --- thanks for the report, confirmed (I am working on a fix).
[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 --- Comment #8 from Iain Sandoe --- (In reply to Artyom Kolpakov from comment #7) > (In reply to Iain Sandoe from comment #6) > > fixed on trunk, waiting for possible back-port > > I'm not sure if I should write this here, but now a warning has appeared in > the original example: unused parameter 'frame_ptr' that should be fixed after r15-3211-g8d6d6c864442.
[Bug c++/102051] [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|NEW |WAITING --- Comment #9 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #10 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/109682] coroutines: ICE in morph_fn_to_coro on wrong return type for get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109682 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #5 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/110635] Segmentation fault when the awaiter's await_resume in initial-suspend returns a class type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110635 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING
[Bug c++/110872] coroutine postcondition is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING
[Bug c++/113773] coroutines: promise deconstructed twice if throwing from return object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/116482] Bogus -Wunused-parameter with C++ coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116482 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Sandoe --- fixed
[Bug c++/116482] Bogus -Wunused-parameter with C++ coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116482 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-08-26 Status|UNCONFIRMED |NEW Target Milestone|--- |15.0 Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe --- confirmed
[Bug c++/108620] coroutines: ICE: in instantiate_type, at cp/class.cc:8742 when assign the return value of co_yield to a member of class/struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620 --- Comment #5 from Iain Sandoe --- (In reply to Peter Damianov from comment #4) > Seems like this is fixed on trunk, it no longer ICEs. > > https://godbolt.org/z/9oGrGq7xq It's fixed (or, at least has become latent) on 14.1 and trunk - probably if we wanted to back port the fix to 13 (?) someone would have to bisect to find the fix.
[Bug c++/101976] When constructing object, calling function and performing co_await in same statement, temporary is erroneously moved trivially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101976 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Iain Sandoe --- (In reply to Jonathan Wakely from comment #3) > Iain, this one seems to be fixed. Should we close it? Yeah, I don't see the need to back port to 12.
[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe --- Created attachment 58948 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58948&action=edit patch under test this patch is on top of other changes - but the principle would be unaltered if made stand-alone. With this the test case produces: Promise() get_return_object() Handle(Promise &) return_void() ~Promise() Which, I think, is what is expected. (I added a promise ctor print).
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 --- Comment #8 from Iain Sandoe --- Created attachment 58946 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58946&action=edit patch under test
[Bug modula2/116378] [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378 --- Comment #13 from Iain Sandoe --- (In reply to Gaius Mulley from comment #12) > Created attachment 58943 [details] > Proposed fix v8 > > Here is a proposed patch for PR 116181, I was wondering how this patch > affects darwin? git master + this patch bootstraps on aarch64, ppc64le, > amd64 GNU Linux. > It resolves all -Wodr warnings (except two). Posting it here as the initial > patch for PR 116181 caused this PR (apologies). I applied the patch and bootstrapped all languages on x86_64-darwin21, smoke test for m2, rust and ada look 'nominal'.. so seems OK for Darwin too.
[Bug c++/113773] coroutines: promise deconstructed twice if throwing from return object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #2 from Iain Sandoe --- Created attachment 58944 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58944&action=edit patch under test
[Bug modula2/116378] [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378 --- Comment #10 from Iain Sandoe --- (In reply to Gaius Mulley from comment #9) > Created attachment 58934 [details] > Proposed fix > > Many thanks Iain and Andrew for your investigation and diagnosis, here is a > patch based on your analysis: works for me on a spot test on x86_64-darwin21 - test results 'nominal'.
[Bug modula2/116378] [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378
--- Comment #8 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #7)
> For glibc (even though the Linux kernel might have a different mode_t idea,
> some targets are unsigned short, e.g. arm-linux-eabi) is always:
> #define __MODE_T_TYPE __U32_TYPE
ah.. I should have added the notes to the c&p
/src-local//m2/mc-boot-ch/Glibc.c:352:16: note: (so you should pass ‘int’
not ‘mode_t’ {aka ‘short unsigned int’} to ‘va_arg’)
/src-local/./m2/mc-boot-ch/Glibc.c:352:16: note: if this code is reached,
the program will abort
So the diagnostics tell us exactly what to expect - and it seems from Andrew's
comments that this is generic.
[Bug modula2/116378] [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378
--- Comment #5 from Iain Sandoe ---
Perhaps there's a need for some target-specific code?
I see entries for Glibc - but nothing for 'posix' or 'windows' - so is the
Glibc code supposed to be generic?
-
In file included from /src-local/./system.h:32,
from /src-local/../m2/mc-boot-ch/Glibc.c:23:
/src-local//m2/mc-boot-ch/Glibc.c: In function ‘int libc_open(void*, int,
...)’:
/src-local//m2/mc-boot-ch/Glibc.c:352:30: warning: ‘mode_t’ {aka ‘short
unsigned int’} is promoted to ‘int’ when passed through ‘...’
352 | mode_t mode = va_arg (arg, mode_t);
|
and the gimple
int libc_open (void * p, int oflag)
{
int D.15836;
struct arg[1];
mode_t mode;
int result;
try
{
__builtin_va_start (&arg, 0);
__builtin_trap (); < and there it is...
mode = MEM[(mode_t *)0B];
_1 = (int) mode;
result = open (p, oflag, _1);
__builtin_va_end (&arg);
D.15836 = result;
return D.15836;
}
finally
{
arg = {CLOBBER(eos)};
}
}
[Bug modula2/116378] [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-08-15 Status|UNCONFIRMED |NEW --- Comment #1 from Iain Sandoe --- reproduced on multiple Darwin versions, so confirming. (guess) Looks to me as if there might be UB somewhere - perhaps a function that should have a return statement is missing it? (see the asm below) example: m2/boot-bin/mc --olang=c++ --h-file-prefix=G -I/src-local/gcc-master/gcc/m2/gm2-libs -I/src-local/gcc-master/gcc/m2/gm2-compiler -I/src-local/gcc-master/gcc/m2/gm2-libiberty -I/src-local/gcc-master/gcc/m2/gm2-gcc --quiet --gcc-config-system -o=m2/gm2-libs-boot/GASCII.h /src-local/gcc-master/gcc/m2/gm2-libs/ASCII.def -v Illegal instruction: 4 * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) frame #0: 0x00010008a279 mc`libc_open + 10 mc`libc_open: -> 0x10008a279 <+10>: ud2 mc`dtoa_dtoa.cold: 0x10008a27b <+0>: leaq 0x526a(%rip), %rdx; "dtoa_dtoa" 0x10008a282 <+7>: movl $0xa4, %esi 0x10008a287 <+12>: leaq 0x526a(%rip), %rdi; "/src-local/gcc-master/gcc/m2/mc-boot-ch/Gdtoa.cc" Target 0: (mc) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) * frame #0: 0x00010008a279 mc`libc_open + 10 frame #1: 0x00013764 mc`ConnectToUnix(unsigned int, bool, bool) (.part.0) + 100 frame #2: 0x00013a8b mc`FIO_openToRead + 91 frame #3: 0x00014809 mc`FIO_exists + 9 frame #4: 0x0001000405a3 mc`mcSearch_findSourceFile + 403 frame #5: 0x0001000362d1 mc`openDef(void*, bool) + 65 frame #6: 0x0001000364cf mc`pass(unsigned int, void*, mcComp_parserFunction_p, decl_isNodeF_p, mcComp_openFunction_p) (.isra.0) + 63 frame #7: 0x00010003653a mc`p1(void*) + 42 frame #8: 0x00010001093c mc`Indexing_ForeachIndiceInIndexDo + 60 frame #9: 0x000100036463 mc`doPass(bool, bool, unsigned int, symbolKey_performOperation_p, char const*, unsigned int) (.constprop.0) + 275 frame #10: 0x000100036919 mc`mcComp_compile + 297 frame #11: 0x00010008a866 mc`main + 758 frame #12: 0x7fff6f105cc9 libdyld.dylib`start + 1 frame #13: 0x7fff6f105cc9 libdyld.dylib`start + 1 Looks like that's hit an unreachable (which has been made into a trap). dis -n libc_open mc`libc_open: 0x10008a26f <+0>: leaq 0x8(%rsp), %rax 0x10008a274 <+5>: movq %rax, -0x10(%rsp) -> 0x10008a279 <+10>: ud2
[Bug modula2/116378] New: [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116378 Bug ID: 116378 Summary: [15 Regression] M2 bootstrap fails on x86_64-darwin after r15-2876 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- Target: x86_64-darwin no analysis so far, but the fixes in PR116181 do not resolve this: make[3]: *** [m2/gm2-compiler-boot/P0SyntaxCheck.mod] Illegal instruction: 4 make[3]: *** Waiting for unfinished jobs make[3]: *** [gm2-ebnf.texi-check] Illegal instruction: 4 make[3]: *** [m2/gm2-compiler-boot/PCBuild.mod] Illegal instruction: 4 make[3]: *** [m2/gm2-compiler-boot/P1Build.mod] Illegal instruction: 4 make[3]: *** [m2/gm2-compiler-boot/P2Build.mod] Illegal instruction: 4 make[3]: *** [m2/gm2-compiler-boot/P3Build.mod] Illegal instruction: 4 make[3]: *** [m2/gm2-compiler-boot/PHBuild.mod] Illegal instruction: 4
[Bug c++/115660] internal compiler error: in build_special_member_call, at cp/call.cc:11085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115660 --- Comment #5 from Iain Sandoe --- (In reply to Arsen Arsenović from comment #4) > this PR was fixed by r14-8437-g44868e7298de50 (fix for PR c++/109227). > > iain, jason, should we backport that patch? (and resolve that PR?) seems reasonable from my point of view, providing it does not depend on other FE changes (and resolves the fail there).
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #10 from Iain Sandoe --- (In reply to Eric Gallager from comment #9) > Ah, looking at gcc/ada/gcc-interface/Makefile.in, perhaps the issue is that > I need to set GNATLINK in my environment, too, besides just GNATMAKE and > GNATBIND... perhaps the issue was arising due to having had a version > mismatch previously... please try the simple case first [see NOTE4 above] - once you can repeat that - adding more configure stuff can be done ... if you only have one, consistent GCC bootstrap compiler in your path it should just work (modulo the issue with Xcode claiming gcc/g++)
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #8 from Iain Sandoe --- (In reply to Eric Gallager from comment #7) > Well ok, could someone send me a binary x86_64 build of GCC for darwin20 > with Ada support that they can bootstrap with successfully, then, so that I > can get back to bootstrapping, too? Either that, or send me the files that > gen_il-main generates... Eric: To the best of my knowledge every release of GCC after 4.6 (when we fixed powerpc-darwin9) should bootstrap correctly on all Darwin archs supported by upstream (i.e. not including Arm64 yet). There can be (sometimes extended) periods where trunk (or even branches) are broken for some/all Darwin - since there's not many folks fixing it - but x86_64 is not currently broken anywhere AFAIK. = Bringing up Ada on a new plafform version - the devil is in the details: AFAIK you have a copy of my gcc-7.5-darwin19 toolchain? This _is_ sufficient to build a new bootstrap compiler on Darwin20 including Ada. the following should work - for 11.5, 12.4, 13.3, 14.2 and trunk .. $ uname -v Darwin Kernel Version 20.6.0: Thu Jul 6 22:12:47 PDT 2023; root:xnu-7195.141.49.702.12~1/RELEASE_X86_64 1. start a shell with just the normal OS PATH 2. you need to have texinfo-6.7 or similar ahead of the OS version (which is not new enough to support trunk). 3. My PATH looks like: PATH=/opt/iains/x86_64-apple-darwin20/gcc-build-tools/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/iains/x86_64-apple-darwin19/gcc-7-5-toolchain/bin The first entry has texinfo-6.7 and dejagnu. 4. $ gnatmake --version GNATMAKE 7.5.0 there is no other GCC or gnatmake in my PATH - but remember that Xcode will claim 'gcc/g++' is 'clang/++'. 5. configure: /src-local/gcc-master/configure --prefix=/opt/iains/x86_64-apple-darwin20/gcc-15-0-0 --build=x86_64-apple-darwin20 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk --disable-libstdcxx-pch --enable-languages=all CC=x86_64-apple-darwin19-gcc CXX=x86_64-apple-darwin19-g++ NOTE1: we _have_ to put CC and CXX because otherwise we run into problems because of the claiming of gcc/g++ as above. NOTE2: x86_64-apple-darwin19-gcc <<- this MUST match the version of gnatmake (there's only one in the PATH so that should be OK) NOTE3: the --disable-libstdcxx-pch should be irrelevant NOTE4: There might _still_ be places in the Ada build where "gnatmake" is used literally - instead of GNATMAKE_FOR_ so it is very important to make sure that the NOTE2 is observed. 6. make -jN .. 7. $ ./gcc/xgcc --version xgcc (GCC) 15.0.0 20240721 (experimental) [master revision r15-2183-g58b78cf068b3] (Sunday AM trunk) Works For Me as I have repeatedly said - you need to examine carefully what you are doing differently - if there's a real bug I'd like to fix it - but I cannot see one at present. 11.5 might be a good one to build since that also gives you a D compiler to bootstrap D on gcc-12+ I just built the darwin branch released over the weekend... configure: /src-local/gcc-git-11/configure --prefix=/opt/iains/x86_64-apple-darwin20/gcc-11-5-darwin --build=x86_64-apple-darwin20 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk --disable-libstdcxx-pch --enable-languages=all CC=x86_64-apple-darwin19-gcc CXX=x86_64-apple-darwin19-g++ $ ./gcc/xgcc --version xgcc (GCC) 11.5.0
[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981 --- Comment #5 from Iain Sandoe --- (In reply to Arsen Arsenović from comment #4) > the latter seems OK to me - mind proposing a patch? I am planning on doing some rework on the ramp code-gen in the (very) near future - so can pick this up on the way (unless Patrick has already done it ... )
[Bug c++/110872] coroutine postcondition is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872 --- Comment #2 from Iain Sandoe --- fixed on trunk, not sure if we need to back port, leaving open for now.
[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871 --- Comment #2 from Iain Sandoe --- fixed on trunk, not sure if we need to back port, leaving open for now.
[Bug c++/115434] Post contracts are ignored on functions with no return statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434 --- Comment #3 from Iain Sandoe --- fixed on trunk, not sure if we need to back port - but leaving open for now.
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #2 from Iain Sandoe --- (In reply to Iain Sandoe from comment #1) > NOTE: my compiler builds and tests do not include any macports or homebrew > components. The only additional content in my PATH is 1) texinfo-6.7 2) > dejagnu and the bootstrap GCC installation (obv. needed for Ada). FAOD: my dejagnu install is self-contained (it includes tcl+expect)... however it seems extremely unlikely that this is in any way related to a build issue.
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #1 from Iain Sandoe --- The problem with fixing this is that I cannot reproduce it; we are still trying to determine if there's some dependency on environment - or maybe something bizarre like the installed version of some utility like gawk etc. I can bootstrap and test all languages including Ada (on x86_64 darwin) using GCC-7.5, 10.5 and 11.4 - results on testresults@ (I've just done r15-2183-g58b78cf068b3 on x86_64-darwin21 under rosetta2 and on x86_64 darwin 23, 21 and 19 native). NOTE: my compiler builds and tests do not include any macports or homebrew components. The only additional content in my PATH is 1) texinfo-6.7 2) dejagnu and the bootstrap GCC installation (obv. needed for Ada). I would really like to resolve this before we issue 14.2-darwin (it's likely too late to fix anything on the release branch).
[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from Iain Sandoe --- but 10.x is closed so we're done on open branches.
[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-07-15 Status|UNCONFIRMED |NEW --- Comment #12 from Iain Sandoe --- (In reply to Michal Jankovič from comment #11) > (In reply to Iain Sandoe from comment #10) > > actually I thought I explained the issue in email to Michal - that we need > > to make some changes for correctness to these mechanisms and therefore that > > we should defer the optimisation until those are done. > > Ok, I must have missed that or misremembered; NP - and it's been unfortunate that it's taken some time to get some support to revisit GCC coroutines. > I remember you recommending I > get some real-world stats on the memory savings to help make this higher > priority, but I couldn't find the time. Yeah I still think we need to do this - my plan was to try and instrument and then see how it applies to folly's test cases; the general issue being that compiler testcases and some of the smaller coroutines libraries would likely not really show as much advantage since they do not have particularly complex scoping or large frames.
[Bug c++/105989] Coroutine frame space for temporaries in a co_await expression is not reused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #10 from Iain Sandoe --- actually I thought I explained the issue in email to Michal - that we need to make some changes for correctness to these mechanisms and therefore that we should defer the optimisation until those are done. I have Michal's patch in my local queue and we now have some funding to take things forward. This optimisation is 100% on the TODO.
[Bug target/115880] [14 regression] GCC 14+ fails to parse CoreFoundation header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-07-11 Ever confirmed|0 |1 --- Comment #2 from Iain Sandoe --- I have posted patches (which need an update [on my shorter TODO] that implement the availability attribute). That makes a fix unnecessary - I would much rather pursue the implementation of the attribute than keep on applying band-aid fixincludes - the latter have been causing us some difficulties where SDKs change even within one OS rev. The availability patches are on my darwin branches, along with patches to remove the existing fixincludes which break on some SDK versions. So I agree that this bug is real - but I do not agree that the right resolution is more fixincludes.
[Bug c++/114663] Several contracts test cases fail with -fsanitize=undefined -fsanitize-trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed|2024-04-09 00:00:00 |2024-07-08 --- Comment #2 from Iain Sandoe --- So I'd like to capture the options here (bearing in mind that the contracts implementation here is not going to be standardised). We're now clear, thanks to Nina's investigation that what's implemented follows the normative text (although perhaps not the intention). 1. The issue is that, in the tests in the contracts suite, if we want to test more than one contract in a single test case we have to compile with -fcontract-continuation-mode=on. However, the first contract assert that fails actually invokes UB. 2. It "all happens to work" for default compile options because our default lowering for __builtin_unreachable() is "nothing". This means that the failing asserts fall-through and therefore reach the next check. 3. Any different strategy (e.g. ubsan or replacing the lowering of __builtin_unreachable (e.g. => trap)) causes this to fail. So our options are; 1. Consider that the test cases are bad, and replace them with tests that have only one [failing] contract per test. 2. Decide that the normative text did not follow the intentions as stated in the discussion paragraph and fix the code to elide the runtime part. 3. Do nothing because we do not know what the eventual shape of the contracts will be and we want to be sure to notice that axioms need some work. While (2) is a nicer engineering solution - it seems that (3) is the right choice for now. So we leave the bug open - and any target effected by it would need to add an xfail (likewise for anyone testing with ubsan).
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #37 from Iain Sandoe --- fixed on open branches
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-06-29 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #7 from Iain Sandoe --- (In reply to Iain Sandoe from comment #6) > Looking at a current discussion of > https://cplusplus.github.io/CWG/issues/2563.html > > it seems that there is agreement that the returned type from > get_return_object() does not need to match the coroutine (ramp) return type > - so long at that latter type has a CTOR that accepts the > get_return_object() type. Am I mistaken in thinking that void is a valid > example of this? More discussion at WG21 - with the result that we do not intend to be able handle a void get_return_object() - only ones that can be converted to the return type. So I'll look into revising the ramp to remove the extra code that allows it.
[Bug c++/95517] [coroutines] suggested warning when co_return and return_void() are missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95517 Iain Sandoe changed: What|Removed |Added Resolution|--- |WONTFIX Status|ASSIGNED|RESOLVED --- Comment #8 from Iain Sandoe --- I think the compiler is doing what the standard mandates; the idea of allowing both return cases to be in the promise could be re-presented to WG21 - but not before C++26, at this stage. So I think to close this now.
[Bug c++/104051] [coroutines] ICE: tree check: expected target_expr, have call_expr in coro_diagnose_throwing_final_aw_expr, at cp/coroutines.cc:880 since r11-7528-g9ee91079fd5879cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104051 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Sandoe --- fixed on open branches
[Bug c++/101765] ICE when using a VLA inside of a coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Iain Sandoe --- fixed on open branches
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 101765, which changed state. Bug 101765 Summary: ICE when using a VLA inside of a coroutine https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/100772] Templated coroutine new function's arguments have incorrect value categories/overload selection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100772 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Iain Sandoe --- fixed on open branches
[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99710 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Iain Sandoe --- fixed on open branches
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #30 from Iain Sandoe --- blocks have support from 10.6 [Apple gcc-4.2] (although there is/was 'after market' support for 10.5). you should be able to find plenty of examples in the Apple Developer doc. This is now becoming more of an issue (e.g. for sanitiser support) there are some APIs that no longer have a non-Blocks version. As with all $hobby things, it takes time ;)
[Bug c++/102454] coroutines: ICE in gimplify_var_or_parm_decl, at gimplify.c:2958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102454 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Iain Sandoe --- fixed on open branches
[Bug c++/110872] coroutine postcondition is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||4848.html Last reconfirmed||2024-06-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org CC||iains at gcc dot gnu.org
[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-06-23 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||4848.html CC||iains at gcc dot gnu.org
[Bug c++/115434] Post contracts are ignored on functions with no return statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||4848.html Status|UNCONFIRMED |NEW Last reconfirmed||2024-06-23 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
[Bug debug/108917] ICE when specifying optimization level and debuging for C++ contracts code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108917 --- Comment #4 from Iain Sandoe --- I think the problem here is related to the setting of DECL_ABSTRACT_ORIGIN on the contract checking functions. " DECL_ABSTRACT_ORIGIN, if non-NULL, points to the original (abstract) ..._DECL node of which this decl is an (inlined or template expanded) instance. " but that is not what these synthesised functions are; rather they are entirely new functions that implement a series of tests and possibly diagnostic output. In fact, they don't necessarily even have the same signature as the original. They certainly do not have the same block layout as the original. It's not clear that we need these functions to be identified as the same function as the original (if that is really a requirement - e.g. to make the function name the same in these helpers - then we could do a similar process to the one used for coroutine helpers).
[Bug c++/115434] Post contracts are ignored on functions with no return statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434 --- Comment #1 from Iain Sandoe --- note that the example uses the new syntax, but the issue applies equally to the attribute syntax in trunk.
[Bug c++/115434] New: Post contracts are ignored on functions with no return statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434
Bug ID: 115434
Summary: Post contracts are ignored on functions with no return
statement.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
This applies to void functions and coroutines (which usually have a return
object but do not have a return statement).
e.g:
void foo (const int b) pre ( b == 9 ) // contract checked
{}
int main()
{
foo(3);
}
void foo (const int b) post ( b == 9 ) // contract not checked
{}
int main()
{
foo(3);
}
int foo (const int b) post ( b == 9 ) // contract checked
{
return 1;
}
int main()
{
foo(3);
}
==
I was expecting the original function body to be wrapped in a try/finally block
with the post function as the cleanup. Same back to 13.3 so it does not appear
to be a regression.
[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305 --- Comment #8 from Iain Sandoe --- (In reply to Eric Botcazou from comment #7) > They might come from https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r15-615 > and, in particular, the change made to libgnarl/s-osinte__darwin.ads, in > which case the way out would be to duplicate libgnat/s-oslock__posix.ads > into libgnat/s-oslock__darwin.ads, add back the sig field and remove the > alignment clause there, and then do the substitution on line 2749 of > Makefile.rtl. thanks for the pointer - if I have a chance, will take a look over the weekend.
[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305 --- Comment #6 from Iain Sandoe --- a quick look at current results for other platform versions suggests that: * x86_64-darwin10 [64b runtimes, but 32b kernel] is also affected but * from darwin11+ [64 kernel] the main fail is FAIL: cxa4001 which is a known issue. my darwin10 box is v. slow (and I lost a bunch of runs on Weds from a power outage) but will post the 889 results for Darwin10 when it's done.
[Bug ada/115292] [15 Regression] i686-darwin17 bootstrap fails for Ada (between r15-856 and r15-889)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115292 Iain Sandoe changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Iain Sandoe --- (In reply to Eric Botcazou from comment #1) > Can you post the list of ACATS regressions on the 32-bit host? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305
[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305 --- Comment #4 from Iain Sandoe --- Created attachment 58322 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58322&action=edit between 856 and 889 likewise.
[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305 --- Comment #3 from Iain Sandoe --- Created attachment 58321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58321&action=edit between 792 and 856 likewise
[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305 --- Comment #2 from Iain Sandoe --- Created attachment 58320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58320&action=edit between 644 and 792
[Bug ada/115305] [15 Regression] many (162) acats regressions on i686-darwin9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305 --- Comment #1 from Iain Sandoe --- Created attachment 58319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58319&action=edit between 386 and 644 the results have been somewhat turbulent - so posting the ranges I have in case it helps
[Bug ada/115305] New: [15 Regression] many (162) acats regressions on i686-darwin9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305 Bug ID: 115305 Summary: [15 Regression] many (162) acats regressions on i686-darwin9. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 58318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58318&action=edit totals between r15-386-889 firstly, this is not a high priority target (even for me) - but I guess these regressions do indicate some underlying omission or similar. up to r15-386 darwin has clean acats results (both 32b and 64b hosts). Unfortunately between r15-386 and 644 there was a bootstrap break for Ada on i686-darwin, so the revision history is fragmented I will attach diffs for the revision ranges I have; listing 162 fails here can be done - but not sure it would be helpful. Where we are testing an unpatched trunk/branch we are now pushing the results to GCC's bunsen project: https://builder.sourceware.org/testruns/?commitishes=&has_expfile_glob=&has_trsfile_glob=&has_keyvalue_k=testrun.git_describe&has_keyvalue_op=glob&has_keyvalue_v=iains%2F*&has_keyvalue2_k=omnitest.results&has_keyvalue2_op=glob&has_keyvalue2_v=*&order_by=testrun.authored.time&order=desc&limit=1000&offset=0&offset=0 the tag is : iains ///- so you can also poke at the detailed logs there if it's helpful. === There are regressions also on other earlier platform versions; I will also try to identify them.
[Bug ada/115292] New: [15 Regression] i686-darwin17 bootstrap fails for Ada (between r15-856 and r15-889)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115292 Bug ID: 115292 Summary: [15 Regression] i686-darwin17 bootstrap fails for Ada (between r15-856 and r15-889) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- Host: i686-darwin17 Target: i686-darwin17 Build: i686-darwin17 The fail occurs in stage #3 building libs. What is special about this configuration is that we are building i686-darwin17 on an x86_64-darwin17 box (I would expect this to be analogous to building i686-linux on a x86_64-linux box which has the 32b runtimes installed (but I did not try to relicate this there). So far this is the only version of Darwin (which supports this mode) on which I've tried this (it is a perfectly valid configuration and is expected to work). On a 32b host, the same revision (r15-889) built OK although there are massive [10s] (unanalysed) Acats regressions on earlier Darwin platforms (so I think things have become a bit unstable recently). Unfortunately, I don't have time to analyze further right now - but this at least brackets the change to a smallish commit range. === Depending on the jN we get different sources failing: +===GNAT BUG DETECTED==+ | 15.0.0 20240529 (experimental) [master revision r15-889-g241a6cc88d86] (i686-apple-darwin17) | | Assert_Failure sem_ch12.adb:17782| | Error detected at a-string.ads:27:66 | | Compiling g-socpol.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ The assert is in "function Save_And_Reset" if Indexed_Assoc.Act_Id'Valid then Result_Pair.Actual_Id := Indexed_Assoc.Act_Id; else pragma Assert (Index = Result'Last); Result_Pair.Actual_Id := Empty; end if;
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 --- Comment #17 from Iain Sandoe --- however, the opover.o mismatch is a symptom - rather than the cause. If all the objects for the D FE are built by D, then that would tend to point to miscompilation of something in common code (that is built with C++ and therefore can be affected by O3).
