[Bug testsuite/66005] libgomp make check time is excessive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #19 f

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110073 --- Comment #3 from Iain Sandoe --- (In reply to Iain Sandoe from comment #2) > there seems to be a second fail on x86_64 darwin on line 970. I tried the alternate patch on a number of x86_64, i686 and power Darwin systems and bootstrap is rest

[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951 --- Comment #8 from Iain Sandoe --- (In reply to Thomas Schwinge from comment #6) > > "Consider '--with-build-sysroot=[...]' for target libraries' build-tree > testing (inst

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110073 --- Comment #5 from Iain Sandoe --- (In reply to David Faust from comment #4) > (In reply to Iain Sandoe from comment #3) > > (In reply to Iain Sandoe from comment #2) > > > there seems to be a second fail on x86_64 darwin on line 970. > > > >

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #20 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #19) > (In reply to Iain Sandoe from comment #1) > > Just to add one note, which is that Apple's gcc-4.2.1 implementation for > > blocks was not actually submitted (and

[Bug target/110044] [10/11/12/13 Regression] #pragma pack(push, 1) may not force packing, while __attribute__((packed, aligned(1))) works

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug modula2/110284] [14 Regression] Bootstrap failures with m2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #11

[Bug target/110406] d: Wrong code-gen returning POD structs by value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #11

[Bug target/110406] d: Wrong code-gen returning POD structs by value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #12 from Iain Sandoe --- OTOH there was a second issue with zero-sized objects which was fixed thus: diff --git a/gcc/d/types.cc b/gcc/d/types.cc index a1f69bb02b7..020cc7de83f 100644 --- a/gcc/d/types.cc +++ b/gcc/d/types.cc @@ -58

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #3 from Iain Sandoe --- interesting - Apple clang does seem to accept __attribute__((init_priority)) but it still does not actually work **between TUs** unless LTO is engaged. Actually GCC for Darwin could adopt a similar scheme

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #5 from Iain Sandoe --- (In reply to Sascha Scandella from comment #4) > I found also this issue regarding init_priority: > https://github.com/llvm/llvm-project/issues/15363 So that is the intentional behaviour (upstream clang defin

[Bug c++/110447] New: [modules] unexpected attachment of GMF decls to a named module.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110447 Bug ID: 110447 Summary: [modules] unexpected attachment of GMF decls to a named module. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c++/110447] [modules] unexpected attachment of GMF decls to a named module.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110447 Iain Sandoe changed: What|Removed |Added CC||nathan at acm dot org --- Comment #1 from

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110073 --- Comment #10 from Iain Sandoe --- this is fixed, at least on Darwin, right? is there some failing case remaining on Solaris or can we close this?

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432 --- Comment #10 from Iain Sandoe --- (In reply to Patrick Palka from comment #9) > (In reply to Jonathan Wakely from comment #1) > > Patrick, we talked about this and IIRC your suggestion was to move the > > __has_attribute check into configure,

