[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 --- Comment #4 from Iain Sandoe --- (In reply to Tomáš Hering from comment #3) > Created attachment 50276 [details] > unprocessed source thanks! but ... (on x86_64-linux-gnu and x86_64-darwin16): $ gcc-10-2/bin/g++ -std=c++20 -fcoroutines pr98432.C -o t -O3 -Wall -Wextra $ ./t allocated frames 1 allocated frames 2 allocated frames 3 allocated frames: 2 allocated frames: 1 hello coro-world allocated frames: 0 === same on 10.x and master. [ I will try on some older platforms, and on a 32b host too, later ]. So I'm still a bit stuck - given that coroutines is pretty much a Front End code base, it seems odd that there would be some platform dependence here (I guess there could be a an allocation/deallocation bug). Maybe we could try to find some difference in the initial gimple [-fdump-tree-gimple].
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 --- Comment #6 from Iain Sandoe --- (In reply to Tomáš Hering from comment #5) > Created attachment 50278 [details] > unprocessed original source > > Oops, seems I uploaded a slightly different code. I apologize. It's strange > you can't reproduce the issue, though. Please see the demo with the original > code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with > my local output. Please note that the behavior now seems correct when > setting the trunk version of gcc there. Perhaps it has been fixed in some > recent commit. >From my tests, it is fixed on 10.x and master - (In reply to Tomáš Hering from comment #5) > Created attachment 50278 [details] > unprocessed original source > > Oops, seems I uploaded a slightly different code. I apologize. It's strange > you can't reproduce the issue, though. Please see the demo with the original > code on godbolt (https://godbolt.org/z/Gao919) which is in accordance with > my local output. Please note that the behavior now seems correct when > setting the trunk version of gcc there. Perhaps it has been fixed in some > recent commit. So, even with the original code copied from Compiler Explorer, from my tests, this is fixed on 10.x and master, therefore I think we can close it here (unless you want to make a build of the 10.x branch on your platform to double-check).
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 --- Comment #8 from Iain Sandoe --- (In reply to Tomáš Hering from comment #7) > I'm a bit lost, which github branch corresponds to 10.x that you mention, > please? gcc.gnu.org/git/gcc branch : releases/gcc-10 (currently 10.2.1 - which will become 10.3 at the next release)
[Bug c++/98432] [coroutine] leaked frame created using await_transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432 --- Comment #9 from Iain Sandoe --- (In reply to Iain Sandoe from comment #8) > (In reply to Tomáš Hering from comment #7) > > I'm a bit lost, which github branch corresponds to 10.x that you mention, > > please? > > gcc.gnu.org/git/gcc > > branch : releases/gcc-10 > > (currently 10.2.1 - which will become 10.3 at the next release) https://github.com/gcc-mirror/gcc/tree/releases/gcc-10 (if you're using that)
[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 Iain Sandoe changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||iains at gcc dot gnu.org --- Comment #11 from Iain Sandoe --- As Dominique says, Darwin defaults to PIC so this works "out of the tin" - but that's not relevant to Linux cases reported here so it seems that what's requested is the shared libgfortran (which is PIC and available) a convenience library with non-PIC code (libgfortran.a) so that the status quo is not broken. a convenience library that has PIC code (e.g. libgfortran_pic.a) and some way to instruct the driver to use that in linking. This would allow a shared lib to be built statically linking libgfortran_pic.a [the same would need to be done of libquadmath and any other dept]. === A work-around might be to package the shared libgfortran.so with your application and make use of rpath to point to it (so that the end-user does not need to install GCC to use the app).
[Bug c++/96749] [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2021-03-04 Target Milestone|--- |10.3 --- Comment #3 from Iain Sandoe --- thanks for the report
[Bug gcov-profile/99406] [11 regression] MAP_ANONYMOUS undeclared in libgcov.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99406 --- Comment #1 from Iain Sandoe --- (In reply to Rainer Orth from comment #0) > The unconditional use of MAP_ANONYMOUS in libgcov.h broke Mac OS X > 10.7/Darwin 11 > bootstrap: > > In file included from > /vol/gcc/src/hg/master/darwin/libgcc/libgcov-merge.c:26: > /vol/gcc/src/hg/master/darwin/libgcc/libgcov.h: In function 'malloc_mmap': > In file included from > /vol/gcc/src/hg/master/darwin/libgcc/libgcov-merge.c:26: > /vol/gcc/src/hg/master/darwin/libgcc/libgcov.h: In function 'malloc_mmap': > /vol/gcc/src/hg/master/darwin/libgcc/libgcov.h:420:30: error: > 'MAP_ANONYMOUS' undeclared (first use in this function); did you mean > 'MAP_ANON'? > 420 |MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > | ^ > | MAP_ANON > /vol/gcc/src/hg/master/darwin/libgcc/libgcov.h:420:30: note: each undeclared > identifier is reported only once for each function it appears in > > I haven't checked which macOS version introduced MAP_ANONYMOUS as alias for > MAP_ANON, but macOS 11/Darwin 20 has it. I think from darwin15 / macOS 10.11 /opt/iains/SDKs/darwin15/usr/include/sys/mman.h:#define MAP_ANONYMOUS MAP_ANON /opt/iains/SDKs/darwin16/usr/include/sys/mman.h:#define MAP_ANONYMOUS MAP_ANON /opt/iains/SDKs/darwin17/usr/include/sys/mman.h:#define MAP_ANONYMOUS MAP_ANON /opt/iains/SDKs/darwin18/usr/include/sys/mman.h:#define MAP_ANONYMOUS MAP_ANON /opt/iains/SDKs/darwin19/usr/include/sys/mman.h:#define MAP_ANONYMOUS MAP_ANON
[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 --- Comment #5 from Iain Sandoe --- thanks for the reports (I have some idea about where the issue is coming from, but not fixed yet).
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- and we can't skip .a because that's the right suffix for AIX, correct?
[Bug c++/99459] [11 Regression] Many coroutines regressions on armv7hl-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459 --- Comment #5 from Iain Sandoe --- It looks likely. is there a 32b arm box on the cfarm? I don't have access to one locally either (but maybe it will reproduce on a cross...) Both places in the crash logs are dummy = dummy ? TREE_OPERAND (CALL_EXPR_FN (dummy), 0) : NULL_TREE; where dummy is the return tree from a DTOR build, I guess that arm can return something other than NULL_TREE for a failed build_special_member_call()? will try to take a look this evening.
[Bug c++/99459] [11 Regression] Many coroutines regressions on armv7hl-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459 --- Comment #6 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #4) > So perhaps: > 2021-03-08 Jakub Jelinek > > PR c++/99459 > * coroutines.cc (build_co_await): Look through NOP_EXPRs in > build_special_member_call return value to find the CALL_EXPR. > > --- gcc/cp/coroutines.cc.jj 2021-03-05 21:51:48.671185716 +0100 > +++ gcc/cp/coroutines.cc 2021-03-08 10:53:13.187959339 +0100 > @@ -868,6 +868,8 @@ build_co_await (location_t loc, tree a, > = build_special_member_call (a, complete_dtor_identifier, >NULL, a_type, LOOKUP_NORMAL, >tf_none); > + if (dummy && CONVERT_EXPR_P (dummy)) > + dummy = TREE_OPERAND (dummy, 0); > dummy = dummy ? TREE_OPERAND (CALL_EXPR_FN (dummy), 0) > : NULL_TREE; > if (dummy && coro_diagnose_throwing_fn (dummy)) > @@ -1031,6 +1033,8 @@ build_co_await (location_t loc, tree a, > = build_special_member_call (e_proxy, complete_dtor_identifier, >NULL, o_type, LOOKUP_NORMAL, >tf_none); > + if (dummy && CONVERT_EXPR_P (dummy)) > + dummy = TREE_OPERAND (dummy, 0); > dummy = dummy ? TREE_OPERAND (CALL_EXPR_FN (dummy), 0) > : NULL_TREE; > if (dummy && coro_diagnose_throwing_fn (dummy)) > > ? looks reasonable to me - but I have no way to test it at present.
[Bug c++/99459] [11 Regression] Many coroutines regressions on armv7hl-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459 --- Comment #7 from Iain Sandoe --- would STRIP_NOPS() be more general?
[Bug c++/99459] [11 Regression] Many coroutines regressions on armv7hl-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99459 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-03-08 Status|UNCONFIRMED |NEW --- Comment #9 from Iain Sandoe --- I could reproduce this with an arm-linux-gnueabi cross (using a sysroot from a linaro 7.5 distribution). The patch at comment #4 works for me for compile tests. I have no setup to do exec. tests.
[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 #27 from Iain Sandoe --- for Darwin x86 * the test at line 83 fails, and with some more debugging stuff inserted and the abort removed, there are 66 cases where the strings do not agree, so a bug in libc (probably) .. I'm doing seem more tests on a newer system version. for Darwin PPC * the tests don't build currently, because the new symbols need adding to the library exports (patch incoming for that). However, with the symbol fix, there's then a different fail (round-trip) which I have yet to analyse.
[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 #28 from Iain Sandoe --- (In reply to Iain Sandoe from comment #27) > for Darwin x86 > > * the test at line 83 fails, and with some more debugging stuff inserted and > the abort removed, there are 66 cases where the strings do not agree, so a > bug in libc (probably) .. I'm doing seem more tests on a newer system > version. repeated on macOS11 (Darwin20) - the fails are for precisions 1, 5, 9 and 13 (if there's any significance to that) with a pattern that looks like this: begin 9.2p-11003, printf_buffer 0x9.1p-11003 FAILED: prec has value 1 -- begin 9.1a2b4p-11003, printf_buffer 0x9.1a2b3p-11003 FAILED: prec has value 5 -- begin 9.1a2b3c4d6p-11003, printf_buffer 0x9.1a2b3c4d5p-11003 FAILED: prec has value 9 -- begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 FAILED: prec has value 13 -- begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 FAILED: prec has value 13 -- begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003 FAILED: prec has value 13 (and similarly for the other values that fail, not read the code enough yet to figure out why we get the three cases for 13...).
[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 #29 from Iain Sandoe --- it seems that libc++ doesn't have support for long double to_chars yet, so I couldn't do a comparison with the platform libc++. However, I did build the code with clang (but using -stdlib=libstdc++, so the headers and implementation are the same as for GCC) - but OTOH that does rule out code-gen. (same result). .. also checked feget/setround and it seems that the default is correct. So.. most likely this is a libc problem, I guess (and not sure how to report it at the moment, since there's no reproducer for the system compiler).
[Bug c++/98480] [coroutines] ICE on co_await in for-loop end condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98480
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
Last reconfirmed||2021-03-12
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Iain Sandoe ---
Created attachment 50375
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50375&action=edit
Patch under test
I seem to have had a brainstorm when applying the changes needed for do {}
while; and while () {} and omitted the ones for for.
[Bug c++/98704] coroutine_handle::done() == false after promise's unhandled_exception() has thrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98704 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last reconfirmed||2021-03-12 --- Comment #2 from Iain Sandoe --- Created attachment 50376 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50376&action=edit Patch under test Thanks for the report, and suggested fix. This is the subject of CWG 2541 (about the wording, which is potentially misleading). Your possible fix doesn't do quite the right thing (because of said misleading wording, I suspect) - it's necessary to ensure that the destroy() entry does the correct thing when called. === When promise.unhandled_exception () is entered, the coroutine is considered to be still running - returning from the method will cause the final await expression to be evaluated. If the method throws, that action is considered to make the coroutine suspend (since, otherwise, it would be impossible to reclaim its resources, since one cannot destroy a running coro). The wording issue is to do with how to represent the place at which the coroutine should be considered suspended. For the implementation here, that place is immediately before the promise life-time ends. A handler for the rethrown exception, can thus call .destroy() which will run DTORs for the promise and any parameter copies [as needed] then the coroutine frame will be deallocated. At present, we also set "done=true" in this case (for compatibility with other current implementations). One might consider 'done()' to be misleading in the case of an abnormal termination - that is also part of the CGW 2451 discussion. I modified the reproducer into a test case that also checks that the resources are properly cleaned up on an exceptional termination.
[Bug c++/96749] [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Comment #4 from Iain Sandoe ---
Created attachment 50377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50377&action=edit
Patch under test
thanks for the reports.
Even though user code cannot, the compiler can generate things like:
(make some temporary, use that temporary)
So a compound statement that builds a temporary that we then use in the second
part.
When this idiom was encountered, the transforms applied to split await
expressions out were producing something like
{
build temporary
temporary
use the temporary
}
so the middle statement was harmless, but also has no effect (hence the
warning).
the patch under test accounts for this idiom.
[Bug c++/98118] [coroutines] ICE with coroutine with parameter with non-trivial destructor since r10-6876-gdc192bbdd0442f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98118 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.3
[Bug c++/99047] ICE on simple task coroutine example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99047
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2021-03-14
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |10.3
--- Comment #1 from Iain Sandoe ---
(In reply to Mathias Stearn from comment #0)
> https://godbolt.org/z/ecxEbb Code compiles on MSVC and clang, and at least
> on clang produces the expected output.
> std::false_type await_ready() noexcept {
> return {};
> }
This seems to be where the ICE is coming from - the current implementation is
not handling it.
[Bug c++/99047] ICE on simple task coroutine example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99047 --- Comment #2 from Iain Sandoe --- Created attachment 50385 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50385&action=edit Patch under test had omitted the conversion to bool (it seems that almost all coroutines do use a boolean type here).
[Bug c++/99617] gcc/cp/coroutines.cc:2807: member variables not initialised in constructor ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617 --- Comment #2 from Iain Sandoe --- (In reply to Martin Liška from comment #1) > I'm going to handle it. actually, I was already on it .. but if you want to...
[Bug c++/99617] gcc/cp/coroutines.cc:2807: member variables not initialised in constructor ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617 --- Comment #4 from Iain Sandoe --- (In reply to Martin Liška from comment #3) > (In reply to Iain Sandoe from comment #2) > > (In reply to Martin Liška from comment #1) > > > I'm going to handle it. > > > > actually, I was already on it .. but if you want to... > > I have a patch with changelog done. > Do we want it for GCC 11, or in the next stage1? I guess if we consider it to be wrong code, it should be in 11 (and is clearly local to coroutines). otherwise, yeah, next stage 1 (unless I need to touch that area for other open bugs).
[Bug c++/99617] gcc/cp/coroutines.cc:2807: member variables not initialised in constructor ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617 --- Comment #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > (In reply to Martin Liška from comment #3) > > (In reply to Iain Sandoe from comment #2) > > > (In reply to Martin Liška from comment #1) > > I have a patch with changelog done. > > Do we want it for GCC 11, or in the next stage1? > > I guess if we consider it to be wrong code, it should be in 11 (and is > clearly local to coroutines). (but I don't at the moment think that any open bug with wrong code is caused directly by the omission of those initialisers.)
[Bug ipa/99466] internal compiler error: in function_and_variable_visibility, at ipa-visibility.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466 Iain Sandoe changed: What|Removed |Added Last reconfirmed|2021-03-08 00:00:00 |2021-3-16 Status|WAITING |NEW --- Comment #4 from Iain Sandoe --- (In reply to Iain Buclaw from comment #3) > Oldest compiler version have tried it one is 8.4.0, and there's an ICE there > as well. On Darwin16 : ICE back to 5.5, at least (probably, it never worked - I will see if can find a 4.x compiler on an older box) I don't see any specific reason for this to be "waiting" now.
[Bug ipa/99466] internal compiler error: in function_and_variable_visibility, at ipa-visibility.c:795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466 --- Comment #6 from Iain Sandoe --- (In reply to Iain Buclaw from comment #5) > (In reply to Iain Sandoe from comment #4) > > (In reply to Iain Buclaw from comment #3) > > > Oldest compiler version have tried it one is 8.4.0, and there's an ICE > > > there > > > as well. > > > > On Darwin16 : ICE back to 5.5, at least (probably, it never worked - I will > > see if can find a 4.x compiler on an older box) > > > > I don't see any specific reason for this to be "waiting" now. > The system installed compiler (4.2.1) errors with "thread-local storage not > supported for this target", so yes, I think you're right. emuTLS was introduced sometime in 4.x (RTH made the implementation), it did not exist for Apple-4.x, native TLS was introduced in clang for Darwin11 (but we don't have that for GCC, yet - with an open PR for that). for the record the emuTLS test ICEs back to at least 4.6.4 on Darwin9. Given that this is ice-on-valid, IMO we should consider fixing on the open branches.
[Bug sanitizer/99179] asan failures with -Os on x86_64-apple-darwin20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99179 --- Comment #2 from Iain Sandoe --- I did some more checking on this. 1) It seems that something we produce in the unwind info for alloca is not compatible with atos. 2) The objects all pass "dwarfdump --verify" 3) If I run the objects under lldb, breakpoints set by line number seem to work properly. 4) If I use a recent llvm-symbolizer (ASAN_SYMBOLIZER_PATH=) the tests work. 5) the tests also work with clang / libsanitizer. so, perhaps we have some subtle problem with the unwind information we produce with -Os (and when there's an alloca or stack adjustment) - but I don't see this as something I can address for GCC11 (even if it's fixable).
[Bug c++/99617] gcc/cp/coroutines.cc:2807: member variables not initialised in constructor ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617 --- Comment #6 from Iain Sandoe --- given that it blocks something else and that the fix is obvious, trivial and confined to the coroutines implementation - my vote would be to make it. (I do expect to touch that code if I have a chance to fix the remaining coroutines bugs so, if not applied now, then I'll pick it up at that point).
[Bug ada/99641] New: [11 Regression] opt30.adb, opt49.adb and loop_optimization3.adb fail to build at m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99641 Bug ID: 99641 Summary: [11 Regression] opt30.adb, opt49.adb and loop_optimization3.adb fail to build at m32 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- Running target unix/-m32 FAIL: gnat.dg/loop_optimization3.adb (test for excess errors) FAIL: gnat.dg/opt30.adb (test for excess errors) FAIL: gnat.dg/opt49.adb (test for excess errors) this started somewhere between r11-6268 and r11-6339 on Darwin. On Linux the fail is: raised STORAGE_ERROR : stack overflow or erroneous memory access On Darwin: raised CONSTRAINT_ERROR : erroneous memory access
[Bug ada/99641] [11 Regression] opt30.adb, opt49.adb and loop_optimization3.adb fail to build at m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99641 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-03-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target||x86_64-linux-gnu, ||x86_64-apple-darwin CC||ebotcazou at gcc dot gnu.org
[Bug sanitizer/99179] asan failures with -Os on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99179 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin20 |x86_64-apple-darwin Build|x86_64-apple-darwin20 |x86_64-apple-darwin Summary|asan failures with -Os on |asan failures with -Os on |x86_64-apple-darwin20 |x86_64-apple-darwin Target Milestone|--- |12.0 Host|x86_64-apple-darwin20 |x86_64-apple-darwin --- Comment #3 from Iain Sandoe --- for the record this occurs for all Darwin variants that currently support libsanitizer.
[Bug target/99661] Cross compiler cannot be built: powerpc-darwin8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99661 --- Comment #1 from Iain Sandoe --- hmm.. thanks for the report. I built a cross to powerpc-darwin9 yesterday (and a native i686-darwin8) will give this a go later.
[Bug target/99661] Cross compiler cannot be built: powerpc-darwin8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99661 --- Comment #2 from Iain Sandoe --- what was the host/build system in this case?
[Bug target/99661] Cross compiler cannot be built: powerpc-darwin8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99661 --- Comment #3 from Iain Sandoe --- (In reply to Iain Sandoe from comment #2) > what was the host/build system in this case? NM... I just didn't read it. How do you get the SDK and binutils in this case?
[Bug target/99661] Cross compiler cannot be built: powerpc-darwin8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99661 --- Comment #5 from Iain Sandoe --- (In reply to Martin Liška from comment #4) > > > > How do you get the SDK and binutils in this case? > > > > I don't do that. My ambition is to build host compilers, so I run make > all-host. so you're just building cc1 - OK. Looks like I missed a hunk from r11-6417-g4a04f09dc7616ebe76ee71aa50eee54f1115f1f2 will test the obvious fix on an x86_64-darwin x powerpc-darwin8.
[Bug target/99661] Cross compiler cannot be built: powerpc-darwin8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99661
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
Last reconfirmed||2021-03-19
Ever confirmed|0 |1
--- Comment #6 from Iain Sandoe ---
testing
(the headers were obsoleted and removed, I missed this hunk) :
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3ec7582f5dd..9cecc140c83 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2878,7 +2878,6 @@ powerpc-*-darwin*)
*-darwin8*)
tmake_file="${tmake_file} ${cpu_type}/t-darwin32-biarch"
tm_file="${tm_file} ${cpu_type}/darwin32-biarch.h"
- tm_file="${tm_file} ${cpu_type}/darwin8.h"
;;
*-darwin7*)
tm_file="${tm_file} ${cpu_type}/darwin7.h"
[Bug target/99661] Cross compiler cannot be built: powerpc-darwin8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99661 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Iain Sandoe --- thanks for catching this, fixed now.
[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 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Iain Sandoe --- fixed for 10.3 and GCC 11.1
[Bug target/55656] objc/obj-c++ failures present under darwin11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55656 --- Comment #7 from Iain Sandoe --- fixed on master e.g. https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/669584.html
[Bug target/55657] objc/obj-c++ failures present under darwin12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55657 --- Comment #10 from Iain Sandoe --- (In reply to Iain Sandoe from comment #8) > > FAIL: obj-c++.dg/property/at-property-13.mm -fgnu-runtime execution test This is a dyld bug, the objc_setProperty() call should be provided from libobjc-gnu.dylib (that's what the symbol two-level lookup says in the executable). However, dyld is resolving it to objc_setProperty_no_gc from libobjc.A.dylib. So I don't plan to try to address this any further (the test case works for NeXT runtime and for both NeXT and GNU runtimes on other OS versions). The remaining issues are fixed on master e.g. https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/669585.html
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215
--- Comment #8 from Iain Sandoe ---
(In reply to Nils Gladitz from comment #7)
> (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 "{}".
>
> I reported the "{}" issue at the gdb issue tracker:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27556
>
> Managed to create a local workaround from comments made there.
> It was mentioned that gcc itself may be generating improper debug
> information (I think specifically nesting the frame type within a function)
> but as I mentioned over there I myself don't know for sure if this is
> uncommon or actually invalid.
I am not 100% sure about the nesting of the type info
on one hand, the type _is_ local to the function (it's compiler-generated, end
users shouldn't need to look inside it - we are only doing so as a work-around
for missing info)
on the other, I suppose it's also unique to the function and therefore could be
pushed to file scope.
In the end I expect things to work better if we make use of the existing
machinery for decls being represented by some specified expression - then you
would not need to be poking inside the private (compiler-generated) type for
the frame.
In support of improved debug, I'm collecting some local patches - ready for
next stage 1. One thing done already is to change the resume index even if the
suspend is not taken - so that an interrupted coro would have some indication
of which part of the code was active.
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215
--- Comment #9 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Nils Gladitz from comment #7)
> > (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 "{}".
> on the other, I suppose it's also unique to the function and therefore could
> be pushed to file scope.
um, maybe that should be the class scope, for member functions.
[Bug target/55656] objc/obj-c++ failures present under darwin11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55656 --- Comment #9 from Iain Sandoe --- (In reply to Eric Gallager from comment #8) > (In reply to Iain Sandoe from comment #7) > > fixed on master > > e.g. > > https://gcc.gnu.org/pipermail/gcc-testresults/2021-March/669584.html > > So... are we keeping this open for backports, then? yes, most of the fixes are code-gen ones - so I think we need them on at least one branch that can be built with c++98. > If so, to which branches? 10.x .. not sure if it's necessary to go back further (let's see there might be a subset of the changes that are worth doing).
[Bug target/99733] darwin: missing ':' in error message about munmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99733 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Sandoe --- (In reply to Roland Illig from comment #0) > config/host-darwin.c says: > > could not unmap % %m > > There is a ':' missing before the '%m'. (I changed this to avoid a diagnostic about "unquoted identifier or keyword".) Personally, I would have preferred "'pch_address_space' : " but that triggers another warning about punctuation in diagnostics. So I left the colon out (on purpose, it was not an accident ;) ). However, I have not a strong feeling about it - and if it helps translation to leave it in all OK with me. So we have now got "'pch_address_space': " > Plus, there is a unit test missing to demonstrate this typo. > Granted, this error message may be hard to produce anyway. Yeah, I don't know a reasonable way to do that. As noted in the commit message for the change I am not sure that the message is really a worthwhile end-user one, since there's nothing that they can do about it - however, fixing that is not something for stage 4.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 99733, which changed state. Bug 99733 Summary: darwin: missing ':' in error message about munmap https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99733 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[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 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Iain Sandoe --- so fixed for master and 10.3.
[Bug c++/98118] [coroutines] ICE with coroutine with parameter with non-trivial destructor since r10-6876-gdc192bbdd0442f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98118 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Iain Sandoe --- fixed for master and 10.3
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 96749, which changed state. Bug 96749 Summary: [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/96749] [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Iain Sandoe --- fixed for master and 10.3
[Bug c++/98704] coroutine_handle::done() == false after promise's unhandled_exception() has thrown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98704 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Iain Sandoe --- fixed (according to the current agreement about done = true being set for a coroutine suspended just before the promise lifetime end) for 10.3 and master.
[Bug c++/98480] [coroutines] ICE on co_await in for-loop end condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98480 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Iain Sandoe --- fixed for master and 10.3.
[Bug c++/99047] ICE on simple task coroutine example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99047 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Iain Sandoe --- fixed for master and 10.3
[Bug c++/95822] [coroutines] compiler internal error with local object with noexcept false destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95822 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Iain Sandoe --- fixed for master and 10.3
[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 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Iain Sandoe --- fixed for master and 10.3
[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 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Iain Sandoe --- fixed for master and 10.3.
[Bug sanitizer/96318] FAIL: c-c++-common/asan/strncpy-overflow-1.c * output pattern test with C on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96318 Iain Sandoe changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |9.4 --- Comment #3 from Iain Sandoe --- I fixed this for master, but failed to mention the PR number. r11-7704-gc86c5195c8c02f58 Part of the problem is that Darwin defaults to _FORTIFY_SOURCE if that is not explicitly given, and this results in the substitution of _chk builtins. This means that the disabling of the regular builtins fails (and we never have the call expected). That's fixable by adding -D _FORTIFY_SOURCE=0 to the command line. The other part of the issue is that the system address symboliser (atos) is not consuming the debug / frame information we are producing. At present, it's not clear if that's a GCC debug bug or an atos bug. Adding "-gdwarf-3" is sufficient to fix things in this case and is functional for the test-case. Investigation of the debug etc. will need to be deferred to the next stage1 and I am leaving this PR open, since the problem also exists on 10.x and 9.x (I will back port to at least 10.x).
[Bug other/93641] Wrong strncmp and strncasecmp size arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93641 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Iain Sandoe --- fixed for 10.x+ as noted in comment #2 the invoke.texi is correct as is.
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 Iain Sandoe changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #27 from Iain Sandoe --- bootstrap with Apple GCC-4.2.1 for gcc-10 works as of r10-9528 NOTE: GCC-11 requires C++11 to bootstrap, and therefore is NOT expected to work with Apple GCC-4.2.1.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #33 from Iain Sandoe --- Have we now resolved this issue? All current open branches work OK for me on all Darwin versions from 10.4 - 11.2. Please update if there is still something to fix.
[Bug target/90834] Header and startup objects not found on macOS 10.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834 --- Comment #17 from Iain Sandoe --- ping for closing this - or new information otherwise.
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #29 from Iain Sandoe --- (In reply to Piotr Kubaj from comment #28) > I just tried on FreeBSD 12.2-RELEASE on powerpc64 with base gcc 4.2.1: > gmake[4]: Entering directory > '/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/gcc' > c++ -std=gnu++98 -fno-PIE -c -DIN_GCC_FRONTEND -g -DIN_GCC > -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables > -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute > -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Icp > -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc > -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp > -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../include > -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libcpp/ > include -I/usr/local/include > -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../ > libdecnumber > -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../ > libdecnumber/dpd -I../libdecnumber > -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../ > libbacktrace -DLIBICONV_PLUG -o cp/coroutines.o -MT cp/coroutines.o -MMD > -MP -MF cp/.deps/coroutines.TPo > /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.cc > /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines. > cc:2700: error: invalid pure specifier (only `= 0' is allowed) before ';' > token > /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines. > cc:2700: error: initializer specified for non-virtual method > 'var_nest_node::var_nest_node()' There were some fixes pushed this week - I see you have gcc-10-20210313, which won't have picked those up. I am about to push my remaining patches for 10.x back port - but the ones I queued should not affect that. If there's still an issue with the coroutines code after that, let me know (that's mine to fix anyway).
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #35 from Iain Sandoe --- (In reply to Matt Thompson from comment #34) > Apologies. I forgot about this. Seeing as I'm now using GNU 10.2.0 on my > Macbook...I guess it's working. great! > and I can't wait for 10.3 or 11.0 or whatever is next! 10.3 release candidates should start in a few days, and then GCC-11 will be not too long after that ... > Note: I'm still on an Intel Mac, so I won't need to bother "Iain Sandoe, > master of M1 GNU" about that for a while. :D heh, M1 support in GCC12 is my objective - but there's a lot of work to do to get it there, let's see if 'experimental' can be morphed into 'production'.
[Bug c++/99827] [10/11 Regression] [coroutines] co_await on function receiving initializer list of shared pointers causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99827 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Iain Sandoe --- see 98056 *** This bug has been marked as a duplicate of bug 98056 ***
[Bug c++/98056] ICE tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.c:9862 since r11-2183-g0f66b8486cea8668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 Iain Sandoe changed: What|Removed |Added CC||inf17092 at lehre dot dhbw-stuttga ||rt.de --- Comment #6 from Iain Sandoe --- *** Bug 99827 has been marked as a duplicate of this bug. ***
[Bug libstdc++/99875] New: [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Bug ID: 99875 Summary: [10 Regression] experimental filesystem fails on Darwin Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- On the RC1 for 10.3 === libstdc++ Summary === # of unexpected failures51 of the form Excess errors: /src-local/gcc-git-10/libstdc++-v3/testsuite/util/testsuite_fs.h:135: error: '::getpid' has not been declared these were not present at r10-9540.
[Bug libstdc++/99875] [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Iain Sandoe changed: What|Removed |Added Target||x86_64-darwin, i686-darwin Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-01 --- Comment #1 from Iain Sandoe --- also present for m32 on platform versions supporting this.
[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
--- Comment #1 from Iain Sandoe ---
I think that this issue is already fixed in the released 10.3 branch and in
master (will shortly become GCC11). Please could you try one of those?
$ ./gcc-10/gcc-10/bin/g++ -std=c++20 -fcoroutines pr100127.C -S -save-temps
pr100127.C: In function ‘future create_future()’:
pr100127.C:54:8: error: the coroutine promise type
‘std::__n4861::__coroutine_traits_impl::promise_type’ {aka
‘future::promise_type’} declares both ‘return_value’ and ‘return_void’
54 | future create_future()
|^
pr100127.C:49:14: note: ‘return_void’ declared here
49 | void return_void() {}
| ^~~
pr100127.C:31:14: note: ‘return_value’ declared here
31 | void return_value(value_type val) {
| ^~~~
===
$ ./gcc-master/gcc-11-0-1/bin/g++ -std=c++20 -fcoroutines pr100127.C -S
-save-temps
pr100127.C: In function ‘future create_future()’:
pr100127.C:54:8: error: the coroutine promise type
‘std::__n4861::__coroutine_traits_impl::promise_type’ {aka
‘future::promise_type’} declares both ‘return_value’ and ‘return_void’
54 | future create_future()
|^
pr100127.C:49:14: note: ‘return_void’ declared here
49 | void return_void() {}
| ^~~
pr100127.C:31:14: note: ‘return_value’ declared here
31 | void return_value(value_type val) {
| ^~~~
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- thanks for the report. please could you check the uploaded assembly file, it seems to be truncated?
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #4 from Iain Sandoe --- (In reply to Iain Sandoe from comment #3) > please could you check the uploaded assembly file, it seems to be truncated? Ignore that - decompressor glitch.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #6 from Iain Sandoe --- (In reply to lucier from comment #5) > I didn't have this trouble with 10.2 or 9.3; should I add these to the > "Known to work" field? yes please - also the original source, if that's OK?
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #8 from Iain Sandoe --- (In reply to lucier from comment #7) > (In reply to Iain Sandoe from comment #6) > > > yes please - also the original source, if that's OK? > > It's highly macrofied C code with a lot of "includes"; is the .i file not > enough? enough for me to replicate the assembly produced, yes. would it be possible to set a breakpoint on the function itself and step through - the reported "invalid insn" seems odd, for sure. the values of rbp. r10 and esi would be interesting too.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #11 from Iain Sandoe --- (In reply to lucier from comment #10) > (In reply to Iain Sandoe from comment #8) > > (In reply to lucier from comment #7) > > > (In reply to Iain Sandoe from comment #6) > > > > > > > yes please - also the original source, if that's OK? > > > > > > It's highly macrofied C code with a lot of "includes"; is the .i file not > > > enough? > > > > enough for me to replicate the assembly produced, yes. > > OK, the .i file is also attached to this bug report. indeed, thanks. is this specific to macOS? (or is it unknown if the effect would also show on Linux)?
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #15 from Iain Sandoe --- I have to try and figure out a way to be able to reproduce the run-time error. Yes, the assembler output is different between 10.2 and 10.3 - but that insn is not apparently in error (and I checked that the assembler gives the same bit pattern for it with GAS and LLVM - it would probably have been astonishing if that was wrong... but) Is there a usable work-around while we try to figure this out? - what happens if you remove "-fschedule-insns2" ? You mentioned that "the way the program is called is not simple, it's a Scheme->C compiler building a "module", so it's hidden behind a number of scripts." I assume it is not some kind of JIT? FWIW, I don't believe that there were Darwin-specific changes to scheduling and insn output between 10.2 and 10.3, although it is possible that some other change exposed a latent problem, of course. Do you know if this failure persists with a trunk or 11 branch compiler? (sorry for all the questions, but since I can't actually reproduce the runtime fail yet)
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-04-21
Status|UNCONFIRMED |NEW
--- Comment #17 from Iain Sandoe ---
(In reply to lucier from comment #16)
> I have figured out how to build and then run the app in lldb to reliably
> reproduce the error.
> To configure and build Gambit, the Scheme->C compiler:
>
> 51 8:56mkdir gambit-test
> 52 8:56cd gambit-test
> 53 8:56git clone https://github.com/gambit/gambit.git
$ git log -1 --oneline
bb05af0a (HEAD -> master, origin/master, origin/HEAD) Fix missing return
address when using (declare (not optimize-dead-local-variables) (not
interrupts-enabled))
> 54 8:57cd gambit
> 55 9:00./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps
> -g' '--enable-single-host' '--enable-shared'
> Hope this helps.
[so far on Darwin16 / macOS 10.12 ]
Yes it does - can confirm that a 10.2 build works and 10.3 fails but the error
I get is different:
$ DYLD_LIBRARY_PATH=lib:gsi:gsc gsi/gsi
-:~~bin=./bin,~~lib=./lib,~~include=./include -v
Bus error: 10
lldb -- gsi/gsi -:~~bin=./bin,~~lib=./lib,~~include=./include -v
(lldb) env DYLD_LIBRARY_PATH=lib:gsi:gsc
(lldb) r
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=2, address=0x1000a88f0)
frame #0: 0x0001000a3475
libgambit.dylib`___release_rc(ptr=0x0001000a8900) at mem.c:724
721 {
722___rc_header *h = ___CAST(___rc_header*,ptr) - 1;
723
-> 724if (--h->refcount == 0)
725 {
726___rc_header *prev = h->prev;
I will try later on 10.15,
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #19 from Iain Sandoe --- (In reply to lucier from comment #18) > I can't see to build mainline on this machine, it fails with > > ../../../gcc-mainline/gcc/rtl.h:4547:42: error: use of undeclared identifier > 'TARGET_ISA_64BIT' > && GET_MODE_PRECISION (int_mode) < BITS_PER_WORD) > ^ > ../../../gcc-mainline/gcc/defaults.h:485:40: note: expanded from macro > 'BITS_PER_WORD' > #define BITS_PER_WORD (BITS_PER_UNIT * UNITS_PER_WORD) >^ > ../../../gcc-mainline/gcc/config/i386/i386.h:663:26: note: expanded from > macro 'UNITS_PER_WORD' > #define UNITS_PER_WORD (TARGET_64BIT ? 8 : 4) > ^ > ../../../gcc-mainline/gcc/config/i386/darwin.h:29:22: note: expanded from > macro 'TARGET_64BIT' > #define TARGET_64BIT TARGET_ISA_64BIT > > 54 warnings and 1 error generated. > make[3]: *** [build/genpreds.o] Error 1 > make[2]: *** [all-stage1-gcc] Error 2 > make[1]: *** [stage1-bubble] Error 2 > make: *** [all] Error 2 Yeah, there have been some patches pushed in early to GCC12 that have destabilised things - I haven't tried to build master since Saturday (which was OK). 11.1 branch should be OK. in the meantime - let see see if I can figure out how to fix master :(
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #20 from Iain Sandoe --- (In reply to Iain Sandoe from comment #17) > (In reply to lucier from comment #16) > > I have figured out how to build and then run the app in lldb to reliably > > reproduce the error. > I will try later on 10.15, ... which does reproduce the fail as you describe. - now it's interesting that different compilers fail in different places, and different OS versions fail with different symptoms. have to try an find a pattern to this.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #21 from Iain Sandoe --- (In reply to Iain Sandoe from comment #19) > (In reply to lucier from comment #18) > > I can't see to build mainline on this machine, it fails with > Yeah, there have been some patches pushed in early to GCC12 that have > destabilised things - I haven't tried to build master since Saturday (which > was OK). master should be OK after r12-50-ga44895ce7ffbc26b4d765c40b5b346f8c9a9b762 let me know if you still see problems.
[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #22 from Iain Sandoe --- so it looks like the contents of r10 are being trashed by the call to ___UTF_8_put (the first call goes through the dylib lazy symbol resolution and that leaves r10 with a value pointing to some mutex). When we return from ___UTF_8_put there's a test for the loop iteration which is expecting that to be the value in r10. The test is for equality which fails for the silly value now in r10 and we try a second loop iteration. That starts with the "movl (%rbp,%r10,4), %esi" - but r10 now has a value that can't be used. So I don't know if this is a new problem or an old problem that has been exposed by changes in the RA .. .. if there's any easy way to amend the build process to attempt modifications of the build flags to that file - this could give you a work-around in the short term.
[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 #4 from Iain Sandoe --- (In reply to Ignacio Fernández Galván from comment #3) > If it helps, this happens in gcc304 from > https://cfarm.tetaneutral.net/machines/list/, but not in gcc80 gcc304 is the Apple M1 machine. The GCC support there is highly experimental and not in master -- please note that there are known issues with the implementation. see : https://github.com/iains/gcc-darwin-arm64/issues
[Bug target/100152] [10.3, 11, 12 Regression] [Darwin, X86] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 Iain Sandoe changed: What|Removed |Added Target|x86_64-apple-darwin19.6.0 |x86_64-apple-darwin* Summary|Possible 10.3 bad code |[10.3, 11, 12 Regression] |generation regression from |[Darwin, X86] used |10.2/9.3 on Mac OS 10.15.7 |caller-saved register not |(Catalina) |preserved across a call. Known to fail||10.3.0 Target Milestone|--- |10.4 --- Comment #24 from Iain Sandoe --- O1: movl$0, %ebx L756: movl0(%rbp,%rbx,4), %esi movq%r14, %rdi callUTF_8_put movq%rbx, %rax addq$1, %rbx cmpq%rax, %r13 jne L756 works OK because %rbx is callee saved. O2: xorl%r10d, %r10d .p2align 4,,10 .p2align 3 L938: movl0(%rbp,%r10,4), %esi callUTF_8_put movq%r10, %rax addq$1, %r10 cmpq%rax, %r12 jne L938 fails because %r10 is not callee saved and is clobbered by the lazy symbol resolver. 10-2 uses rbx at O2, and so does Linux (it is of course hard to be 100% sure that the same problem "could not occur" on other platforms; there is relatively little Darwin-specific code in the x86 backend, especially for x86_64). I did see a fail [wrong code] with 11.1 (and would expect that to be present in master too) - whether the code crashes will depend on which reg happens to be used - e.g. r8 could survive the call (even tho it is not saved) but r10 will always be clobbered by the lazy symbol resolver. A workaround is to build c_intf.o with -O1. Unfortunately, the configuration for the project does not allow selection of the RTS optimisation level - it is jammed on at the highest level found. Adding or modifying a rule for that object will work in the short-term. Locally, I added a --enable-c-opt-rts to allow testing, you're welcome to that patch if it's helpful. Next will be to try and bisect to find the change that caused this - but obv. that is not going to be done before 10.4 / 11.2 so the workaround is probably needed.
[Bug target/100152] [10.3, 11, 12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 Iain Sandoe changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Summary|[10.3, 11, 12 Regression] |[10.3, 11, 12 Regression] |[Darwin, X86] used |used caller-saved register |caller-saved register not |not preserved across a |preserved across a call.|call. --- Comment #27 from Iain Sandoe --- this is caused by, or exposed by, r10-9246-geddcb627ccfbd97e025cf366cc3f3bad76211785 since that's a change in tree optimisation, the problem might not be confined to Darwin, but I wasn't able to get the preprocessed source attached here to produce wrong code on Linux. For x86_64, the Darwin ABI is supposed to be same as Linux - and as noted, there is not so much Darwin-specific back end code (but, of course, there is some).
[Bug target/100152] [10.3, 11, 12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #28 from Iain Sandoe ---
reduced test case:
___UTF_8_put(char *a, int b) {
char *c = a;
int bytes;
if (b <= 15)
bytes = 2;
else if (b <= 255)
bytes = 4;
else if (b <= 4095)
bytes = 5;
else
bytes = 6;
c = *a = c;
switch (bytes) {
case 6:
*--c = b >>= 6;
case 5:
*--c = b;
b >>= 6;
}
*c = bytes + b;
}
___SCMOBJ_to_NONNULLSTRING(d) {
{
unsigned long g, h;
char c;
h = ((long *)1)[1];
g = 0;
for (; g < h; g++)
i();
g = 0;
for (; g < h; g++)
___UTF_8_put(c, (long)*((unsigned *)d + (g << 2 >> 2)) << 2 >> 2);
}
}
[Bug target/100152] [10.3, 11, 12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #29 from Iain Sandoe --- what is also somewhat peculiar is that replacing the first function in the reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes the code-gen for the second function.
[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 #31 from Iain Sandoe --- (In reply to Richard Biener from comment #30) > (In reply to Iain Sandoe from comment #29) > > what is also somewhat peculiar is that replacing the first function in the > > reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes > > the code-gen for the second function. > > That might hint at IPA RA which you can try disabling via -fno-ipa-ra which > in turn hints at a target issue. yeah, it does switch back to using rbx, at least on the reduced test case. > Btw, the GIMPLE optimization change just exposes the issue - it can have no > influence on the used registers. indeed, it seemed more likely to be "exposed by".
[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 #32 from Iain Sandoe --- (In reply to Iain Sandoe from comment #31) > (In reply to Richard Biener from comment #30) > > (In reply to Iain Sandoe from comment #29) > > > what is also somewhat peculiar is that replacing the first function in the > > > reduced test case with "extern void ___UTF_8_put(char *a, int b);" changes > > > the code-gen for the second function. > > > > That might hint at IPA RA which you can try disabling via -fno-ipa-ra which > > in turn hints at a target issue. > > yeah, it does switch back to using rbx, at least on the reduced test case. (also on the original). I wonder if the problem is that IPA can't "see" the lazy symbol resolver, so it just sees a call to ___UTF_8_put and doesn't know that this will be resolved indirectly. .. but something similar must apply to PLT and targets with linker veneers ?
[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 #36 from Iain Sandoe ---
(In reply to Richard Biener from comment #35)
> Which means another possible candidate for the "bug" is darwin_binds_local_p
yeah... see below.
> > > .. but something similar must apply to PLT and targets with linker
> > > veneers ?
> >
> > I don't know how IPA RA works in detail but obviously the target has to
> > expose this detail. It looks like IPA RA causes us to add some notes to
> > call insns which are supposed to describe those details and there's
> > collect_fn_hard_reg_usage which looks at the target function (but likely
> > does not include the ABI details of the call itself, in this case the
> > resolver).
> @deftypevr {Target Hook} bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
> Set to true if each call that binds to a local definition explicitly
> clobbers or sets all non-fixed registers modified by performing the call.
> That is, by the call pattern itself, or by code that might be inserted by the
> linker (e.g.@: stubs, veneers, branch islands), but not including those
> modifiable by the callee. The affected registers may be mentioned explicitly
> in the call pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE.
> The default version of this hook is set to false. The purpose of this hook
> is to enable the fipa-ra optimization.
> @end deftypevr
thanks for the pointer, I'll take a look at that when i have some cycles.
I guess it was never added at the time the IPA stuff was done... and somehow we
"got away with it" mostly.
> might be relevant - though when compiling for a shared library the call
> to ___UTF_8_put does not bind locally (but then IPA RA shouldn't apply
> either I guess). So, does ___UTF_8_put bind locally?
extern void ___UTF_8_put
(char* *ptr, unsigned int c)
If it does, then that's also a bug :), will have to check (sometime later).
(we are always building with fPIC for x86_64, snd don't specifically identify
that the result will be a shlib [all Darwin exes are DSOs too] - although
Linux does identify shlibs as something special).
[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 #38 from Iain Sandoe --- (In reply to Richard Biener from comment #37) > Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 doesn't seem > to reproduce the issue with the reduced testcase (I seee no call to > ___UTF_8_put remaining with -O3 -fPIC -fno-strict-aliasing -fwrapv). I think my interestingness test isn't strict enough - the creduced code resulting doesn't have an extern for ___UTF_8_put and only seems to not inline that fn because the interface has been mangled. [ so that the fn is legitimately binds_localP as the pasted case ]. if you still have the build around, out of curiosity, does it fail on the original .i file attached here? and with -fno-trapping-math -fno-math-errno -fschedule-insns2 -fomit-frame-pointer ( I only need O2 to get a fail ).
[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 #41 from Iain Sandoe --- (In reply to Richard Biener from comment #40) > (In reply to Richard Biener from comment #39) > > (In reply to Iain Sandoe from comment #38) > > > (In reply to Richard Biener from comment #37) > > > > Oh, and FYI a cc1 cross from x86_64 to x86_64-apple-darwin19.6.0 > > > > doesn't seem > > > > to reproduce the issue with the reduced testcase (I seee no call to > > > > ___UTF_8_put remaining with -O3 -fPIC -fno-strict-aliasing -fwrapv). > > code. But then ___UTF_8_put isn't interposable so I wonder why the linker > > even has to resolve anything. Adding -fPIC OTOH should definitely make the > > symbol interposable but the same code is still generated ... Darwin x86_64 is always PIC (fPIC is a NOP, and is added if no other PIC mode is given). user-mode code is invalid without it. > > breaking on darwin_binds_local_p I see ___UTF_8_put is considered binding > > local even with -fPIC. So GCC thinks there will be no linker stub involved. which is the immediate bug here... > flag_shlib != 0 || force_overridable I want to check on the indirection rules to be sure [they are not exactly the same as Linux] (and that flag_shlib is set appropriately). The other possible bug might be irrelevant (missing information to IPA about the lazy resolver) - but I still need to think about the various cases.
[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 Iain Sandoe changed: What|Removed |Added Target Milestone|10.4|8.5 --- Comment #42 from Iain Sandoe --- actually, it seems clear that this case was just exposing a latent problem and the fix is needed on all open branches (and by distros if they care about it on older branches). Adjusting the target milestone.
[Bug bootstrap/100246] New: [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
Bug ID: 100246
Summary: [11/12 Regression] GCC will not bootstrap with clang
3.4/3.5 [xcode 5/6, Darwin 12/13]
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
using CC=clang and CXX="clang++ -stdlib=libc++" which is needed to get C++11
support.
In file included from /src-local/gcc-git-11/gcc/config/i386/i386-options.c:94:
/src-local/gcc-git-11/gcc/config/i386/x86-tune-costs.h:363:13: error: call to
implicitly-deleted default constructor of 'const struct stringop_strategy'
{libcall, {{-1, rep_prefix_4_byte, false}}},
^
/src-local/gcc-git-11/gcc/config/i386/i386.h:254:15: note: default constructor
of 'stringop_strategy' is implicitly deleted because field 'max' of
const-qualified type 'const int' would not be initialized
const int max;
when building in c++89 mode, (GCC10.x and earlier) this worked fine. It does
look like a clang bug (but the rules are quite complex around this topic). It
would seem it's trying to find a constructor for the empty elements in the
lists (and that is implicitly deleted).
A workaround is to ensure that all the elements have a complete initialisers
with dummy entries for those that are not needed. Patch pending.
[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 Iain Sandoe changed: What|Removed |Added Host||x86_64-darwin12, ||x86_64-darwin13 Keywords||build Build||x86_64-darwin12, ||x86_64-darwin13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-24
[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 #44 from Iain Sandoe --- unfortunately, wider testing showed sanitiser fails - so this has been reverted for now.
[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 --- Comment #1 from Iain Sandoe --- Created attachment 50669 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50669&action=edit Patch that works around the clang issue/bug this is against GCC-11.1rc2, but not likely to need much/any amendment for GCC12.
[Bug bootstrap/92719] MacOS 10.15 Catalina build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92719 --- Comment #6 from Iain Sandoe --- (In reply to Nikhil Benesch from comment #5) > Ah, sorry, I was imprecise before. By “system gmp” I meant a gmp installed > by Homebrew, as in `brew install gmp`. So ... I am guessing that the default home-brew installation place is /usr/local? the only way the configury can find things is (1) it's in some well known place (2) you tell it where to find it usually using a --with-=. > I believe this is a third option from the two you listed. (At least, it is > on non-macOS platforms.) actually, Darwin's behaviour w.r.t to sysroots and suchlike is not different from Linux. What is different is that Linux [and older Darwin] tends to have an installation of the headers etc in /, so for self-hosted builds there's no need for a sysroot. however, modern macOS/Darwin now requires a sysroot (a.k.a SDK) always. >without a `—with-gmp-dir` option, Homebrew’s GMP > installation gets automatically picked up by the top level configure script, > but somehow the configure script in the gcc subdirectory can’t find gmp.h. If something is in /usr/local, then default search paths will find it (the top level configure doesn't prepend a sysroot - but the system compiler [clang] will do - as will any functional GCC used for bootstrap). However - we need a sysroot for Darwin so /some/path/to/the/SDK... Probably, it's somewhat inconsistent that the top level succeeds (the top level ought to fail too if the build/host needs a sysroot). ... but /usr/local does *not* exist relative to that SDK (it's present relative to /) so /some/path/to/the/SDK/usr/local doesn't contain anything (or even exist). the compiler(s) will not add /usr/local to the search paths automatically (they will only add paths onto the sysroot, or relative to the compiler's installation tree). This has been discussed in various PRs - it's actually quite tricky to be sure that it's safe to add /usr/local to the search paths in any automatic way (think, for example, what would happen if cross-compiling from X86_64 => powerpc or Arm64) If this is the situation ... then --with-gmp=/usr/local ought to work. If GMP is installed somewhere else, then it would be interesting to see how the top level config finds it.
[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 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |10.3 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last reconfirmed||2020-10-16
[Bug c++/97433] C++20 Coroutines, Unexpected reordering of await_resume, return_value and yield_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97433 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-10-16 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Iain Sandoe --- probably a dup of 97452.
[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 #1 from Iain Sandoe --- probably a dup of 97433.
[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 #3 from Iain Sandoe --- (In reply to David Ledger from comment #2) > I'm happy to use this thread for the issue, I can just repost my link to the > same issue here. > > My reporting of the issue is here, but Lewis Bakers example is seperate. > > https://stackoverflow.com/questions/64348125/c20-coroutines-unexpected- > reordering-of-await-resume-return-value-and-yield > > Is there anything I can do to help this issue get resolved? I've been > throwing things at the wall trying to get something to stick (for a work > around) but so far nothing helps with this particular case. I have reproduced the problem(s) - the next thing is to do some analysis of the generated code and try to figure out where the bug is.
[Bug c++/97438] [accepts-invalid] coroutines accepts prmomise type with both return_value() and return_void()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97438 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Last reconfirmed||2020-10-19 Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Sandoe --- fixed on master, the general view is that this isn't critical to back port (if there is some pressing reason it should be then please reopen the PR).
