[Bug libstdc++/102259] ifstream::read(…, count) fails when count >= 2^31 on darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259 --- Comment #9 from Iain Sandoe --- (In reply to Jonathan Wakely from comment #8) > Patch posted: > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671057.html > > It would be great if somebody could test this on macOS and/or FreeBSD to

[Bug target/113257] -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra

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

[Bug target/80782] Configure options to use llvm/clang assembler on Mac

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80782 --- Comment #18 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #17) > (In reply to Iain Sandoe from comment #16) > > Why not use `llas` (which only needs LLVM) instead of `clang` (which needs > LLVM + clang)? > I have seen in some

[Bug target/80782] Configure options to use llvm/clang assembler on Mac

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80782 --- Comment #20 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #19) > (In reply to Iain Sandoe from comment #18) > > (In reply to Sergey Fedorov from comment #17) > > > (In reply to Iain Sandoe from comment #16) > > > > > > Why no

[Bug c++/118673] [14 regression] LLVM's libMLIR miscompiled since r14-1705-g2764335bd336f2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118673 --- Comment #20 from Iain Sandoe --- (In reply to Jason Merrill from comment #19) > (In reply to Jason Merrill from comment #18) > > (In reply to Iain Sandoe from comment #16) > > > + if ((TREE_CODE (ref) == CONST_DECL && TREE_STATIC (ref))

[Bug c++/117231] [15 regression] Incorrect code generation for std::generator since r15-3840-g650e9156656187

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231 --- Comment #8 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #7) > The last progress I see is Jason's patch review comments in > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671258.html > Iain, any progress since then?

[Bug c++/117231] [15 regression] Incorrect code generation for std::generator since r15-3840-g650e9156656187

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231 --- Comment #10 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #9) > (In reply to Iain Sandoe from comment #8) > > (In reply to Jakub Jelinek from comment #7) > > > The last progress I see is Jason's patch review comments in > > >

[Bug cobol/119213] gcc/cobol/Make-lang.in: suspicious -DEXEC_LIB with hardcoded lib64

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

[Bug cobol/119283] cobol FE uses memrchr unconditionally.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283 --- Comment #3 from Iain Sandoe --- Created attachment 60770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60770&action=edit Add implementation of memrchr to libiberty This is a trial implementation of adding memrchr to libiberty,

[Bug cobol/119241] cobol Front end uses host floating point (128b) support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241 --- Comment #5 from Iain Sandoe --- In my experiments with x86_64 Darwin and Linux, I have managed to convert the library to use libquadmath. I started to try and apply Jakub's suggestions to the FE for this BZ, since what it is doing at the mo

[Bug cobol/119301] cobol FE uses get_current_dir_name unconditionally

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|iains at gcc dot g

[Bug cobol/119295] cobol, libcobol uses random_r which is GLIBC specific

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295 Iain Sandoe changed: What|Removed |Added Assignee|iains at gcc dot gnu.org |unassigned at gcc dot gnu.org

[Bug cobol/119295] cobol, libcobol uses random_r which is GLIBC specific

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295 --- Comment #1 from Iain Sandoe --- Created attachment 60775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60775&action=edit Patch tested on x86_64 Darwin and Linux Unfortunately, we don't have a fallback on Darwin other than to use the

[Bug cobol/119296] cobol, libgcobol the library uses strfromf* which are C23 and not generally available outside GLIBC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|iains at gcc dot g

[Bug cobol/119213] gcc/cobol/Make-lang.in: suspicious -DEXEC_LIB with hardcoded lib64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213 --- Comment #6 from Iain Sandoe --- Created attachment 60776 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60776&action=edit Patch to remove std= and forced lib paths This removes these from the CPPSPEC in the cobol Make-lang.in and also

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 --- Comment #9 from Iain Sandoe --- Created attachment 60777 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60777&action=edit Initial patch (working on x86_64 darwin and linux) The relationship between the library and the FE remains uncle

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|iains at gcc dot g

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 --- Comment #20 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #18) > I think s390x-linux is similar to aarch64-linux here, neither has > libquadmath support. However, libquadmath works fine on aarch64-darwin, so it is a possible

[Bug target/119308] Cobol ICE on "hello world" on POWER in rs6000_output_function_epilogue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org Ever confirm

[Bug libitm/88319] all-target and all-target-libitm build targets fail for libitm.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88319 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last rec

[Bug target/116827] New C++ failures in macOS 15

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org

[Bug target/119435] Darwin: constructor priorities are not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119435 --- Comment #3 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #2) > (In reply to Iain Sandoe from comment #1) > > I am actually surprised we don't have an enhancement bug for this. > > > > The reason we do not have this is becaus

