[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452 --- Comment #5 from Iain Sandoe --- (In reply to David Ledger from comment #4) > @Iain Sandoe > In terms of the standard do you think this is technically undefined > behaviour? no, AFAICT, it's just a regular bug in the implementation. (it's jus

[Bug c++/95519] [coroutines] non-functions for promise_type::return_void not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519 --- Comment #10 from Iain Sandoe --- (In reply to H.J. Lu from comment #9) > On AVX or AVX512 machines, I got (I test on AVX and AVX512 machines without seeing this) What version of glibc do you have? this might be a dup of PR96504 (r11-1673 i

[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504 --- Comment #5 from Iain Sandoe --- (In reply to H.J. Lu from comment #4) > __builtin_coro_resume and __builtin_coro_destroy delete the memory. > Everything goes downhill after it. thanks for the analysis - I will hopefully take a look later.

[Bug tree-optimization/97666] New: [11 Regression] bootstrap fail for powerpc-darwin while building libgfortran after r11-4485

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97666 Bug ID: 97666 Summary: [11 Regression] bootstrap fail for powerpc-darwin while building libgfortran after r11-4485 Product: gcc Version: 11.0 Status: UNCONFIRMED

[Bug tree-optimization/97666] [11 Regression] bootstrap fail for powerpc-darwin while building libgfortran after r11-4485

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97666 Iain Sandoe changed: What|Removed |Added Keywords||ice-on-valid-code Target|

[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 #12 from Iain Sandoe --- (In reply to Fabian Groffen from comment #11) > Is there a patch or WIP somewhere I can try out or attempt to bring forwards? I need to bring forward my patches to the latest master, will post a link here whe

[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 --- Comment #5 from Iain Sandoe --- I added xfail-if for powerpc-darwin (8,9, 10 and 11). https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/336720.html Since i don't think I will have time this cycle to implement it (there are much more press

[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 #15 from Iain Sandoe --- (In reply to Fabian Groffen from comment #14) > (In reply to Eric Gallager from comment #13) > > If we could get in touch with an actual lawyer to review which laws > > specifically are getting in the way here

[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 --- Comment #6 from Iain Sandoe --- (In reply to Iain Sandoe from comment #5) > I added xfail-if for powerpc-darwin (8,9, 10 and 11). > > https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/336720.html > > Since i don't think I will have time t

[Bug tree-optimization/97757] New: [11 Regression] fortran save_6.f90 fails with a segv for -flto -O >= 2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97757 Bug ID: 97757 Summary: [11 Regression] fortran save_6.f90 fails with a segv for -flto -O >= 2 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/97757] [11 Regression] fortran save_6.f90 fails with a segv for -flto -O >= 2

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

[Bug objc/77404] Add Wobjc-root-class

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

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #37 from Iain Sandoe --- (In reply to Avi Kivity from comment #36) > A reminder that coroutines are crippled without this fixed, as it is > standard practice these days to use sanitizers. Although I have taken the PR, please don't le

[Bug objc/77404] Add Wobjc-root-class

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

[Bug objc/77404] Add Wobjc-root-class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77404 --- Comment #9 from Iain Sandoe --- fixed for GCC-11

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 77404, which changed state. Bug 77404 Summary: Add Wobjc-root-class https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77404 What|Removed |Added ---

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

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

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #5 from Iain Sandoe --- I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and have been looking into other issues. Note that the libgfortran directory throws up a lot of warnings when 'autoreconf'ed' so maybe ther

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #7 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #6) > (In reply to Iain Sandoe from comment #5) > > I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and > > have been looking into other issues. > >

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #8 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #4) > (In reply to Iain Sandoe from comment #3) > > I didn't have x86 Big Sur until the weekend - still working through things. > > 1/ > > > > The change you have keeps

[Bug c++/97871] [11 Regression] ICE in cp_parser_declaration, at cp/parser.c:13539

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97871 --- Comment #2 from Iain Sandoe --- (In reply to Marek Polacek from comment #1) > Started with r11-4927. Iain, I think the assert should go: > > --- a/gcc/cp/parser.c > +++ b/gcc/cp/parser.c > @@ -13536,7 +13536,6 @@ cp_parser_declaration (cp_p

[Bug c++/97871] [11 Regression] ICE in cp_parser_declaration, at cp/parser.c:13539

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

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

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

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #11 from Iain Sandoe --- Created attachment 49581 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49581&action=edit regenerated files the second patch is all the regenerated files .. much larger :)

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #13 from Iain Sandoe --- (In reply to jos...@codesourcery.com from comment #12) > config.sub and config.guess are imported, unmodified, from upstream > config.git. thanks I will try to do that and test it over the next days (I've be

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #15 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #14) > If there is a git branch or so, I could also test it on my system with our > code whether this works as expected. Here you go - this is config.{sub, guess}, libt

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #18 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #17) > Iain, as I wrote below your changes seem not sufficient, I will recheck when > I build your branch with gmp/mpfr/mpc built with dynamic_lookup, but it > seems tha

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #19 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #16) > (In reply to Iain Sandoe from comment #15) > > (In reply to Jürgen Reuter from comment #14) > clang: error: argument unused during compilation: '-no-pie' > [-We

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #20 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #16) > (In reply to Iain Sandoe from comment #15) > > (In reply to Jürgen Reuter from comment #14) > - #if defined( AIX_PHYSADR_T_CHECK ) > - typedef struct __physadr_

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #21 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #16) > (In reply to Iain Sandoe from comment #15) > > (In reply to Jürgen Reuter from comment #14) > (4) I checked that on my system there is an older version of libasa

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #22 from Iain Sandoe --- (In reply to Iain Sandoe from comment #19) > (In reply to Jürgen Reuter from comment #16) > > (In reply to Iain Sandoe from comment #15) > > > (In reply to Jürgen Reuter from comment #14) > > > > clang: erro

[Bug fortran/97864] Homebrew Operator Overload ICE

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

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #24 from Iain Sandoe --- (In reply to Iain Sandoe from comment #22) > (In reply to Iain Sandoe from comment #19) > > (In reply to Jürgen Reuter from comment #16) > > > (In reply to Iain Sandoe from comment #15) > > > > (In reply to Jü

[Bug fortran/97864] Homebrew Operator Overload ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864 --- Comment #7 from Iain Sandoe --- (In reply to Brad Richardson from comment #6) > I recently updated to Big Sur, and have xcode version 12.2, but this > initially occurred on Catalina. I don't know exactly which version of xcode > was installed

[Bug fortran/97864] Homebrew Operator Overload ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864 --- Comment #9 from Iain Sandoe --- I would not expect anything to have changed with 10.2 (it's a released version) unless Homebrew were to back port something. Are you able to test with 'master' (i.e. the development version for GCC-11)?

[Bug fortran/97864] Homebrew Operator Overload ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864 --- Comment #11 from Iain Sandoe --- do you see this on mainline too? (I do not - but building a 10.x debug compiler at present) -- the trick will be to figure out what fortran patch(es) have apparently fixed this on mainline. There doesn't see

[Bug fortran/97864] Homebrew Operator Overload ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97864 --- Comment #14 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #13) > And the backtrace is identical, too. It's a duplicated of > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768 OK - so I imagine Jakub will back port w

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |8.5 --- Comment #25 from Iain Sandoe ---

[Bug fortran/97864] Homebrew Operator Overload ICE

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

[Bug d/98058] libphobos: Support building on *-*-darwin*

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

[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-11-30 CC|

[Bug d/98067] [11 Regression] d: ICE in in force_decl_die, at dwarf2out.c:26197 with -gdwarf-2 -gstrict-dwarf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98067 --- Comment #6 from Iain Sandoe --- although this was discovered on Darwin, I guess any platform supporting D could be invoked with -gdwarf-2 and that ought not to ICE. I suppose we could adjust configury to decline building D without DWARF >= 3

[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452 --- Comment #7 from Iain Sandoe --- (In reply to David Ledger from comment #6) > Is this the right place for me to track this bug? yes - it's just waiting for someone to have time to address it.

[Bug target/97865] libtool needs to be updated for Darwin20.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #27 from Iain Sandoe --- tomorrow if there are no further comments (the patch needs minor typographical changes). I'm also testing back-ports for the open branches, and will publish Darwin-specific branches at least for gcc-7.5 (and

[Bug ipa/97757] [11 Regression] fortran save_6.f90 fails with a segv for -flto -O >= 2

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

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968 --- Comment #7 from Iain Sandoe --- (In reply to Andrea Corallo from comment #6) > I believe f5e73de00e9c853ce65333efada7409b0d00f758 should have fixed > this. > > Okay to close? unfortunately, I've not been able to test since you applied this

[Bug libbacktrace/97082] new test 'mtest' fails for Mach-O/Darwin.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97082 --- Comment #3 from Iain Sandoe --- (In reply to Ian Lance Taylor from comment #2) > Does btest pass? It's hard to see why mtest would fail if btest passes. current results [darwin16, darwin19] are: PASS: allocfail.sh PASS: test_elf_32 PASS: t

[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c

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

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968 --- Comment #9 from Iain Sandoe --- (In reply to Andrea Corallo from comment #8) > "iains at gcc dot gnu.org via Gcc-bugs" writes: > [...] > > unfortunately, I've not been able to test since you applied this - curren

[Bug bootstrap/92719] MacOS 10.15 Catalina build fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92719 --- Comment #4 from Iain Sandoe --- (In reply to Nikhil Benesch from comment #3) > For posterity, I could reproduce this issue even with the suggested > `./configure` arguments, i.e., excluding the `--enable-multilib` option. > I worked around t

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 Iain Sandoe changed: What|Removed |Added Last reconfirmed|2020-12-21 00:00:00 |2021-1-7 Target|powerpc64-linu

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #4 from Iain Sandoe --- (In reply to Patrick Palka from comment #3) > Candidate patch: > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563000.html thanks! On Darwin, the test case now builds (checked on a 32b host [powerpc]

[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()

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

[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504 --- Comment #10 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #9) > Are you going to fix co-ret-17-void-ret-coro.C too? should be done with https://gcc.gnu.org/pipermail/gcc-cvs/2021-January/340327.html (as far as I am aware, ha

[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #4 from Iain Sandoe --- (In reply to Nathan Sidwell from comment #3) > Oh, I see what you mean. > > FWIW this is the tip of a deceptively simple, but actually complex, iceberg. [for Darwin] These tests were working on the modules br

[Bug c++/98805] exception abort on mac os 11 (big sur)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 --- Comment #2 from Iain Sandoe --- Hi Hana .. There are some changes needed on the 10.x branch to cater for macOS 11. Trying to ensure that we get them in before 10.3 is released. In the meantime, I'll discuss with the home-brew folks about o

[Bug c++/98805] exception abort on mac os 11 (big sur)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 --- Comment #6 from Iain Sandoe --- thanks FX.. That single patch is definitely "necessary, but not sufficient". .. AFAIK, the critical patches have been already applied to the 10.x branch (there were several) - but I'll run a check on macOS 11

[Bug c++/98805] exception abort on mac os 11 (big sur)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|---

[Bug c++/98821] New: modules : c++tools configures with CC but code fragments assume CXX.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98821 Bug ID: 98821 Summary: modules : c++tools configures with CC but code fragments assume CXX. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug c++/98944] New: [modules] Failed to read compiled module with a non-exported partition.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98944 Bug ID: 98944 Summary: [modules] Failed to read compiled module with a non-exported partition. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #40 from Iain Sandoe --- (In reply to niek from comment #39) > I just tested this on the nightly build of GCC 11. Unfortunately, the issue > is still there... > > @Richard Biener > Would it be a good idea to attach this bug's target

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 Iain Sandoe changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org,

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #6 from Iain Sandoe --- (In reply to ktkachov from comment #5) > I do think it's one of those LLVM assembler issues. > Maybe it's due to the fact that "prfmPLDL1KEEP, [x0, -8]" > is just the alias to the: > prfum pldl1keep, [x0,

[Bug c++/95615] [coroutines] Coroutine frame and promise is leaked if exception thrown from promise.initial_suspend()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95615 --- Comment #3 from Iain Sandoe --- Actually, I don't think the example goes far enough. ISTM, [on exception in the places noted] that non-trivial DTORs for frame copies of parms should be run after the GRO and promise DTOR but before the frame

[Bug c++/96251] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 --- Comment #4 from Iain Sandoe --- So, as noted, the problem is being caused because the coroutine is being regarded as potentially constexpr while still type-dependent, and then failing during template expansion. All the coroutine expressions

[Bug c++/98976] [coroutines] co_return in a switch statement doesn't make a generic lambda non-constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98976 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-2-16 See Also|

[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #13 from Iain Sandoe --- fixed for Darwin.

[Bug c++/97587] [coroutines] promise_type constructor is called with original parameters, not parameter copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97587 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-02-16 Status|UNCONFIRMED

[Bug c++/95615] [coroutines] Coroutine frame and promise is leaked if exception thrown from promise.initial_suspend()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95615 --- Comment #4 from Iain Sandoe --- Created attachment 50195 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50195&action=edit Patch for testing This implements the change including cleanup of parm copies with non-trivial DTORs as mentioned

[Bug c++/95822] [coroutines] compiler internal error with local object with noexcept false destructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95822 --- Comment #3 from Iain Sandoe --- Created attachment 50196 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50196&action=edit Patch for testing this needs some wider testing.

[Bug c++/95616] [coroutines] coroutines with potentially-throwing 'co_await promise.final_suspend()' expressions should be ill-formed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95616 --- Comment #3 from Iain Sandoe --- Created attachment 50197 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50197&action=edit Patch being tested this fixes the top-level check, but doesn't yet look at (a) operator co_await (b) the await_*

[Bug c++/98976] [constexpr, coroutines] co_return in a switch statement doesn't make a generic lambda non-constexpr

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

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 Iain Sandoe changed: What|Removed |Added CC||mail+gnu at tzik dot jp --- Comment #5 fro

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

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

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #8 from Iain Sandoe --- it seems that GAS is accepting an encoding that's not specified in at least version DDI0487Fc_armv8_arm. that says that C6.2.212 PRFM (immediate) takes " Is the optional positive immediate byte offset, a mu

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #11 from Iain Sandoe --- (In reply to Andrew Pinski from comment #10) > From the ARM ARM: > An assembler program translating a Load/Store instruction, for example LDR, > is required to encode an unambiguous offset using the unscaled 9

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

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

[Bug sanitizer/99179] asan failures with -Os on x86_64-apple-darwin20

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

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 --- Comment #7 from Iain Sandoe --- patch posted : https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565649.html

[Bug c++/99215] coroutines: debugging with gdb

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

[Bug c++/99215] coroutines: debugging with gdb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #3 from Iain Sandoe --- (In reply to Nils Gladitz from comment #2) > (In reply to Iain Sandoe from comment #1) > > Can you identify specific key blockers to progress? > > (I think the paper cited contained a number of desiderata, but

[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.3 --- Comment #9 from Iain Sandoe ---

[Bug c++/99215] coroutines: debugging with gdb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #6 from Iain Sandoe --- (In reply to Nils Gladitz from comment #5) > Apparently when the coroutine happens to be a member function (even a static > one) printing *frame_ptr results in "{}". > > Ideally I'd want to have non-static mem

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #17 from Iain Sandoe --- (In reply to Patrick Palka from comment #16) > (In reply to r...@cebitec.uni-bielefeld.de from comment #14) > > > --- Comment #13 from Patrick Palka --- [..] > > Which according to ISO C 2017, p.228, is allo

[Bug objc++/49070] [8/9/10/11 regression] ObjC++ compiler fails to compile ObjC method invocations without keyword arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49070 Iain Sandoe changed: What|Removed |Added Target Milestone|6.4 |8.6 --- Comment #5 from Iain Sandoe --- p

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98979 --- Comment #12 from Iain Sandoe --- the failures are resolved on Darwin too.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384 --- Comment #20 from Iain Sandoe --- still failing on Darwin at r11-7425 - is that expected (i.e. patches pending) or more analysis needed? long_double.cc:83: test01()::)>: Assertion '!strcmp(begin, printf_buffer+strlen("0x"))' failed.

[Bug c++/98432] [coroutine] leaked frame created using await_transform

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 --- Comment #2 from Iain Sandoe --- (In reply to Tomáš Hering from comment #1) > Created attachment 49839 [details] > preprocessed file that triggers the bug please could you attach the un-preprocessed source? I cannot reproduce this with the pr

[Bug bootstrap/100269] New: [12 Regression] i686 biarch compiler fails for Darwin after r12-36.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269 Bug ID: 100269 Summary: [12 Regression] i686 biarch compiler fails for Darwin after r12-36. Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal

[Bug bootstrap/100269] [12 Regression] i686 biarch compiler fails for Darwin after r12-36.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-04-26 Status|UNCONFIRMED

[Bug target/100269] [12 Regression] i686 biarch compiler fails for Darwin after r12-36.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100269 --- Comment #1 from Iain Sandoe --- Created attachment 50705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50705&action=edit patch under test It doesn't seem that the rationale for the changes in r12-35/36 is captured anywhere I could fi

[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183 --- Comment #6 from Iain Sandoe --- (In reply to anlauf from comment #5) > (In reply to Iain Sandoe from comment #4) > > gcc304 is the Apple M1 machine. The GCC support there is highly > > experimental and not in master -- please note that ther

[Bug bootstrap/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #6 from Iain Sandoe --- (In reply to Richard Biener from comment #5) > Does it work when you use STAGE1_CFLAGS="-O0" (I think clang defaults to > optimizing?). To rule out compare-debug issues also try > --without-build-config The

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #7 from Iain Sandoe --- (In reply to Iain Sandoe from comment #6) > (In reply to Richard Biener from comment #5) > > Does it work when you use STAGE1_CFLAGS="-O0" (I think clang defaults to > > optimizing?). To rule out compare-debu

[Bug bootstrap/100373] New: [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 Bug ID: 100373 Summary: [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057 Product: gcc Version: unknown Status: UNCONFIRMED Severity: nor

[Bug bootstrap/100373] [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 Iain Sandoe changed: What|Removed |Added Keywords||build Target|

[Bug bootstrap/100373] [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 --- Comment #1 from Iain Sandoe --- this happens with mpfr-4.x sources and not with mpfr-3.1.6.

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #45 from Iain Sandoe --- the i386 backend code already sets : TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS to true unconditionally. So, it seems that it might be necessary to find some way to adjust CALL_INSN_FUNCTION_USAGE.

[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #46 from Iain Sandoe --- Created attachment 50737 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50737&action=edit trial patch for testing looking at the way other ports handle things like use of registers in veneers etc. it s

[Bug bootstrap/100373] [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 --- Comment #3 from Iain Sandoe --- (In reply to Richard Biener from comment #2) > Doesn't reproduce on x86_64-linux with bootstrapping with in-tree mpfr 4.1.0 it might well be some corner-case, but Darwin is PIC by default, so it might be wort

<    1   2   3   4   5   6   7   8   9   10   >