[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=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=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=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=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=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=_expfile_glob=_trsfile_glob=_keyvalue_k=testrun.git_describe_keyvalue_op=glob_keyvalue_v=iains%2F*_keyvalue2_k=omnitest.results_keyvalue2_op=glob_keyvalue2_v=*_by=testrun.authored.time=desc=1000=0=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).
[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 #14 from Iain Sandoe --- (In reply to Richard Biener from comment #13) > (In reply to Iain Sandoe from comment #9) > > (In reply to Richard Biener from comment #8) > > > I've pushed a fix for PR115137, it's likely this fixes also this bug. > Note stage1 and stage2 are not expected to compare equal - it's stage2 and > stage3 objects that are compared. Right, for the runtime objects they are built with the stage2 and stage3 compilers, but for the language objects (like the one we see here), those are built with the stage1 and stage2 compilers. I did check manually that the stage3 compiler does do the same as the stage2 (and that -fdebug-compare does not fail(. >> I don't expect the machine to make any difference - and I saw that this was >> also reported by at least one person for Linux too (although bootstrapping >> with O3, I think). >I think that was an ICE with prange. Hmm, I thougt I saw toon report the same file with a -O3 bootstrap on Linux: make[3]: Leaving directory '/home/toon/scratch/bld2850364' Comparing stages 2 and 3 Bootstrap comparison failure! gcc/d/opover.o differs make[2]: *** [Makefile:37306: compare] Error 1
[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 #9 from Iain Sandoe --- (In reply to Richard Biener from comment #8) > I've pushed a fix for PR115137, it's likely this fixes also this bug. unfortunately, not; at least, on my fastest x86 machine (AVX512) - the fail is the same (different CSWTCH.xxx numbers between the stage1 compiler and the stage2 - the numbers are unchanged with the r15-753 [.154 and .155 respectively]). I don't expect the machine to make any difference - and I saw that this was also reported by at least one person for Linux too (although bootstrapping with O3, I think).
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 --- Comment #7 from Iain Sandoe --- I have not tested on solaris - hopefully that is OK too. However, I will comment that it maybe built but there are cats regressions (1) on x86_64, (2) on i686-darwin17 (many) on i686-darwin9. No idea what caused those at the moment - and my hardware is very tied up with the releases.
[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 #7 from Iain Sandoe --- additional notes: 1. jamming -std=c++11 into stage2 and 3 cxxflags did not make any difference (I was wondering if some c++17 copy elision thing might have changed the number of temporaries). 2. still there at r15-644 (no surprise) 3. building the object using the stage3 compiler gives the same result as the stage2 one. 4. building the object with the stage3 compiler and -fcompare-debug succeeds. 5. (although it's still out of tree) my aarch64-darwin branch, rebased onto r15-644 also fails in the same way. (not that any of these observations gets us any closer .. )
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 --- Comment #5 from Iain Sandoe --- as of r15-644, Ada bootstrap succeeded on i686-darwin9 and 17. I do not known whether that means the issue is actually fixed by recent Ada commits, or that it's now just become latent.
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 Iain Sandoe changed: What|Removed |Added Target|x86_64-darwin |x86_64-darwin, x86_64-linux --- Comment #6 from Iain Sandoe --- (In reply to Andreas Schwab from comment #5) > Dup of PR115137? honestly, I don't know, perhaps but it's not obvious. However, I think that the debug-compare is a red herring (clearly there's some difference in codegen). note: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/815459.html which seems to indicate that this does fire on x86_64 linux too - with the right bootstrap conditions.
[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 #4 from Iain Sandoe --- so I am comparing the output of compiling gcc/d/dmd/opover.d with the stage1 and stage2 compilers. Using -fdump-tree-all. the .005t.original outputs are the same the .006t.gimple outputs already have differences in the numbering of some vars. the first dump file that mentions CSWTCH.15x is .032t.einline (which mentions a reference to the object). AFAICT the symbol CSWTCH.15x has the same value at all times; so it appears to have been created with a different id. I can upload the gimple if it's useful. ( one further experiment - and then I need to punt on this until there's some more focussed way to debug it - I am wondering if the issue has anything to do with the default c++ std being different for stage 1 and 2+ ) - to test this theory, will jam -std=c++11 into BOOT_CFLAGS.
[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 #3 from Iain Sandoe --- (In reply to rguent...@suse.de from comment #2) > > Am 17.05.2024 um 16:20 schrieb iains at gcc dot gnu.org > > : > > > > where the stage1 compiler (and x86_64 Linux) produces _CSWTCH.154 > > > > At present, still trying to figure out how to debug this further .. it's D > > so > > no preprocessed output - I guess will have to try tree dumps. > > Did the followup fix maybe resolve this? unfortunately, not - the same behaviour is seen at r15-633 (so will have to see what can be done to debug).
[Bug tree-optimization/115138] [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |15.0 Version|14.0|15.0 Last reconfirmed||2024-05-17 --- Comment #1 from Iain Sandoe --- seen on several OS versions.
[Bug tree-optimization/115138] New: [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115138 Bug ID: 115138 Summary: [15 Regression] Bootstrap compare-debug fail after r15-580-gf3e5f4c58591f5 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: x86_64-darwin The compare fail is a symbol name mismatch (AFAICT) the code is otherwise identical. a single fail fails gcc/d/opover.o There's: .const _CSWTCH.155: .byte 38 .byte 37 .byte 40 .byte 39 where the stage1 compiler (and x86_64 Linux) produces _CSWTCH.154 At present, still trying to figure out how to debug this further .. it's D so no preprocessed output - I guess will have to try tree dumps.
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 Iain Sandoe changed: What|Removed |Added Build|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||i686-darwin Host|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||i686-darwin Target|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||i686-darwin --- Comment #4 from Iain Sandoe --- likewise, x86_64 seems unaffected on the same OS versions (even on the same h/w).
[Bug ada/115106] [15 regression] SEGV in sem_elab.internal_representation.nts_map.mutate_and_rehash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115106 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- *** Bug 115113 has been marked as a duplicate of this bug. ***
[Bug ada/115113] [15 Regression] Ada bootstrap fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115113 Iain Sandoe changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- Rainer's bisect was quicker than mine! *** This bug has been marked as a duplicate of bug 115106 ***
[Bug ada/115113] New: [15 Regression] Ada bootstrap fails for i686-darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115113 Bug ID: 115113 Summary: [15 Regression] Ada bootstrap fails for i686-darwin. 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: --- Target: i686-darwin between - r15-386 and r15-516 not analysed any further yet - but x86_64 bootstrap on the same OS rev appears unaffected. several instances of memory constraint errors.. At the moment, it's the stage#2 gnat1 that's failing - so no debug info... one example: /scratch/10-13-his/gcc-master-i686/./prev-gcc/gnat1 -I - -I . -I ada/generated -I ada -I /src-local/gcc-master/gcc/ada -I ada/libgnat -I /src-local/gcc-master/gcc/ada/libgnat -I ada/gcc-interface -I /src-local/gcc-master/gcc/ada/gcc-interface -quiet -nostdinc -O2 -Wextra -Wall -dumpdir ada/ -dumpbase exp_attr.adb -dumpbase-ext .adb -gnatwa -fchecking=1 -g -fchecking=1 -gnatpg -gnata -fPIC -mmacosx-version-min=10.13.0 -mtune=core2 -fPIC -feliminate-unused-debug-symbols -gnatO ada/exp_attr.o /src-local/gcc-master/gcc/ada/exp_attr.adb -o /Volumes/ramdisk/cceVdIos.s * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: 0x003d8c6b gnat1`sem_elab__internal_representation__nts_map__mutate_and_rehashXb + 235 gnat1`sem_elab__internal_representation__nts_map__mutate_and_rehashXb: -> 0x3d8c6b <+235>: movl %ecx, 0x8(%eax) 0x3d8c6e <+238>: movq %xmm0, 0x8(%ecx) 0x3d8c73 <+243>: movl 0xc(%esi), %ecx 0x3d8c76 <+246>: testl %ecx, %ecx Target 0: (gnat1) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) * frame #0: 0x003d8c6b gnat1`sem_elab__internal_representation__nts_map__mutate_and_rehashXb + 235 frame #1: 0x003e1d72 gnat1`sem_elab__internal_representation__scenario_representation_ofX + 306 frame #2: 0x003ebc3d gnat1`sem_elab__guaranteed_abe_processor__process_guaranteed_abeX + 253 frame #3: 0x003ebf76 gnat1`sem_elab__record_elaboration_scenario + 582 frame #4: 0x0044c041 gnat1`sem_res__resolve_call + 2609 frame #5: 0x0043b076 gnat1`sem_res__resolve + 6758 frame #6: 0x0043f8a0 gnat1`sem_res__resolve_equality_op + 400 frame #7: 0x0043b0be gnat1`sem_res__resolve + 6830 frame #8: 0x0043a270 gnat1`sem_res__resolve + 3168 frame #9: 0x0043eb21 gnat1`sem_res__resolve_short_circuit + 81 frame #10: 0x0043b08e gnat1`sem_res__resolve + 6782 frame #11: 0x0037d47a gnat1`sem_ch5__analyze_exit_statement + 346 frame #12: 0x002b566f gnat1`sem__analyze + 4143 frame #13: 0x00380369 gnat1`sem_ch5__analyze_statements + 249 frame #14: 0x00381f35 gnat1`sem_ch5__analyze_loop_statement + 181 frame #15: 0x002b5719 gnat1`sem__analyze + 4313 frame #16: 0x00380369 gnat1`sem_ch5__analyze_statements + 249 frame #17: 0x00380540 gnat1`sem_ch5__analyze_if_statement__analyze_cond_then.92 + 112 frame #18: 0x00381b10 gnat1`sem_ch5__analyze_if_statement + 80 frame #19: 0x002b565e gnat1`sem__analyze + 4126 frame #20: 0x00380369 gnat1`sem_ch5__analyze_statements + 249 frame #21: 0x002ebf25 gnat1`sem_ch11__analyze_handled_statements + 181 frame #22: 0x002b52e3 gnat1`sem__analyze + 3235 frame #23: 0x0037cf84 gnat1`sem_ch5__analyze_block_statement + 276 frame #24: 0x002b5129 gnat1`sem__analyze + 2793 frame #25: 0x00380369 gnat1`sem_ch5__analyze_statements + 249 frame #26: 0x00380f2b gnat1`sem_ch5__analyze_case_statement + 2315 frame #27: 0x002b5118 gnat1`sem__analyze + 2776 frame #28: 0x00380369 gnat1`sem_ch5__analyze_statements + 249 frame #29: 0x002ebf25 gnat1`sem_ch11__analyze_handled_statements + 181 frame #30: 0x002b52e3 gnat1`sem__analyze + 3235 frame #31: 0x00396488 gnat1`sem_ch6__analyze_subprogram_body + 2008 frame #32: 0x002b4f5c gnat1`sem__analyze + 2332 frame #33: 0x0033d12b gnat1`sem_ch3__analyze_declarations + 75 frame #34: 0x0039fabd gnat1`sem_ch7__analyze_package_body + 3165 frame #35: 0x002b4f6d gnat1`sem__analyze + 2349 frame #36: 0x002e83a5 gnat1`sem_ch10__analyze_compilation_unit + 501 frame #37: 0x002b50c3 gnat1`sem__analyze + 2691 frame #38: 0x002b6945 gnat1`sem__semantics + 1381 frame #39: 0x0021fe68 gnat1`_ada_frontend + 1752 frame #40: 0x00507b3c gnat1`_ada_gnat1drv + 3004 frame #41: 0x000279af gnat1`gnat_parse_file() + 31 frame #42: 0x01a591fa gnat1`compile_file() + 42 frame #43: 0x0237cea6 gnat1`toplev::main(int, char**) + 5478 frame #44: 0x0237d6aa gnat1`main + 42 frame #45: 0xa7273611 libdyld.dylib`start + 1
[Bug bootstrap/115077] New: bootstrap fails with in-tree isl-0.25/6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115077 Bug ID: 115077 Summary: bootstrap fails with in-tree isl-0.25/6 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- see also this thread: https://gcc.gnu.org/pipermail/gcc/2024-May/243949.htm version 0.25 and 0.26 have test cases that require c++17 support. Essentially we have a stage1 bootstrap fail with errors of the form " /src-local/gcc-master/isl/isl_test_cpp17-generic.cc: In function ‘isl::id construct_id(isl::ctx, bool*)’: /src-local/gcc-master/isl/isl_test_cpp17-generic.cc:25:24: error: no matching function for call to ‘isl::id::id(isl::ctx&, const char [2], std::shared_ptr&)’ 25 | isl::id id(ctx, "S", s); " because we are somehow mismatching the build flags and the configure ones. = The isl configure checks for this support using AX_CXX_COMPILE_STDCXX_17 which updates CXX to include the addition of -std=c++17, if that is required to enable it. The test cases are then added on HAVE_CXX17 The isl (stage1) Makefile contains (for an example on Darwin) CXX = x86_64-apple-darwin21-g++ -std=c++11 -std=gnu++17 CXXCPP = x86_64-apple-darwin21-g++ -std=c++11 -std=gnu++17 -E Which is correct. However somehow we are overriding this in the actual build: x86_64-apple-darwin21-g++ -std=c++11 -DHAVE_CONFIG_H -I. -I/src-local/gcc-master/isl -I/src-local/gcc-master/isl/include -Iinclude/ -I/src-local/gcc-master/gmp -I/scratch/12-mon-rosetta/gcc-master/./gmp -O -pipe -MT isl_test_cpp17.o -MD -MP -MF $depbase.Tpo -c -o isl_test_cpp17.o /src-local/gcc-master/isl/isl_test_cpp17.cc &&\ mv -f $depbase.Tpo $depbase.Po
[Bug libstdc++/66146] call_once not C++11-compliant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #58 from Iain Sandoe --- As far as I can tell, (at least on targets with TLS support) since the variables __once_callable and __once_call have a single instance per thread, the current implementation does not support nested once_call()s in the same thread either.
[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728 --- Comment #8 from Iain Sandoe --- (In reply to Iain Sandoe from comment #7) > I happened to do an AIX build on cfarm119 - and looking at this, not sure > why AIX is failing; although the LTO is handled in a different way in AIX, > there are actually no instances of "ascii" in the assembler output - so I'd > have expected it to pass "by accident". and, indeed, testing on r15-384 on powerpc-ibm-aix7.3.1.0 the test passes.
[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728 --- Comment #7 from Iain Sandoe --- I happened to do an AIX build on cfarm119 - and looking at this, not sure why AIX is failing; although the LTO is handled in a different way in AIX, there are actually no instances of "ascii" in the assembler output - so I'd have expected it to pass "by accident".
[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-05-11 CC||iains at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #6 from Iain Sandoe --- it also fails on Darwin because the LTO section names are different (and therefore are not being excluded) -- I have patches to fix the two issues mentioned for Darwin, For the EH case, we can imply omit the EH frames from the test. For the other case, I'll fix up the scanasm code to allow the correct LTO section name introducer on Darwin - that seems a better solution than doing a dance with counting the number of .ascii every time. No idea if either of those issues is relevant to the remaining affected platforms.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #31 from Iain Sandoe --- (In reply to Liviu Ionescu from comment #30) > (In reply to Dimitry Andric from comment #29) > > ... fixes system.h which is also included by gcov.cc > > ok, great. > > > Which version of gcc were you building? > > in the reported bug I was building 13.2. > > was the fix backported to older versions? so far, the fix has baeen back ported for 13.3 .. it is on the list to be back ported for 12.4 and 11.5,
[Bug c++/114982] New: [15 Regression] New test g++.dg/tree-ssa/cxa_atexit-6.C fails on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114982 Bug ID: 114982 Summary: [15 Regression] New test g++.dg/tree-ssa/cxa_atexit-6.C fails on Darwin. Product: gcc Version: 14.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: --- The call to __cxa_atexit is elided on Darwin. The rules for what binds locally on Mach-O might be in error (but I think that they are subtly different from ELF).
[Bug testsuite/114034] Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Iain Sandoe --- fixed on open branches
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Iain Sandoe --- fixed on open branches
[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Iain Sandoe --- fixed on open branches.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Iain Sandoe --- fixed on open branches
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Iain Sandoe --- fixed on open branches (needed on earlier if maintained).
[Bug objc/101666] Objective-C frontend crashes with `-fobjc-nilcheck`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101666 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #10 from Iain Sandoe --- now fixed on open branches (still needed on earlier 'vendor' branches)
[Bug c++/114663] New: Several contracts test cases fail with -fsanitize=undefined -fsanitize-trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663
Bug ID: 114663
Summary: Several contracts test cases fail with
-fsanitize=undefined -fsanitize-trap
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: testsuite-fail, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
I found this while working on -funreachable-traps (but the failure equally
occurs with -fsanitize=undefined -fsanitize-trap)
FAIL: g++.dg/contracts/contracts10.C execution test
FAIL: g++.dg/contracts/contracts18.C execution test
FAIL: g++.dg/contracts/contracts19.C execution test
FAIL: g++.dg/contracts/contracts2.C execution test
Initial analysis is that somehow the lowering of the contracts code is
exploiting UB [which has a large measure of irony if true] to make these cases
pass, for example contracts2.C optimised tree dump contains:
;; Function main (main, funcdef_no=0, decl_uid=2531, cgraph_uid=1,
symbol_order=0)
int main ()
{
int x;
int D.2551;
const struct D.2542;
int _2;
:
x_1 = 1;
if (x_1 < 0)
goto ; [INV]
else
goto ; [INV]
:
__builtin_unreachable ();
:
if (x_1 <= 0)
goto ; [INV]
else
goto ; [INV]
:
=
When (default) the __builtin_unreachable () is replaced with nothing (i.e. it
falls though) the test case passes.
When we replace the __builtin_unreachable () with a trap (either using the
ubsan or -funreachable-traps style) the test case fails with the trap.
This seems to be unlikely to be what was intended (or if it was intended it's
terribly fragile); I'm labelling it wrong code for now.
Similar code patterns exist in the other cases mentioned.
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 --- Comment #8 from Iain Sandoe --- (In reply to Andrew Pinski from comment #5) > (In reply to Pierre-Emmanuel Patry from comment #2) > While you are at it, it would be useful to add a link to the rust langauge > specification (like there is for almost all other languages [I see > objective-C is not listed]) to https://gcc.gnu.org/readings.html . This is getting a bit off-topic for the current PR - but, for the record, I am not aware of any formal spec for Objective-C/C++ - the API is described in Apple's developer documentation and compliance is assessed (at least by me) in terms of "do we implement the things that we claim, in the same way as the system compiler"? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 --- Comment #8 from Iain Sandoe --- (In reply to Andrew Pinski from comment #5) > (In reply to Pierre-Emmanuel Patry from comment #2) > While you are at it, it would be useful to add a link to the rust langauge > specification (like there is for almost all other languages [I see > objective-C is not listed]) to https://gcc.gnu.org/readings.html . This is getting a bit off-topic for the current PR - but, for the record, I am not aware of any formal spec for Objective-C/C++ - the API is described in Apple's developer documentation and compliance is assessed (at least by me) in terms of "do we implement the things that we claim, in the same way as the system compiler"?
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe --- since humour does not always translate - even between en_GB and en_US in some cases... I wonder if the better solution in the case of something that is clearly intended to be humour (which is subjective as per the comments here) is to leave the text in the original language (perhaps with surrounding quotation marks correct for the target language). That way if the (end user) reading the diagnostic can understand the original language the joke should stand. It seems a bit unreasonable to expect translators to find an equivalent joke in the target language (transliteration is not likely to work in most cases). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe --- since humour does not always translate - even between en_GB and en_US in some cases... I wonder if the better solution in the case of something that is clearly intended to be humour (which is subjective as per the comments here) is to leave the text in the original language (perhaps with surrounding quotation marks correct for the target language). That way if the (end user) reading the diagnostic can understand the original language the joke should stand. It seems a bit unreasonable to expect translators to find an equivalent joke in the target language (transliteration is not likely to work in most cases).
[Bug middle-end/29231] need a way to produce trampolines not on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231 --- Comment #8 from Iain Sandoe --- A secondary comment - the wiring up of the built-ins that allocate/deallocate trampoline entries makes the underlying mechanism opaque to the middle end consumer. So, although the current example implementations use mmap / heap, I do not believe that there is anything preventing an implementation from choosing some alternate scheme for allocation of tables (e.g. a non-hosted impl could use a fixed allocation - presumably with a hard fail if that allocation is exceeded.)
[Bug middle-end/29231] need a way to produce trampolines not on the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231 Iain Sandoe changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113401 --- Comment #7 from Iain Sandoe --- Current status. We have implemented (currently for hosted x86 and aarch64) a heap-based trampoline approach. for efficiency heap trampolines are allocated in tables of one page in size (no pages are allocated until the first trampoline requires one). Pages are added and subtracted as the number of trampoline tables increases/decreases. One proviso - the first allocated page is sticky (this avoids mmap/etc. churn if there are a lot of single trampolines required). Trampoline pages are per thread. The mechanism works with platforms that will not allow heap pages to be both writable and executable at the same time (the page is made temporarily r+w to make changes and then r+x for operation). For Darwin, there's a permission mode "jit" that does something similar. A new platform needs to supply the libgcc support for example : libgcc/config/aarch64/heap-trampoline.c libgcc/config/aarch64/t-heap-trampoline + a reference to this in libgcc/config.host A new platform can elect to default to heap trampolines by adding HEAP_TRAMPOLINES_INIT=1 to tm_defines in the relevant target section in gcc/config.gcc There is currently (pre gcc-14 branch) one unhandled issue which is reallocation of the last "sticky" trampoline page when a thread exits. I would say, that (within realistic implementation constraints) we could count this as fixed.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #26 from Iain Sandoe --- NOTE: I adjusted the PR lines in the commit header so that the commits get reflected on the PR.
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #11 from Iain Sandoe --- (In reply to Jason Merrill from comment #10) > (In reply to Jonathan Wakely from comment #8) > > (In reply to Iain Sandoe from comment #7) > > > So I am actually asking if the extension actually has any useful meaning? > > > > For non-darwin, yes, it requests the storage of two initializer lists to be > > merged (see the commit msg for r14-1500-g4d935f52b0d5c0). > > Though that doesn't involve the attribute, and promoting init-lists to > static should work fine on darwin. I think that is working we end up with two constant text arrays (no copy via automatic storage as mentioned in the paper) > (In reply to Jonathan Wakely from comment #6) > > The question then is whether the attribute is supposed to be a non-binding > > request or not. > > > > If it's a non-binding request then the test should be adjusted/unsupported > > for this target. > > It is a non-binding request. And yes, if this optimization is problematic on > darwin, we should adjust the test. Actually, the optimisation is failing on Darwin - we produce two distinct arrays. (although, if it succeeds then technically that's breaking the ABI since we then have two external symbols with the same addresss). SO I suppose the question is do we want to figure out why the opt is failing (knowing that if it succeeds that is a secondary issue) - or just dg-xfail-run-if for Darwin? This is what we generate now: .const .align 3 _i: .long 1 .long 2 .long 3 .globl _j .align 3 _j: .long 1 .long 2 .long 3 and we do access i and j directly (i.e. not via the GOT).
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 --- Comment #7 from Iain Sandoe --- however: 1) it is not in the gnu:: namespace the tests just have it as [[ ]]. 2) I do not think that the standard has anything to say about how entities at file scope are ordered in memory (many/most impls. probably use the same order as the file - but I do not think they are obliged to). 3) it is an ABI break for Darwin (where two global entities are not allowed to have the same address - although it _is_ possible to tell the linker that one is an alias for another - that support is not (yet) available in the FE). So I am actually asking - if the extension actually has any useful meaning? - if it is an extension it probably should be only available in gnu:: ?
[Bug testsuite/114034] Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 --- Comment #4 from Iain Sandoe --- fixed on trunk, needed on open branches.
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #5 from Iain Sandoe --- fixed on trunk, needed on open branches.
[Bug objc/101718] Objective-C frontend emits wrong code to call methods returning scalar types returned in memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101718 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Iain Sandoe --- fixed on open branches (and gcc-10)
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #23 from Iain Sandoe --- (In reply to Gerald Pfeifer from comment #22) > (In reply to Dimitry Andric from comment #21) > > Indeed, please merge both commits: > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > > h=9970b576b7e4ae337af1268395ff221348c4b34a > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > > h=5213047b1d50af63dfabb5e5649821a6cb157e33 > > Jakub, Ian, if you approve I volunteer to gradually push this to > open release branches. Geral, thanks for the offer: I have locally back ported and tested for GCC-13, so (assuming that this is approved) please start with gcc-12.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #20 from Iain Sandoe --- This is fixed on trunk, but is needed on open release branches.
[Bug testsuite/112297] Failure of pr100936.c on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 --- Comment #3 from Iain Sandoe --- this seems to have been fixed by r14-6423-g02f562484c1752, does it need back porting? or should we close?
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Iain Sandoe --- thanks for the fixes, now passing on Darwin.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Iain Sandoe changed: What|Removed |Added Target Milestone|14.0|11.5 --- Comment #10 from Iain Sandoe --- fixed on trunk, but this will need back porting to avoid fails when building the release branches with latest toolchains / on newest OS versions.
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #16 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #15) > (In reply to Peter Bergner from comment #12) > > (In reply to Sergey Fedorov from comment #11) > > > (In reply to GCC Commits from comment #10) > > > > The master branch has been updated by Iain D Sandoe : > > > > > > Iain, thank you very much for addressing this! > > > > If this is fixed for you, can you please move this to RESOLVED / FIXED? > > I will need to rebuild gcc13 and try it out, allow me some time please. it is only fixed on trunk so far - I am currently working on back ports to earlier branches and this will be one of them - so please leave open for now.
[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 Iain Sandoe changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #15 from Iain Sandoe --- (In reply to Amir Shahmoradi from comment #14) > It's not a bug but a popular requested feature. See, for example, the > discussion here: > https://fortran-lang.discourse.group/t/distribute-shared-libraries-or-not/ > 7532/1 OK - I will reopen - but really someone needs to propose a patch - otherwise releases just go by. > Are there any downsides to distributing PIC-enabled `libgfortran.a` on all > platforms? yes. For platforms that support non-pic user-space code (e.g. Linux) then this would produce a performance penalty (since the PIC code is typically slower) > For consistency, if this is the default behavior on macOS, it should be the > default on all platforms. I doubt that would be a general agreement. If a given distribution (or use-case) needs the PIC version [and I can totally see why that would be the case for embedding it in a plugin) - then perhaps a suitable solution would be to introduce a specific configuration flag like "--enable-pic-runtimes" or "--enable-pic-libgfortran"
[Bug libobjc/48626] --enable-objc-gc should be automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48626 --- Comment #7 from Iain Sandoe --- now that boehm-gc is no longer in tree what should we do with this? I suppose there could be some more sophisticated top-level configuration (similar to GMP et. al.) which determines if there's a suitable libgc available?
[Bug target/42818] Static C++ linking breakage "undefined reference to ___real__Znwj" and others in libcygwin.a(_cygwin_crt0_common.o)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42818 Bug 42818 depends on bug 41596, which changed state. Bug 41596 Summary: handling of library-related options by g++spec.c causes a failure when generating pch. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/41596] handling of library-related options by g++spec.c causes a failure when generating pch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Iain Sandoe --- this has been fixed by the improved handling of -static-libstdc++ in r13-4870 (also in the D and M2 drivers).
[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 Iain Sandoe changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #13 from Iain Sandoe --- no feedback since 2021.
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #31 from Iain Sandoe --- what is the current situation with this - what input are we waiting for? - is the problem now cleared for powerpc64-freebsd?
[Bug bootstrap/88590] System Integrity Protection (SIP) breaks GCC build assumptions on Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88590 Iain Sandoe changed: What|Removed |Added Build|x86_64-apple-darwin1[5678] |x86_64-apple-darwin1[56789] ||, *-apple-darwin2* --- Comment #6 from Iain Sandoe --- fixed on trunk using the @rpath mechanism; TODO - determine if this might reasonably be back-ported.
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 --- Comment #12 from Iain Sandoe --- what input is this waiting for at the moment?
[Bug target/108743] [objective-c, NeXT runtime] -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Iain Sandoe --- (In reply to Eric Gallager from comment #12) > So I'm assuming this is staying open for backports to the 12 and 11 branches? yup, which is now done, so fixed.
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 --- Comment #9 from Iain Sandoe --- I think this is fixed now?
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-16 --- Comment #8 from Iain Sandoe --- according to information from the Apple OSS folks, the Kernel.framework is/was (never) intended to be used as a regular framework. [This was news to me, FWIW, and it does seem a somewhat odd situation, since it's wrapped up in all the necessary machinery which makes it look like it should work]. anyway What we want from this test is that a suitable framework is found in /System/Library/Frameworks when the user has also given a local framework path (-F.). What we want to avoid is the test regressing because of incidental SDK changes (like unguarded Apple Black usage) - so we have picked the kernel framework and a suitable low-complexity header. At present, I am thinking that IOkit/IOReturn.h might be a suitable substitute - but that needs to be checked across the range of OS versions supported.
[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin20 |*-darwin* Component|testsuite |c++ Last reconfirmed|2023-08-18 00:00:00 |2024-3-7 Host|x86_64-apple-darwin20 |*-darwin* Build|x86_64-apple-darwin20 |*-darwin* --- Comment #5 from Iain Sandoe --- I am shifting this to component C++, because the answer to comment #4 is really what's important - if this is supposed to work for file scope entities, then it needs to be a GCC extension (ISTM, anyway).
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233 --- Comment #5 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #3) > The question is: will this reveal new issues in other tests that weren't > running before. I'm starting a new regtest and will post the results here. Well, I do not think that actually matters (perhaps if newly revealed tests hang, it's a problem - but otherwise it's just telling us something we should already have known). So, FAOD absent something drastic like a hanging testsuite, the update to the darwin-specific code in the target-supports is OK.
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #3)
> Jakub has posted a patch in the linker PR (thanks!).
>
> But there remains a darwin bug. The test in check_effective_target_shared
> actually works with C, but not with C++, because:
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index ae33c4f1e3a..467b539b20d 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -1390,7 +1390,7 @@ proc check_effective_target_shared { } {
> # here to be undefined.
> set extra_flags ""
> if { [istarget *-*-darwin\[912\]*] } {
> - set extra_flags "-Wl,-U,_foo,-U,_bar"
> + set extra_flags "-Wl,-U,_foo,-U,_bar,-U,__Z3foov"
> }
Ah that's an omission on my part, the fix applied recently was incomplete :-(.
(FWIW, the "C" fix doubled the number of libphobos tests, IIRC).