[Bug libitm/88319] all-target and all-target-libitm build targets fail for libitm.

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

[Bug target/119435] Darwin: constructor priorities are not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119435 Iain Sandoe changed: What|Removed |Added Severity|normal |enhancement Target|powerpc-ap

[Bug cobol/119414] New: cobol driver unconditionally adds platform-specific command line options.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 Bug ID: 119414 Summary: cobol driver unconditionally adds platform-specific command line options. Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: norm

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 --- Comment #16 from Iain Sandoe --- (In reply to Michael Duggan from comment #15) > Would it be possible for one of these to make it into version 15? I'd prefer the change that teaches gcov about coroutines, I fear the change to the status of

[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)

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

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 --- Comment #18 from Iain Sandoe --- (In reply to Michael Duggan from comment #17) > Gcov doesn't have access to the function declaration, only to the > information that has been output to the count and graph files. Neither of > those contain a

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 --- Comment #20 from Iain Sandoe --- (In reply to Michael Duggan from comment #19) > I submitted a patch. Yes a saw that - thanks, it does need other people to review it though, > I also recently thought of another potential solution. > We co

[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.

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

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 Iain Sandoe changed: What|Removed |Added Attachment #60777|0 |1 is obsolete|

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 --- Comment #25 from Iain Sandoe --- (In reply to Iain Sandoe from comment #24) > Created attachment 60792 [details] > v2 patch with support for long double and literal suffix wrapping. > > This tries to pick up Jakub's suggestion as to how to

[Bug target/119172] [12/13/14 regression] macOS SDK version is not set by gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119172 Iain Sandoe changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Iain Sando

[Bug cobol/119241] cobol Front end uses host floating point (128b) support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241 --- Comment #7 from Iain Sandoe --- (In reply to Robert Dubner from comment #6) > (In reply to Iain Sandoe from comment #5) > > In my experiments with x86_64 Darwin and Linux, I have managed to convert > > the library to use libquadmath. > > >

[Bug cobol/119296] cobol, libgcobol the library uses strfromf* which are C23 and not generally available outside GLIBC

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

[Bug cobol/119296] New: cobol, libgcobol the library uses strfromf* which are C23 and not generally available outside GLIBC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296 Bug ID: 119296 Summary: cobol, libgcobol the library uses strfromf* which are C23 and not generally available outside GLIBC Product: gcc Version: 15.0 Status: UNCONFIRME

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

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

[Bug cobol/119283] cobol FE uses memrchr unconditionally.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283 --- Comment #2 from Iain Sandoe --- (In reply to Richard Biener from comment #1) > I wonder if it could just use strrchr as fallback? IDK if cobol strings are always null-terminated?

[Bug cobol/119295] cobol, libcobol uses random_r which is GLIBC specific

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

[Bug cobol/119295] New: cobol, libcobol uses random_r which is GLIBC specific

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295 Bug ID: 119295 Summary: cobol, libcobol uses random_r which is GLIBC specific Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: build Severity: normal P

[Bug cobol/119301] cobol FE uses get_current_dir_name unconditionally

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

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 --- Comment #23 from Iain Sandoe --- (In reply to Richard Biener from comment #21) > (In reply to Richard Biener from comment #19) > > I'll cook up a preliminary patch for the Q vs. f128 change. > > Note it seems libgfortran LIBGFOR_CHECK_FLOAT

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 --- Comment #12 from Iain Sandoe --- (In reply to Richard Biener from comment #11) > I'll note this also affects s390x-linux where libgcobol currently fails to > build due to > > ../../../gcc/libgcobol/intrinsic.cc:984:3: error: unsupported non

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 --- Comment #15 from Iain Sandoe --- (In reply to Richard Biener from comment #14) > (In reply to Iain Sandoe from comment #12) > > (In reply to Richard Biener from comment #11) > > > I'll note this also affects s390x-linux where libgcobol curre

[Bug cobol/119213] gcc/cobol/Make-lang.in: suspicious -DEXEC_LIB with hardcoded lib64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119213 --- Comment #10 from Iain Sandoe --- In my patches for Darwin/macOS - I did it in a more long-winded way by removing the CPPFLAGS def completely and then adding: +CFLAGS-cobol/cobol1.o += -I$(LIB_SOURCE) +CFLAGS-cobol/genutil.o += -I$(LIB_SOU

[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error

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

[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error

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

[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.

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

[Bug cobol/119595] Port libgcobol to 32-bit architectures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119595 --- Comment #5 from Iain Sandoe --- Very encouraging I put this patch (with obvious amendments) on top of my posted patches for libquadmath support - and then adjusted the sorry in cobol1 (so that it only required float128). x86_64-darwin1

[Bug cobol/119283] cobol FE uses memrchr unconditionally.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED URL|

[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 #34 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #33) > (In reply to Eric Gallager from comment #31) > This does not help us much though, unfortunately, since that support appears > rudimentary and, importantly, won

[Bug target/119691] gcc does not build for powerpc64-apple-darwin9: ld: bl out of range (-16845644 max is +/-16M) from __ZN10hash_tableI19default_hash_traitsIP11cgraph_edgeELb0E11xcallocatorED1Ev at 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691 --- Comment #5 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #4) > (In reply to Iain Sandoe from comment #2) > > it's always been broken, unfortunately (for a start, it gets the range > > wrong) > > At that stage, there were not

[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 --- Comment #17 from Iain Sandoe --- (In reply to Robert Dubner from comment #16) > Mainframe programmers sometimes think differently, I believe. > > If my understanding from discussions with an old-school mainframe programmer > -- who admitted

[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 --- Comment #15 from Iain Sandoe --- (In reply to rdubner from comment #14) > > -Original Message- > > From: iains at gcc dot gnu.org > > Sent: Wednesday, April 9, 2025 11:19 > > To: rdub...@gcc.gnu.org > > Subject: [Bug cobol/119414] c

[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 --- Comment #12 from Iain Sandoe --- (In reply to rdubner from comment #11) > COBOL comes from long ago, and far away. And the vast bulk of code that I > never forget is where my boss, paying my salary, hopes to someday actually > make some m

[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 --- Comment #8 from Iain Sandoe --- (In reply to Robert Dubner from comment #7) > The commit has the comment, "...the options had been added during development > to handle specific cases, they are no longer needed..." > That turns out not t

[Bug target/119691] gcc does not build for powerpc64-apple-darwin9: ld: bl out of range (-16845644 max is +/-16M) from __ZN10hash_tableI19default_hash_traitsIP11cgraph_edgeELb0E11xcallocatorED1Ev at 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119691 --- Comment #2 from Iain Sandoe --- (In reply to Peter Bergner from comment #1) > (In reply to Sergey Fedorov from comment #0) > > :info:build ld: bl out of range (-16839456 max is +/-16M) from > > __ZN10hash_tableI19default_hash_traitsIP11cgrap

[Bug cobol/119283] New: cobol FE uses memrchr unconditionally.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283 Bug ID: 119283 Summary: cobol FE uses memrchr unconditionally. Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3

[Bug cobol/119283] cobol FE uses memrchr unconditionally.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2025-03-14 Status|UNCONFIRMED

[Bug cobol/119301] cobol FE uses get_current_dir_name unconditionally

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 --- Comment #26 from Iain Sandoe --- Also .. I'm a bit fuzzy still about the absolute requirements. Is there any specific reason (apart from "people don't like it") that this would not work with native __ibm128 long double? granted, at present

[Bug cobol/119301] New: cobol FE uses get_current_dir_name unconditionally

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301 Bug ID: 119301 Summary: cobol FE uses get_current_dir_name unconditionally Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: build Severity: normal Prio

[Bug cobol/119301] cobol FE uses get_current_dir_name unconditionally

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301 --- Comment #4 from Iain Sandoe --- (In reply to Andrew Pinski from comment #1) > https://www.gnu.org/software/libc/manual/html_node/Working-Directory.html > > Describes how get_current_dir_name could be implemented. > > Since this is in the f

[Bug cobol/119301] cobol FE uses get_current_dir_name unconditionally

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119301 --- Comment #3 from Iain Sandoe --- Created attachment 60764 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60764&action=edit patch under test this works on Darwin... but not tested more widely yet/

[Bug other/119218] libiberty configure test fails for basename on targets which declare it in .

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119218 Iain Sandoe changed: What|Removed |Added Attachment #60727|0 |1 is obsolete|

[Bug other/119250] GCC configure fails to find the declaration of basename() on hosts that need

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119250 --- Comment #7 from Iain Sandoe --- Created attachment 60766 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60766&action=edit patch under test This makes the configure test for basename use the same process as in libiberty so that the res

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 --- Comment #28 from Iain Sandoe --- did not succeed in testing on powerpc64le (it built OK, but the testsuite does not run because of PR119308)

[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 Iain Sandoe changed: What|Removed |Added Attachment #60792|0 |1 is obsolete|

[Bug target/115880] [13/14/15 regression] GCC 14+ fails to parse CoreFoundation header

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880 --- Comment #7 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #6) > (In reply to Iain Sandoe from comment #2) > > I have posted patches (which need an update [on my shorter TODO] that > > implement the availability attribute). Th

[Bug target/93082] macOS Authorization.h needs fixinclude

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 Iain Sandoe changed: What|Removed |Added Attachment #61030|0 |1 is obsolete|

[Bug cobol/119524] cobol: gg_printf assumes target characteristics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119524 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2025-04-11 Ever confirmed|0

[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug target/93082] macOS Authorization.h needs fixinclude

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #16 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #15) > This still does not work with gcc-14.2.0. > > ``` > :info:build In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/

[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Iain Sandoe changed: What|Removed |Added Assignee|iains at gcc dot gnu.org |unassigned at gcc dot gnu.org ---

[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #13 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #12) > (In reply to Jonathan Wakely from comment #10) > > The same error happens even without the macro in question being passed, at > least explicitly. Getting it wit

[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org

[Bug libstdc++/119647] cstdlib: error: 'aligned_alloc' has not been declared in '::'; ctime: error: 'timespec_get' has not been declared in '::'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119647 --- Comment #5 from Iain Sandoe --- this seems odd, ICU is a system component - so presumably the version released on Apple's Open Source repo should be buildable by the system. What version of ICU are you trying to build (and where from)? It

[Bug target/93082] macOS Authorization.h needs fixinclude

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 Iain Sandoe changed: What|Removed |Added Attachment #52980|0 |1 is obsolete|

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15 since r15-3153-g68ee624bc52ba1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 --- Comment #12 from Iain Sandoe --- noting the CWG issue, this is a tricky area since [current] tests might be expecting either the existing clang/MSVC (and previous GCC) behaviour - or the revised GCC behaviour. What seems clear to me is that

[Bug other/105404] Update in-tree copy of zlib to zlib-1.3.1

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

[Bug c++/113773] coroutines: promise deconstructed twice if throwing from return object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773 Iain Sandoe changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #5 from Iain Sandoe

[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|WAITING |RESOLVED Resolution|---

[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 Resolution|--- |FIXED Status|NEW

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

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

[Bug c++/105475] coroutines: ICE in coerce_template_parms, at cp/pt.cc:9183

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475 Iain Sandoe changed: What|Removed |Added Status|WAITING |RESOLVED Target Milestone|---

[Bug c++/98935] [coroutines] co_await on statement expressions causes ICE

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

[Bug c++/115905] [coroutines] Wrong behavior of await_suspend()

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

[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns

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

[Bug c++/100476] coroutines: questionable handling of void get_return_object

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

[Bug c++/109682] coroutines: ICE in morph_fn_to_coro on wrong return type for get_return_object_on_allocation_failure

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

[Bug c++/102051] [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848

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

[Bug c++/110635] Segmentation fault when the awaiter's await_resume in initial-suspend returns a class type.

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

[Bug c++/113457] Nesting coroutine definitions (e.g. via a lambda or a template expansion) can ICE the compiler

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

[Bug c++/106973] coroutine generator and setjmp

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

[Bug target/116827] New C++ failures in macOS 15

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #10 from Iain Sandoe --- fixed on trunk, backports to follow.

[Bug c++/111075] [13/14/15 Regression] ICE on g++.dg/torture/tail-padding1.C on darwin since r13-6145-gb2287a4d9a640fdc2caef6a067830ea65044deb7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075 --- Comment #12 from Iain Sandoe --- (In reply to Jason Merrill from comment #11) > Created attachment 61123 [details] > fix > > This seems like an appropriate fix, can someone test it on an affected > target? A spot-check on x86_64 darwin21 s

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15 since r15-3153-g68ee624bc52ba1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 --- Comment #13 from Iain Sandoe --- [IMO] I would suggest that GCC's behaviour (now) is the correct one [intended by the design]. Consider a request such as made by Ville "I want the ramp return object to be able to tell me if the coroutine

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15 since r15-3153-g68ee624bc52ba1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 --- Comment #15 from Iain Sandoe --- hmm .. EWG does seem to iterate at times ... maybe I can reach out to Lewis for the example (and to ask him how Ville's request is intended to be handled). This got discussed in some depth during the work on

[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15 since r15-3153-g68ee624bc52ba1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 --- Comment #17 from Iain Sandoe --- (In reply to Jason Merrill from comment #16) > (In reply to Iain Sandoe from comment #15) > > hmm .. EWG does seem to iterate at times ... maybe I can reach out to Lewis > > for the example (and to ask him ho

[Bug c++/118874] [15 regression] ICE in copy_rtx, at rtl.cc:372

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118874 --- Comment #22 from Iain Sandoe --- Given that Rainer reports that this is a regression from GCC-10, I was looking into back porting it for GCC-14.3. However, it does not seem that either the pr115905 or the test case here fail with current re

<    7   8   9   10   11   12   13   >