[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
[Bug pch/113970] New: [14 Regression] pch/system-{1,2}.C fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
Bug ID: 113970
Summary: [14 Regression] pch/system-{1,2}.C fails on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: needs-bisection, wrong-code
Severity: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Target: *-darwin*
somewhere between r14-8885 and r14-9043
FAIL: g++.dg/pch/system-1.C -g assembly comparison
FAIL: g++.dg/pch/system-1.C -O2 -g assembly comparison
FAIL: g++.dg/pch/system-2.C -g assembly comparison
FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison
lots of lines like:
line #354
< .long 0x11ac1
> .long 0x11ac2
line #691
< .uleb128 0x22
> .uleb128 0x21
line #703
< .uleb128 0x22
> .uleb128 0x21
line #805
< .uleb128 0x22
> .uleb128 0x21
presumably something has changed size or alignment.
[Bug target/112294] thread_local13.C and thread_local14.C fail on x86_64-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112294 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin21 |x86_64-apple-darwin* Build|x86_64-apple-darwin21 |x86_64-apple-darwin* Last reconfirmed|2023-10-30 00:00:00 |2024-2-17 Host|x86_64-apple-darwin21 |x86_64-apple-darwin* --- Comment #1 from Iain Sandoe --- I think this is probably a dup of PR106435 (the patch for that needs some rework)
[Bug analyzer/108562] [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562 Bug 108562 depends on bug 105755, which changed state. Bug 105755 Summary: -Wanalyzer-null-dereference regression compiling Emacs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |---
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-02-16 Ever confirmed|0 |1 CC||iains at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #7 from Iain Sandoe --- see comment #5 and #6
[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 Component|c++ |other Keywords|wrong-code |error-recovery URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Februar ||y/645814.html --- Comment #2 from Iain Sandoe --- patch posted.
[Bug c++/113957] [14 Regression] bad-mapper-1.C hangs on all Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957 --- Comment #1 from Iain Sandoe --- the problem is that liberty is using the value set by posix_spawnp for pid. but: (darwin): The argument pid is a pointer to a pid_t variable to receive the pid of the spawned process; if this is NULL, then the pid of the spawned process is not returned. If this pointer is non-NULL, then on successful completion, the variable will be modified to contain the pid of the spawned process. The value is undefined in the case of a failure. (linux): Upon successful completion, posix_spawn() and posix_spawnp() place the PID of the child process in pid, and return 0. If there is an error during the fork() step, then no child is created, the contents of *pid are unspecified, and these functions return an error number as described below. So .. I think the fix will be to set pid = -1 in the error paths .. will try that.
[Bug c++/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 Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-16
[Bug c++/113957] New: [14 Regression] bad-mapper-1.C hangs on all Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957 Bug ID: 113957 Summary: [14 Regression] bad-mapper-1.C hangs on all Darwin. Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ Assignee: iains at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- Target: *-*-darwin* Initial analysis: this seems to be hanging in a read in libcody.
[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 --- Comment #5 from Iain Sandoe --- AFAICT, this was fixed on trunk by r14-6721-gd31c54c7da7661 (which seems to have a reference to the PR so not sure why it did not show up here). I think we need this on any open branch which we want to work with macOS14+.
[Bug target/112864] Many libphobos tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864 Iain Sandoe changed: What|Removed |Added Summary|[14 regression] Many|Many libphobos tests FAIL |libphobos tests FAIL on |on macOS 12+ |macOS 12+ | --- Comment #4 from Iain Sandoe --- this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - (almost certainly for macOS14 + Xcode 15.1+)
[Bug target/112863] Many obj-c++ tests FAIL on macOS 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 Iain Sandoe changed: What|Removed |Added Summary|[14 regression] Many|Many obj-c++ tests FAIL on |obj-c++ tests FAIL on macOS |macOS 14 |14 | --- Comment #9 from Iain Sandoe --- this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - (almost certainly for macOS14 + Xcode 15+).
[Bug target/112862] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 Iain Sandoe changed: What|Removed |Added Summary|[14 regression] gfortran.dg |gfortran.dg coarray tests |coarray tests FAIL on macOS |FAIL on macOS 12+ |12+ | --- Comment #15 from Iain Sandoe --- this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - so leaving open for now.
[Bug target/112861] Most gdc tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861 Iain Sandoe changed: What|Removed |Added Summary|[14 regression] Most gdc|Most gdc tests FAIL on |tests FAIL on macOS 12+ |macOS 12+ --- Comment #6 from Iain Sandoe --- this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - so leaving open for now.
[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #4 from Iain Sandoe --- Created attachment 57378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378=edit patch under test This implements the common case for an i386 trampoline (and, in this respect, matches the expectations for x86_64 and aarch64). -- to explain the "common case" comment. We still have work to do to generalise the heap trampoline implementation; Several platforms have multiple trampoline implementations that can depend on optimisations or protections. At present, I considered: (1) - having the heap trampoline impl just deal with managing the storage. -- one would call a builtin to obtain a writeable trampoline area -- one would then use the inline existing trampoline impl to populate that -- one would then call to the heap management to apply conditions to make the written trampoline executable (since most security models do not allow writable+executable at the same time). -- although this model re-uses the existing trampoline in-line code-gen, I'm not in favour of it (a) it means two calls to libgcc_s for each case + (b) the inline code-gen is replicated which appears pointless code bloat since we have failed to avoid an out of line function call already. (2) - having the caller of __gcc_heap_trampoline_created () pass sufficient information for that function to alter the flavour of trampoline as needed. ( i) - we could add an extra argument to communicate this information (it could be as simple as an enum, probably). (ii) - We could re-use the third argument (which is a pointer to a pointer) to pass in a pointer to the data (or nullptr, for 'default' perhaps) -- in either case we need a new target hook that returns the relevant enum (or other target-private data) to be passed to __gcc_heap_trampoline_created(). (3) - perhaps using the existing in-line codegen into a scratch space and passing that to __gcc_heap_trampoline_created () -- not keen on this because: (a) the same comment about in-line code + out of line call. (b) if the trampoline uses relative branches (like the i386 common case) then those need to be relocated, which then means that the __gcc_heap_trampoline_created routine would have to match the relevant patterns and do the relocation. so, at the moment, (2) is my favoured approach - but more thinking might being other ideas.
[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #3 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #2) > Guess an ia32 implementation would be even better, shouldn't be that hard. I have a draft on one of my machines, I'll post it here tomorrow.
[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #1 from Iain Sandoe --- I was looking at making an i686 impl. but we could also do as you suggest for gcc-14.
[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
--- Comment #10 from Iain Sandoe ---
automake if is limited to testing a single variable, so we have to introduce an
AM_CONDITIONAL to say the OS is DARWIN (we did not seem to have one already,
but I could have missed something else usable).
I'm testing this - if it's not too invasive (but I'll also try, at some point,
to see if applying this to the whole library build makes any measurable
performance change)
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index c68cac4f345..37396bd6ebb 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -109,6 +109,12 @@ ACX_LT_HOST_FLAGS
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
AM_CONDITIONAL([ENABLE_DARWIN_AT_RPATH], [test x$enable_darwin_at_rpath =
xyes])
+os_is_darwin=no
+case ${host_os} in
+ darwin*) os_is_darwin=yes ;;
+ *) ;;
+esac
+AM_CONDITIONAL([OS_IS_DARWIN], [test x${os_is_darwin} = xyes])
if test "$enable_vtable_verify" = yes; then
predep_objects_CXX="${predep_objects_CXX}
${glibcxx_builddir}/../libgcc/vtv_start.o"
diff --git a/libstdc++-v3/libsupc++/Makefile.am
b/libstdc++-v3/libsupc++/Makefile.am
index d0e1618507e..645d53cb6ab 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -132,6 +132,14 @@ atomicity_file =
${glibcxx_srcdir}/$(ATOMICITY_SRCDIR)/atomicity.h
atomicity.cc: ${atomicity_file}
$(LN_S) ${atomicity_file} ./atomicity.cc || true
+if OS_IS_DARWIN
+# See PR 112397
+new_opvnt.lo: new_opvnt.cc
+ $(LTCXXCOMPILE) -fno-reorder-blocks-and-partition -I. -c $<
+new_opvnt.o: new_opvnt.cc
+ $(CXXCOMPILE) -fno-reorder-blocks-and-partition -I. -c $<
+endif
+
# AM_CXXFLAGS needs to be in each subdirectory so that it can be
# modified in a per-library or per-sub-library way. Need to manually
# set this option because CONFIG_CXXFLAGS has to be after
[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
--- Comment #7 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > Maybe:
> >
> > ifneq ($(filter %-darwin%,${host_alias}),)
>
> ${target_os} instead maybe?
I'll give that a try (we have similar stanzas in the Ada build stuff)
[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 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-07 Ever confirmed|0 |1 --- Comment #3 from Iain Sandoe --- (In reply to Iain Sandoe from comment #2) > (In reply to Jonathan Wakely from comment #1) > > The .cold symbol is created by gcc, I don't see any way to control its > > visibility in the source. So maybe a target bug in the compiler, not a > > library bug. > > Agreed its a target issue - it's a question of convincing the linker that > the label is not reachable from a different TU if the implementation of the > non-cold symbol comes from that. The problem is this: We partition the function into hot/cold. so we have weak definition hot . do stuff ... make a call Landingpad1 OK... return epilogue_code: Landingpad2 bad -> jump to error_case cold error_case: ... do stuff jump epilogue_code. The linker says "oh you have a direct jump to that epilogue code in a weak definition which would be broken if a different weak definition was chosen by the dynamic linker". On the face of it, the linker is correct ... ... but what it cannot see is that the only way to be executing the code that makes this jump is if it came from Landingpad2. So actually, we do not have a real error - but I am not sure how we could go about teaching the linker to DTRT (even if we could persuade Apple to do the same for the new closed source one). I'm tempted to suggest that we consider building libstdc++ with `-fno-reorder-blocks-and-partition` and see if there's any measurable performance decrease. NOTE; that Darwin's linker (using subsections_by_symbols) is also able to partition and reorder code without help from the compiler .. (although whether/how much it does I"m not sure). If there's a way to add that [-fno-reorder-blocks-and-partition] flag to that single source for Darwin-only, that would be a short-term workaround.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #11 from Iain Sandoe --- (In reply to Rainer Orth from comment #10) > Patch posted. FWIW Darwin is, indeed, also affected and I have patches in progress to resolve it.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-05 Status|UNCONFIRMED |NEW --- Comment #10 from Iain Sandoe --- (In reply to Iain Buclaw from comment #8) > Created attachment 57329 [details] > The quick fix to the lock-free test > > The immediate thing that can be changed is turning the test into a > `__traits(compiles)` one, which would turn the error into a `false` value. This works for me on both powerpc64-linux and a powerpc-darwin9 cross. NOTE: I expect a reduced testsuite on powerpc-darwin since we build "--with-libphobos-druntime-only" however, I am a bit surprised that powerpc64-linux has roughly half the number of tests (590 c.f. 1100) of x86_64-linux; is this expected? (independent of this fix, this was the case before too).
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #6 from Iain Sandoe --- (In reply to Iain Buclaw from comment #4) > Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time > /* If it isn't always lock free, don't generate a result. */ > if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node) > return boolean_true_node; ^ but this does fall back to a libcall to the relevant libatomic function, (you can verify that with a simple C routine).. and given that both darwin and linux powerpc have libatomic impls. this still should not give an "unimplemented" response.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Buclaw from comment #4)
> Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
> values one can get out of this built-in are "true" and "defer to run-time"
>
> ---
> /* Return a one or zero if it can be determined that object ARG1 of size ARG
>is lock free on this architecture. */
>
> static tree
> fold_builtin_atomic_is_lock_free (tree arg0, tree arg1)
> {
> if (!flag_inline_atomics)
> return NULL_TREE;
>
> /* If it isn't always lock free, don't generate a result. */
> if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node)
> return boolean_true_node;
>
> return NULL_TREE;
> }
> ---
>
> The upstream contributor who tested this on x86 likely didn't get this
> because it's all lock-free.
indeed x86_64 and i686 both build fine .. but "it's all lock-free" is not
entirely true - x86-64 is only lock free up to 16bytes, so it might be a bug
waiting to happen there too.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #3 from Iain Sandoe --- extern pure nothrow @nogc @safe bool __atomic_always_lock_free(uint, shared(const(void))*); extern pure nothrow @nogc @safe bool __atomic_is_lock_free(uint, shared(const(void))*); perhaps there's a parameter type mismatch or sth?
