[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"?
[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).
[Bug target/114233] Newly-introduced pr113617.C test fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114233 --- Comment #1 from Iain Sandoe --- note Darwin's linker does not, by default permit symbols to be undefined. If the test case requires allowing undefined symbols to complete, then either we need to specify them thus: -Wl,-U,_XXX (for each symbol) or if they are unknown at build time, but required dynamically at runtime... -Wl,-undefined,dynamic_lookup ( I am not sure if this is a requirement of the test, or some artefact of the test case reduction ).
[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Iain Sandoe --- (In reply to Marek Polacek from comment #6) > Should we close this as fixed then? Yes, it is fixed as per my recent testing.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #15 from Iain Sandoe --- (In reply to Dimitry Andric from comment #14) > (In reply to Iain Sandoe from comment #13) > > (In reply to Francois-Xavier Coudert from comment #11) > > > Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking > > > bootstrap on x86_64-apple-darwin23 > > > > confirmed the bootstrap fail and that the proposed patch fixes it (on > > x86_64-darwin23). Now testing more widely on other Darwin versions. > > > > For Darwin, this is a regression (caused by changes in the system SDK > > headers) - what is the situation with freeBSD? > > The situation is that the FreeBSD port maintainer disabled the option to > build the gcc ports without bootstrap, to work around the problem. :-) > > I built the ports locally, but there are seem to have been some recent > introductions of poisoned identifiers in plugins, which also have be fixed > by adding #define INCLUDE_xxx statements at the top of the sources, before > including system.h. > > I will update the patches to build with gcc master, and re-attach/send them. FAOD, in the Darwin case this is a failure in the regular bootstrap at stage-1 (not an attempt to build --disable-bootstrap or a cross).
[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 CC||iains at gcc dot gnu.org --- Comment #13 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #11) > Starting with Xcode 15.3 and the SDK for macOS 14.4, this is breaking > bootstrap on x86_64-apple-darwin23 confirmed the bootstrap fail and that the proposed patch fixes it (on x86_64-darwin23). Now testing more widely on other Darwin versions. For Darwin, this is a regression (caused by changes in the system SDK headers) - what is the situation with freeBSD?
[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 #13 from Iain Sandoe --- fixed on trunk, intending to backport it.
[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 --- Comment #6 from Iain Sandoe --- I'm still finding this a bit confusing. - we have not altered the code in this area (at least not the Darwin parts) during the gcc-14 cycle. - apparently, it works with previous Xcode versions/SDKs - from your comment #2 "$ clang /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c -F. -S -o framework-1.s In file included from /vol/gcc/src/hg/master/darwin/gcc/testsuite/gcc.dg/framework-1.c:4: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers/string.h:55:10: error: 'machine/trap.h' file not found with include; use "quotes" instead #include " that seems to be an error, not a warning (even if it diagnoses better than we do). - even if it tries to fall back to the "" version, that still should not find the header according to the information in comment #5 - since we so not add any paths below Library/Frameworks .. so 'machine' is only a top level include directory in /usr/include (and it does not contain trap.h).
[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970 --- Comment #4 from Iain Sandoe --- Created attachment 57501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57501=edit without PCH As Andrew says, the differences are in the debug info (it might even only be in the order of the debug info - hard to tell from a quick comparison).
[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970 --- Comment #3 from Iain Sandoe --- Created attachment 57500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57500=edit with PCH
[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 --- Comment #5 from Iain Sandoe --- The manual currently says: -I dir -iquote dir -isystem dir -idirafter dir Add the directory dir to the list of directories to be searched for header files dur- ing preprocessing. If dir begins with ‘=’ or $SYSROOT, then the ‘=’ or $SYSROOT is replaced by the sysroot prefix; see --sysroot and -isysroot. Directories specified with -iquote apply only to the quote form of the directive, #include "file". >>> Directories specified with -I, -isystem, or -idirafter apply to lookup for >>> both the #include "file" and #include directives. <<< You can specify any number or combination of these options on the command line to search for header files in several directories. The lookup order is as follows: 1. Forthequoteformoftheincludedirective,thedirectoryofthecurrentfile is searched first. 2. For the quote form of the include directive, the directories specified by -iquote options are searched in left-to-right order, as they appear on the command line. 3. Directories specified with -I options are scanned in left-to-right order. 4. Directories specified with -isystem options are scanned in left-to-right order. 5. Standard system directories are scanned. 6. Directories specified with -idirafter options are scanned in left-to-right The highlighted bit seems to say we should be searching for either "" or <> .. I wonder if something is being confused by the user framework path (-F .)
[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 --- Comment #3 from Iain Sandoe --- so .. if i follow your discussion correctly - neither clang nor gcc finds it because it's incorrectly quoted (is that an SDK issue?).. or? We do have control, IIRC, about adding the frameworks search path to "system" rather than "user".
[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 --- Comment #1 from Iain Sandoe --- /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Headers should be a symlink to /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers so either that's broken or we're failing to follow a symlink somehow.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #26 from Iain Sandoe --- but from your initial post it's also guarded by: #ifndef __has_cpp_attribute #define __has_cpp_attribute(x) 0 #endif so it will always be 0 for clang in C mode, since that does not define __has_cpp_attribute
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #22 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #21) > > --- Comment #19 from fxcoudert at gmail dot com > com> --- > The only issue left (the gcc.dg/framework-1.c failure) so far seems to > be an issue with gcc not setting include paths correctly for frameworks. Please raise a separate BZ for that - it's a bit surprising (I would have expected more fails if that was not working).
[Bug target/114033] Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #2)
> This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS
> 14.3).
> I am attaching the preprocessed source.
>
> The code from CFData.h that is triggering this is:
>
> typedef CF_OPTIONS(CFOptionFlags, CFDataSearchFlags) {
> kCFDataSearchBackwards = 1UL << 0,
> kCFDataSearchAnchored = 1UL << 1
> } API_AVAILABLE(macos(10.6), ios(4.0), watchos(2.0), tvos(9.0));
>
> which preprocesses to:
>
> typedef __attribute__((availability(swift,unavailable))) CFOptionFlags
> CFDataSearchFlags; enum : CFDataSearchFlags {
> kCFDataSearchBackwards = 1UL << 0,
> kCFDataSearchAnchored = 1UL << 1
> } ;
So - it seems we have an unguarded use of __attribute__ availability - we'll
need to track back to why API_AVAILABLE is not DTRT.
* I did post patches to enable us to consume the availability attribute, but
did not have time to address review comments got GCC-14; although it would
remain an option for darwin-local branches.
> There is similar code linked to the error in CFString.h:
>
> typedef CF_OPTIONS(CFOptionFlags, CFStringCompareFlags) {
> kCFCompareCaseInsensitive = 1,
> kCFCompareBackwards = 4,/* Starting from the end of the
> string */
> kCFCompareAnchored = 8, /* Only at the specified starting
> point */
> kCFCompareNonliteral = 16, /* If specified, loose equivalence
> is performed (o-umlaut == o, umlaut) */
> kCFCompareLocalized = 32, /* User's default locale is used for
> the comparisons */
> kCFCompareNumerically = 64, /* Numeric comparison is used; that
> is, Foo2.txt < Foo7.txt < Foo25.txt */
> kCFCompareDiacriticInsensitive API_AVAILABLE(macos(10.5), ios(2.0),
> watchos(2.0), tvos(9.0)) = 128, /* If specified, ignores diacritics
> (o-umlaut == o) */
> kCFCompareWidthInsensitive API_AVAILABLE(macos(10.5), ios(2.0),
> watchos(2.0), tvos(9.0)) = 256, /* If specified, ignores width differences
> ('a' == UFF41) */
> kCFCompareForcedOrdering API_AVAILABLE(macos(10.5), ios(2.0),
> watchos(2.0), tvos(9.0)) = 512 /* If specified, comparisons are forced to
> return either kCFCompareLessThan or kCFCompareGreaterThan if the strings are
> equivalent but not strictly equal, for stability when sorting (e.g. "aaa" >
> "AAA" with kCFCompareCaseInsensitive specified) */
> };
I guess the same glitch here.
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #2 from Iain Sandoe --- if there are lots of symbols that need to be undefined .. then one can use an undefined symbols file. Of course, it does not work if we do not know the symbol names at build-time.
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #1 from Iain Sandoe --- yeah, there is a better way to do this with ld64 (and presumably dyld-ld), my guess is that this is an anachronism from the ld_classic (v1) days. We can tell the linker it's OK for a symbol to be undefined - and then that makes it behave like the ELF case. "-Wl,-U,_symbol_name " is the incantation to do this - and AFAIK should work back to i686-darwin9 (which is the earliest I test these days).
[Bug target/114034] Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 --- Comment #1 from Iain Sandoe --- let me see if we're adding an extra in the Darwin specs that is covered elsewhere (sometimes the specs get changed in gcc/gcc.cc and it takes us some time to sync the ones in darwin.h)
[Bug target/114033] Failure of test darwin-cfstring1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 --- Comment #1 from Iain Sandoe --- which actual SDK is this? you should be able to look at the SDKsettings.plist in the root of the SDK, if there's any need to discriminate versions with the same name. (and is it possible to get pre-processed output?) [I hope we do not have the situation where we have a broken header in the Frameworks ...]
[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 --- Comment #7 from Iain Sandoe --- (In reply to Sebastian "spaetz" Spaeth from comment #5) > I fully understand that nobody wants to invest time into fixing this. What > would be nice though, is if this were really just a missed optimization and > not rejecting to compile valid code. It's not that no-one wants to fix the bug, it's just that no-one wants it fixed enough to hire someone to do it .. and it's too much work for "spare time hacking". While ibm-128 is being phased out in favour of ieee754 - it is still used on a number of systems that are current and will be for a few more GCC releases. Given the increase in use of constexpr, it's likely to become more common to see issues. In the past, I worked around the problem by making conditional non-constexpr code (so _not_ ignoring constexpr, but having a #ifdef'd alternate path.)
[Bug target/113971] [14 Regression] failure to build on arm64 musl (#error "Unsupported AArch64 platform for heap trampolines")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- fixed on trunk
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-20 Ever confirmed|0 |1 --- Comment #12 from Iain Sandoe --- further the manual says: "The special operator __has_cpp_attribute (operand) may be used in ‘#if’ and ‘#elif’ expressions in C++ code to test whether the attribute referenced by its operand is recognized by GCC" Which seems to be explicit about the use in C++ code (which makes me suspect that the availability in C mode might be unintentional). Currently it seems that libcpp makes __has_cpp_attribute an alias for __has_attribute, whereas __has_c_attribute is considered separate in the enumerations.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #11 from Iain Sandoe --- looking at n2176 - C18 there is no mention of __has_c* looking at n3047 - C23 there is mention only of __has_c_attribute OTOH, there is no prohibition in declaring __has_cpp_attribute (c.f. an actual prohibition in declaring __cplusplus). So, perhaps this is a GCC extension that should only be applied to -std=gnucxx?
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #10 from Iain Sandoe --- indeed, it seems clang does not define __has_cpp_attribute for -std=c11 c compilations, whereas GCC does.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #6 from Iain Sandoe --- (In reply to Iain Sandoe from comment #5) > perhaps this is also a clang regression - for Jakub's example with Xcode > 15.1 : (xcode clang, that is, I did not test with upstream clang yet).
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #5 from Iain Sandoe ---
perhaps this is also a clang regression - for Jakub's example with Xcode 15.1 :
$ clang --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin23.3.0
master-wip-short-queue mini-05-son:gcc-master iainsandoe$ clang t.c -std=c11
-fsyntax-only
t.c:2:29: error: missing ')' after ':'
#if __has_c_attribute (clang::unsafe_buffer_usage)
^
t.c:2:23: note: to match this '('
#if __has_c_attribute (clang::unsafe_buffer_usage)
^
t.c:5:5: error: function-like macro '__has_cpp_attribute' is not defined
#if __has_cpp_attribute (clang::unsafe_buffer_usage)
^
2 errors generated.
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 Iain Sandoe changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- Is this a clang extension (handling clang::x with -std= < c23)? i.e. if the header is not actually standard-conforming - perhaps there's time to get the released SDK fixed (did you raise a feedback?)
[Bug other/113957] [14 Regression] bad-mapper-1.C hangs on all Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Iain Sandoe --- fixed on trunk.
[Bug middle-end/19779] IBM 128bit long double format is not constant folded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779 --- Comment #9 from Iain Sandoe --- (In reply to Andrew Pinski from comment #8) > (In reply to Sergey Fedorov from comment #6) > > (In reply to Andrew Pinski from comment #0) > > > This is the new bug for PR 19405. Keeping track of that we no longer > > > constant fold long doubles in the > > > IBM 128bit long double format. > > > > What is the current status of the issue? > > Nothing has changed here that much. Though powerpc64 le is heading towards > doing IEEE 128bit FP by default so this might be much much less of an issue > for most people which means this is more likely never get fixed. it occasionally causes grief, but so far there's been a work-around; I guess if someone really wanted to make a patch - they'd have to use MPFR et. al. to do the work.
[Bug target/113971] [14 Regression] failure to build on arm64 musl (#error "Unsupported AArch64 platform for heap trampolines")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-02-18 --- Comment #2 from Iain Sandoe --- Created attachment 57456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57456=edit patch to allow heap trampolines for all aarch64-linux This has been tested so far on aarch64-linux-gnu and aarch64-darwin; I do not have access to an aarch64-linux-muscl system to check that.
[Bug target/113971] [14 Regression] failure to build on arm64 musl (#error "Unsupported AArch64 platform for heap trampolines")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113971
--- Comment #1 from Iain Sandoe ---
the intent was not to enable this feature for platforms we could not test.
but libgcc/config.host has "aarch64*-*-linux*" so we have inadvertently enabled
it for aarch64-linux-musl.
assuming linux-musl defines __linux__ ... something like:
diff --git a/libgcc/config/aarch64/heap-trampoline.c
b/libgcc/config/aarch64/heap-trampoline.c
index 9d5b19983b1..1e3460b1601 100644
--- a/libgcc/config/aarch64/heap-trampoline.c
+++ b/libgcc/config/aarch64/heap-trampoline.c
@@ -29,7 +29,7 @@ void *allocate_trampoline_page (void);
void __gcc_nested_func_ptr_created (void *chain, void *func, void *dst);
void __gcc_nested_func_ptr_deleted (void);
-#if defined(__gnu_linux__)
+#if defined(__linux__)
static const uint32_t aarch64_trampoline_insns[] = {
0xd503245f, /* hint34 */
0x58b1, /* ldr x17, .+20 */
@@ -82,7 +82,7 @@ allocate_trampoline_page (void)
{
void *page;
-#if defined(__gnu_linux__)
+#if defined(__linux__)
page = mmap (0, getpagesize (), PROT_WRITE | PROT_EXEC,
MAP_ANON | MAP_PRIVATE, 0, 0);
#elif __APPLE__
[Bug c++/113970] [14 Regression] pch/system-{1,2}.C fails on darwin after r14-8987-gdd9d14f7d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Iain Sandoe changed:
What|Removed |Added
Component|pch |c++
CC||nshead at gcc dot gnu.org
Summary|[14 Regression] |[14 Regression]
|pch/system-{1,2}.C fails on |pch/system-{1,2}.C fails on
|darwin |darwin after
||r14-8987-gdd9d14f7d53
Keywords|needs-bisection |
Target Milestone|--- |14.0
--- Comment #1 from Iain Sandoe ---
Bisected to r14-8987-gdd9d14f7d53; reverting that commit on current trunk
(r14-9043) also clears the issue.
[Bug pch/113970] [14 Regression] pch/system-{1,2}.C fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-02-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