[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 Last reconfirmed||2023-07-02 Component|objc

[Bug target/110611] New: X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110611 Bug ID: 110611 Summary: X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Pr

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110611 Iain Sandoe changed: What|Removed |Added Target||x86_64-linux-gnu, |

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110611 --- Comment #2 from Iain Sandoe --- (In reply to Iain Sandoe from comment #0) > the x86 backend sets: > gcc/config/i386/i386.h:#define POINTERS_EXTEND_UNSIGNED 1 > which ought, according to gccint mean that pointers get sign-extended... erm I

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110611 --- Comment #4 from Iain Sandoe --- (In reply to Andreas Schwab from comment #3) > uint64_t is neither Pmode nor word_mode here. POINTERS_EXTEND_UNSIGNED is > only relevant if POINTER_SIZE is narrower than Pmode. So, just pilot-error, then?

[Bug target/110611] X86 is not honouring POINTERS_EXTEND_UNSIGNED in m32 code.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110611 Iain Sandoe changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 --- Comment #1 from Iain Sandoe --- OK. (I do not have enough hardware to install 14 or xc15 at present). I guess we just add a configuration test for it and then make the link line dependent; will have a go on D21+XC14.3

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 --- Comment #3 from Iain Sandoe --- actually, we already have a config test for -platform_version, which is what clang passes to ld. First, I'll take a look at enabling that (in which case the mmacosx_version_min is not needed). I take it that

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 --- Comment #5 from Iain Sandoe --- Created attachment 55523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55523&action=edit Patch for testing I tested this (by bootstrapping GCC with it) on x86_64 darwin21 with Xcode 14.3. FWIW; The re

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |11.5 Assignee|unassigned at gcc

[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 --- Comment #1 from Iain Sandoe --- (In reply to Rainer Orth from comment #0) > When bootstrapping current trunk on macOS 14.0 beta 3 with Xcode 15 beta 4, > every single fortran link test FAILs like > * Get rid of %(libgcc) in libgfortran.spec

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963 --- Comment #2 from Iain Sandoe --- r14-4825-g6a6d3817afa02b, (adding @rpath support) was not intended to change the behaviour of libc handling, but as noted a rebase error left that in (probably because both changes acted on the link). So the

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963 --- Comment #3 from Iain Sandoe --- (In reply to Andreas Schwab from comment #1) > How did that work before r14-4825-g6a6d3817afa02b? I suppose, unconditional adding of '-lm' is not a problem to the affected bare metal targets but using the AC_

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963 --- Comment #6 from Iain Sandoe --- I cannot peak for the others, but Darwin does not need '-lm' because it is part of libc [libSystem] (adding -lm actually symlinks to libSystem and alters the effective library order on the link line so I'd pre

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963 --- Comment #8 from Iain Sandoe --- I propose to test the patch at comment #2 as a step to restore the original behaviour. It would be nice to make the libm use configurable (as per libgfortran or libstdc++) as a separate issue.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963 --- Comment #11 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #10) > BTW, yet another option would be to just > LIBM= > case $host in > *-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*) > # These syst

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963 --- Comment #12 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #10) > BTW, yet another option would be to just > LIBM= > case $host in > *-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*) > # These syst

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #24 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #23) > (In reply to Andrew Pinski from comment #22) > > (In reply to Sergey Fedorov from comment #21) > > > Any chance of having it fixed in gcc14? > > > > It is too l

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 f

[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #1 from Iain Sandoe --- this seems a somewhat similar dilemma to the emulated TLS case. Perhaps: provide a weak definition of these in a CRT (which is used for -static-libgcc) and weaken the defs in libgcc_s so that mixed scenario

[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #3 from Iain Sandoe --- (In reply to Florian Weimer from comment #2) > Weak symbols have no meaning for ELF DSOs, so this wouldn't work for > libgcc_s on ELF targets. Instead we automatically link against dynamic > libgcc_s if certai

[Bug libgcc/113403] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #5 from Iain Sandoe --- Sorry, my intended design was not stated very clearly. 1. IIUC, the objective is to have only one instance of these symbols in the dynamically-linked program. 2. One way to ensure that is to make it a requi

[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 #3 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #2) > Created attachment 57087 [details] > gcc14-pr113402.patch > > > Though, I wonder if we also shouldn't rename those symbols, having __builtin_ > prefix in the na

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #10 from Iain Sandoe --- it is an optimisation, yes - but as Richi points out, if we change this it will affect ABI - so it is ideal to do this before the first release that includes it? - IIUC Jakub's suggestion: - remove the fun

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #13 from Iain Sandoe --- (In reply to Florian Weimer from comment #12) > (In reply to Jakub Jelinek from comment #11) > > Or put it in libgcc_eh.a and libgcc_s.so.1? > > Yes, that's what I came up with as well (conceptually, not a p

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #1 from Iain Sandoe --- this appears to be fixed; I get clean fortran testsuite results on (x86_64) Darwin21 and Darwin23. Please could you check and either close this or post your Xcode version, configure line and OS version.

[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 --- Comment #1 from Iain Sandoe --- which Xcode version produces this? on Darwin23 with XC15.1 I get clean obj-c++ results (but we should omit the duplicates anyway)

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #3 from Iain Sandoe --- OK. So I realise the reason you see this and I wasn't: I have the habit of installing before running the testsuite. When I test uninstalled, then I get the issue. ... the subsequent work reveals that we are

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #5 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #4) > > --- Comment #3 from Iain Sandoe --- > > OK. So I realise the reason you see this and I wasn't: I have the habit of > > installing before running

[Bug analyzer/113150] FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c -std=c++98 (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113150 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Target|hppa64-hp-hpux11.11

[Bug analyzer/113150] FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c -std=c++98 (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113150 --- Comment #3 from Iain Sandoe --- on darwin we also get (all with the same diagnostic - about a leaked fd) I can report them separately if you like - but it seems likely to be a common cause: FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-

[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #14 from Iain Sandoe --- Created attachment 57182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57182&action=edit patch under test this is what I'm testing - these functions are removed from libgcc.a and added to libgcc_eh.a

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #3 from Iain Sandoe --- for platforms using pthreads as the underlying resource, then perhaps we can do this without thread_atexit (which I do not see in many places) by using pthread_cleanup_push () not sure if gthr.h abstracts tha

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #5 from Iain Sandoe --- (In reply to Florian Weimer from comment #4) > (In reply to Iain Sandoe from comment #3) > > for platforms using pthreads as the underlying resource, then perhaps we can > > do this without thread_atexit (whic

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #7 from Iain Sandoe --- (In reply to Florian Weimer from comment #6) > Sorry, pthread_cleanup_push is purely scope-based, like the existing > handler. It cannot be used to push a handler to some unscoped cleanup > function list that

[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #9 from Iain Sandoe --- (In reply to Florian Weimer from comment #8) > Which version of the manual page are you looking at? > > https://man7.org/linux/man-pages/man3/pthread_cleanup_push.3.html seems > pretty clear about the scope-b

[Bug target/112861] [14 regression] Most gdc tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #7 from Iain Sandoe --- Created attachment 57202 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57202&action=edit patch under test works on x86_64 Sonoma with XC CLT 15.1 testing more widely

[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #9 from Iain Sandoe --- (In reply to Rainer Orth from comment #8) > Again tested on macOS 11 (unchanged) and 14. On the latter, the previous > failures > to find libatomic.1.dylib have been traded for > > FAIL: gfortran.dg/coarray/

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #11 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #10) > > --- Comment #9 from Iain Sandoe --- > > (In reply to Rainer Orth from comment #8) > >> Again tested on macOS 11 (unchanged) and 14. On the la

[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 --- Comment #5 from Iain Sandoe --- (In reply to Rainer Orth from comment #4) > On macOS 11, everything is still fine. On macOS 14, there's progress: > The remaining failures fall into two categories: > > FAIL: obj-c++.dg/encode-10.mm -fgnu-r

[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506 Iain Sandoe changed: What|Removed |Added Last reconfirmed|2023-11-13 00:00:00 |2024-1-27 --- Comment #5 from Iain Sandoe

[Bug target/112861] [14 regression] Most gdc tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma

[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma

[Bug target/112864] [14 regression] Many libphobos tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-01-28 Status|UNCONFIRMED

[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506 --- Comment #8 from Iain Sandoe --- (In reply to Gaius Mulley from comment #7) > I doubt the m2date and testclock are related to filesystem case (but I could > be wrong) as I've built gcc on a gnu-linux jfs filesystem (case preserving > case ins

[Bug modula2/111627] modula2: Excess test fails with a case-preserving-case-insensitive source tree.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627 --- Comment #6 from Iain Sandoe --- FWIW. testing on i686-darwin9 and x86_64-darwin14 with case-preserving-non-case-sens shows these fixed.

[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506 --- Comment #9 from Iain Sandoe --- (In reply to Iain Sandoe from comment #8) > (In reply to Gaius Mulley from comment #7) > > I doubt the m2date and testclock are related to filesystem case (but I could > > be wrong) as I've built gcc on a gnu-

[Bug target/112861] [14 regression] Most gdc tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861 --- Comment #5 from Iain Sandoe --- I suppose we are going to have to consider back porting this, if we want to avoid the same problems on open branches.

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 --- Comment #14 from Iain Sandoe --- I suppose we are going to have to consider back porting this, if we want to avoid the same problems on open branches.

[Bug target/112863] [14 regression] Many obj-c++ tests FAIL on macOS 14

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 --- Comment #8 from Iain Sandoe --- I suppose we are going to have to consider back porting this (and the fixes for data layout), if we want to avoid the same problems on open branches.

[Bug target/112864] [14 regression] Many libphobos tests FAIL on macOS 12+

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864 --- Comment #3 from Iain Sandoe --- I suppose we are going to have to consider back porting this, if we want to avoid the same problems on open branches.

[Bug middle-end/113750] New: [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750 Bug ID: 113750 Summary: [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid

[Bug middle-end/113750] [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750 --- Comment #1 from Iain Sandoe --- .. (gdb) p debug_tree(current_function_decl) > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xf5b5d008 arg-types

[Bug middle-end/113750] [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750 --- Comment #3 from Iain Sandoe --- Created attachment 57317 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57317&action=edit gimple for 179t.ifcvt the label seems OK here.

[Bug middle-end/113750] [14 Regression] ICE in vect building gcc/m2/gm2-libs/NumberIO.mod

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750 --- Comment #4 from Iain Sandoe --- Created attachment 57318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57318&action=edit gimple for 179t.vect now there's a mem at the start of bb3 with the label following

[Bug target/113763] New: [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 Bug ID: 113763 Summary: [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr. Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #1 from Iain Sandoe --- I suppose the trivial fix is s/constexpr/const/ (but maybe there's something more elegant). If we agree that this is c++14 - only, then maybe we should have a separate bug that we accept this for c++11.

[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #8 from Iain Sandoe --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jakub Jelinek from comment #6) > > Jon, what about Iain's question whether it isn't a bug we use constexpr on > > the ctor even in C++11 mode? > > D

[Bug d/113772] New: [14 Regression] atomic.d compile error since recent upstream imports.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Bug ID: 113772 Summary: [14 Regression] atomic.d compile error since recent upstream imports. Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: build

[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 Target Milestone|--- |14.0

[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 the

[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" > > --- > /

[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_

[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|

[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 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|

[Bug c++/115434] New: Post contracts are ignored on functions with no return statement.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434 Bug ID: 115434 Summary: Post contracts are ignored on functions with no return statement. Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug c++/115434] Post contracts are ignored on functions with no return statement.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434 --- Comment #1 from Iain Sandoe --- note that the example uses the new syntax, but the issue applies equally to the attribute syntax in trunk.

[Bug debug/108917] ICE when specifying optimization level and debuging for C++ contracts code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108917 --- Comment #4 from Iain Sandoe --- I think the problem here is related to the setting of DECL_ABSTRACT_ORIGIN on the contract checking functions. " DECL_ABSTRACT_ORIGIN, if non-NULL, points to the original (abstract) ..._DECL node of wh

[Bug c++/115434] Post contracts are ignored on functions with no return statement.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 URL|

[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug c++/110872] coroutine postcondition is not evaluated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872 Iain Sandoe changed: What|Removed |Added URL||https://gcc.gnu.org/piperma

[Bug c++/102454] coroutines: ICE in gimplify_var_or_parm_decl, at gimplify.c:2958

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102454 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #30 from Iain Sandoe --- blocks have support from 10.6 [Apple gcc-4.2] (although there is/was 'after market' support for 10.5). you should be able to find plenty of examples in the Apple Developer doc. This is now becoming more of a

[Bug c++/99710] coroutines: co_yield and co_await should only be allowed in suspension context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99710 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/100772] Templated coroutine new function's arguments have incorrect value categories/overload selection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100772 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug c++/101765] ICE when using a VLA inside of a coroutine

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug c++/16994] [meta-bug] VLA and C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 101765, which changed state. Bug 101765 Summary: ICE when using a VLA inside of a coroutine https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765 What|Removed |Added --

[Bug c++/104051] [coroutines] ICE: tree check: expected target_expr, have call_expr in coro_diagnose_throwing_final_aw_expr, at cp/coroutines.cc:880 since r11-7528-g9ee91079fd5879cb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104051 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

<    5   6   7   8   9   10   11   12   13   >