[Bug target/90834] Header and startup objects not found on macOS 10.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-03-19 Status|UNCONFIRMED |WAITING --- Comment #15 from Iain Sandoe --- 10.15 has been working for me for some time for SDKs included with Xcode 11.3+ can this bug be closed now, or is there something else we need to address?
[Bug lto/94237] New: [10 regression] Many (100s) of new LTO fails on Darwin targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94237 Bug ID: 94237 Summary: [10 regression] Many (100s) of new LTO fails on Darwin targets Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- This seems to be from "API extension for binutils (type of symbols)." https://gcc.gnu.org/g:c8429c2aba80f845939ffa6b2cfe8a0be1b50078 Although this might simply be exposing a latent problem. We are ICE-ing here with a NULL_TREE DECL_UNIT_SIZE. frame #2: 0x0001015ad1af cc1`tree_to_uhwi(t=0x) at tree.c:7361 frame #3: 0x0001017753d4 cc1`machopic_select_section(decl=0x000143422bd0, reloc=0, align=8) at darwin.c:1591 frame #4: 0x00010163aec1 cc1`get_variable_section(decl=0x000143422bd0, prefer_noswitch_p=) at varasm.c:1216 frame #5: 0x000100efc24a cc1`::write_symbol_extension_info(t=0x000143422bd0) at lto-streamer-out.c:2793 frame #6: 0x000100efcf02 cc1`::produce_symtab_extension(ob=, previous_streamed_symbols=2) at lto-streamer-out.c:2888 frame #7: 0x000100f0f45a cc1`produce_asm_for_decls() at lto-streamer-out.c:3081 frame #8: 0x000101008e34 cc1`::write_lto() at passes.c:2617 frame #9: 0x00010100b0a2 cc1`::ipa_write_summaries_1(encoder=0x0001027003e0) at passes.c:2678 frame #10: 0x00010100c352 cc1`ipa_write_summaries() at passes.c:2733 frame #11: 0x0001009b4f7e cc1`::ipa_passes() at cgraphunit.c:2667 frame #12: 0x0001009b55c0 cc1`symbol_table::compile(this=0x000144c05100) at cgraphunit.c:2754 frame #13: 0x0001009b6ab6 cc1`symbol_table::finalize_compilation_unit(this=0x000144c05100) at cgraphunit.c:3001 Background. Darwin's linker makes use of 'atoms' which are non-zero-sized code and data fragments starting with a linker-visible symbol. These can be rearranged in the manner of ELF function and data sections but at a finer granularity. One consequence of this is that two atoms may not share the same address, therefore no two linker-visible symbols may refer to the same address. This means that zero-sized objects (with a linker-visible-symbol) must be padded to at least one byte. If unhandled, this would prevent section anchors from working since the size of objects 'lies' c.f. that recorded in the decls. To cater for this, we place zero-sized objects in separate sections and mark those sections as not supporting section anchors. === Therefore, whenever the Darwin backend is asked for the section for a variable, it checks to see if the variable is zero-sized before placing it. 'machopic_select_section' is failing because the VAR_DECLs are being passed with DECL_UNIT_SIZE unset (i.e. NULL_TREE) which means that either the type is incomplete or that it has not been laid out. Clearly, we can avoid the ICE by acting in some way on the NULL size - but maybe that means we're streaming incomplete or incorrect information. In the cases I've examined so far, the var decls are arrays that might have unspecified dimensions ... int x[]; but also the vtables in typeinfos are failing. There are many fails, and they have not all be analysed.
[Bug lto/94237] [10 regression] Many (100s) of new LTO fails on Darwin targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94237 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-03-20 Status|UNCONFIRMED |NEW Target Milestone|--- |10.0 Ever confirmed|0 |1 Keywords||ice-on-valid-code
[Bug lto/94237] [10 regression] Many (100s) of new LTO fails on Darwin targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94237 Iain Sandoe changed: What|Removed |Added Target||x86_64-apple-darwin* --- Comment #1 from Iain Sandoe --- reproduces on a stage1 - so a cross would work. However, it would seem unlikely to be Darwin-specific as to whether the types are incomplete/not laid out.
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #23 from Iain Sandoe --- unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK >= Xcode commandline tools 11.3b. If there's no additional information I propose we close this PR after another week.
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 --- Comment #25 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #24) > > --- Comment #23 from Iain Sandoe --- > > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK > > >= > > Xcode commandline tools 11.3b. > > I've recently tried both building gcc 8.3.0 (build only) and master > (full bootstrap and test) on macOS 10.14.6 and 10.15.3, each with Xcode > 11.3.1. Both worked *provided the build and target compilers were > configured with the approriate --with-sysroot to account for the lack of > /usr/include and startup objects in /usr/lib*. That's not going to change, I think (at least, the underlying behaviour). We could entertain and implement a change to Darwin's configuration that automatically discovers the /Library/Developer/CommandLineTools .. or /Applications/Xcode... for Darwin versions >= X and complains of fails to configure if those can't be seen (asking for a --with-sysroot=). We can already invoke GCC like "xcrun /path/to/gcc-exe" provided that is not called "gcc" or "g++" it will work to set the SDKROOT which gcc honours from 7.5+. The only irritation is that we can't use 'gcc' or 'g++' in that position, because xcrun places the clang/++ aliases ahead of the GCC in the PATH (even if the GCC install is first) [last time I tried]. There's also an API to obtain the info - but only on 10.15+ and it forces one to install XCode I suspect to use it, I'm not keen on making new dependencies on things outside our control - I'd rather make use of OSS equivalents. > > If there's no additional information I propose we close this PR after > > another > > week. > > I guess that's fine. I think we have the /usr/local/include issue tracked elsewhere.
[Bug c++/94288] co_await in while loop crashes g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94288 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- thanks for the report. The reduced testcase at c#2 doesn't fire for me once pending updates are applied. However, the attached case preprocessed code does; I think we will be able to make suitable test-cases, once the analysis is done.
[Bug c++/94288] co_await in while loop crashes g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94288 --- Comment #5 from Iain Sandoe --- (In reply to Martin Liška from comment #4) > (In reply to Iain Sandoe from comment #3) > > thanks for the report. The reduced testcase at c#2 doesn't fire for me once > > pending updates are applied. However, the attached case preprocessed code > > does; I think we will be able to make suitable test-cases, once the analysis > > is done. > > If you point me to the pending patches, I can make reduction based on that? (the reduction is not urgent, I've an idea about the problem, hopefully have a few cycles on it tomorrow) unreviewed: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542407.html review-in-progress: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542411.html (but thanks for the offer!)
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 --- Comment #2 from Iain Sandoe --- (In reply to David Binderman from comment #1) > git blame says: > > 49789fd08378 (Iain Sandoe 2020-01-18 11:54:46 + 2654) do_subtree = 0; > > Adding author. indeed looks like a typo. thanks
[Bug c++/94319] gcc/cp/coroutines.cc:2654: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94319 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Iain Sandoe --- so fixed
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-03-27 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Iain Sandoe --- There are two cases here. 1) When the optimisation level is < 2 (where GCC does not normally tail-call). - in that case, the specific call [ which is in the tail position, and AFAIU should be tail-callable ] is marked as TAIL_CALL, MUST_TAIL_CALL (hence the complaint error: cannot tail-call: target is not able to optimize the call into a sibling call, I suppose). 2) for O >= 2 where GCC would normally tail call anyway - for this, the coroutine code does not mark the cll specially, so for these cases it indicates that the tail-call is not being made in "normal" circumstance. the function signature is void actor (void *) and the codgen should be emitting an indirect call, followed by a void return (the indirect call is expanding __builtin_coro_resume() [expansion happens very early in the ME].
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #2 from Iain Sandoe --- it is not mandatory (for C++20 compliance) that the implementation provides symmetric transfer - so it could be switched off - or XFAILed. However, users state that an impl. that can't do the symmetric transfers is not useful in a number of important applications.
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #3 from Iain Sandoe ---
Note1 : the 32b multilib works without any error.
Note2 : The dumps are gimple from symmetric-transfer-00-basic.C.020t.fixup_cfg1
which is the pass after all the coroutine-specific stuff is complete.
thus, For O0 (produces the error saying it can't tail call):
:
actor.continue.ret:
actor.continue = VIEW_CONVERT_EXPR(D.38505);
_38 = std::__n4835::coroutine_handle::address (&actor.continue);
_39 = MEM[(void (*) (void *) *)_38];
_39 (_38); [tail call] [must tail call]
goto ; [INV]
...
:
:
actor.continue = {CLOBBER};
:
:
return;
for O2 (execute fails, because without the tail-call we overflow the stack).
:
actor.continue.ret:
frame_ptr->__resume_at = 6;
_22 = &frame_ptr->__lv.1.1.aw;
D.38734 = Loopy::loopy_awaiter::await_suspend (_22,
frame_ptr->__self_h); [return slot optimization]
actor.continue = VIEW_CONVERT_EXPR(D.38734);
_38 = std::__n4835::coroutine_handle::address (&actor.continue);
_39 = MEM[(void (*) (void *) *)_38];
_39 (_38); [tail call]
goto ; [INV]
...
:
actor.suspend.ret:
:
actor.continue = {CLOBBER};
return;
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #4 from Iain Sandoe --- so, it seems: rs6000_function_ok_for_sibcall () calls rs6000_decl_ok_for_sibcall () which gets a NULL decl and thus this returns false /* Under the AIX or ELFv2 ABIs we can't allow calls to non-local functions, because the callee may have a different TOC pointer to the caller and there's no way to ensure we restore the TOC when we return. */ if (!decl || DECL_EXTERNAL (decl) || DECL_WEAK (decl) || !(*targetm.binds_local_p) (decl)) return false; The signature of the callee is void (void *) So not sure how to proceed here at the moment (I wonder if this works for PPC on the clang impl). The comment indicates that this is going to fail for AIX too as it stands.
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > So not sure how to proceed here at the moment (I wonder if this works for > PPC on the clang impl). It does work for X86 (and ironically, on PPC Darwin too - where the fact that we build a new "got" in each routine + no use of TOC means we can always tail call). Actually, I'm a bit suspicious of what happens in the case that two coroutines are in different DSOs for X86. apparently not: [iains@gcc1-power7 llvm-90]$ ./INSTL/bin/clang++ -fcoroutines-ts -std=c++17 ../gcc-master/src/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C -stdlib=libc++ -S fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail (the test case crashes the compiler for O>0). [iains@gcc1-power7 llvm-10]$ ./INSTL/bin/clang++ -fcoroutines-ts -std=c++17 ../gcc-master/src/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C -stdlib=libc++ -S fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail I'm going to discuss this with the coroutines paper authors - as to whether any constraints had been considered. Note, once again, that failure to implement this does not make us non-conforming.
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Iain Sandoe from comment #4)
> I'm going to discuss this with the coroutines paper authors - as to whether
> any constraints had been considered. Note, once again, that failure to
> implement this does not make us non-conforming.
coro paper author hadn't tested this configuration.
==
basically, the intent is that one can continue an arbitrary number
of coroutines, without overflowing the stack. Maybe there's an alternate
pattern that we could construct that would allow this; modulo the caller-
save of the TOC. Coroutine actor functions are marked with a flag, so we
do have a mechanism for handling them differently.
In the meantime, I guess this isn't going to work for PPC (AIX/powerpc64)
:( and we have to XFAIL or switch it off.
/* A C equivalent of what's being done. */
extern void actor (void *p);
/* This is how the public part of the coroutine frame ABI looks. */
typedef struct __frame {
void (*a) (void *);
void (*d) (void *);
float _other_things;
} generic_frame_t;
/* This is what a coroutine handle looks like. */
typedef struct __handle {
generic_frame_t *fp;
} generic_handle_t;
/* A fake call to get a handle... */
__attribute__((__noinline__))
generic_handle_t get_handle (void)
{
generic_frame_t *f = (generic_frame_t *)__builtin_malloc (sizeof
(generic_frame_t));
f->a = actor;
f->d = actor;
f->_other_things = 0.0F;
generic_handle_t h = {f};
return h;
}
/* .. and part of coroutine state machine that wants to continue
by executing another coroutine.
X86 tail-calls this for O2+ (even for PIC) m32/m64
PPC tail-calls for m32 (even for PIC), but not for ELFv2 m64.
with the TOC reg caller-saved, perhaps there's no sequence that can
work.
*/
void actor2 (void *p2)
{
generic_handle_t h = get_handle ();
generic_frame_t *t = h.fp;
/* Use the TOC. */
t->other_things = 1.1F;
(*t->a) ((void *)t);
}
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #8 from Iain Sandoe --- (In reply to Rainer Orth from comment #7) > I'm seeing the same failure on Solaris/SPARC (32 and 64-bit). Do you have any info on why the tail-call fails there? (e.g. is it not possible to make an indirect tail-call in the ABI, as seems to be the case for powerpc64 & AIX). At present, having discussed with a couple of other folks, my plan (for stage 4) is to produce a target hook to allow targets to opt out. For next stage 1, since the caller and the callee are both under our control and it is known that the callee *must* be another coroutine 'actor' function it might be possible to work around specific target constraints.
[Bug c++/94454] New: ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Bug ID: 94454 Summary: ICE 'canonical types differ for identical types' Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- This a bug reported by Eric Niebler when building the ranges-v3 code on Darwin19, however it's not a Darwin-specific problem. This is a very slippery bug to pin down (possibly a dup of 90301, but unknown at present) The failure on a given platform seems to depend on the compiler build. I have now seen fails on x86-64-linux-gnu, powerpc64-linux-gnu, *darwin*. Some compiler builds fail almost consistently on a given platform, but a later build could easily pass every time. Often the fail is ≈ 1 time in 5 attempts. tried: --with-checking=yes,gcac --param ggc-min-expand=0 --param ggc-min-heapsize=0 Neither altered the repeatability. Jonathan did a run under valgrind which was also inconclusive. I've tried (manually) a fairly large number of permutation of options etc. without any pattern emerging. At present a hunch is that it's maybe an uninitialised var, or perhaps something that depends on the order in which things get initialised. ** Trying to reduce on x86-64-linux-gnu and x86-64-darwin16 (but going very slowly). /home/iains/range-v3/include/meta/meta.hpp:1216:11: internal compiler error: canonical types differ for identical types ‘std::integral_constant >’ and ‘std::integral_constant >’ 1216 | using if_c = _t, Args...>>; | ^~~~ 0x1054ba4b comptypes(tree_node*, tree_node*, int) ../../src/gcc/cp/typeck.c:1519 0x1053679f cp_tree_equal(tree_node*, tree_node*) ../../src/gcc/cp/tree.c:3940 0x10536523 cp_tree_equal(tree_node*, tree_node*) ../../src/gcc/cp/tree.c:3933 0x1043318f template_args_equal(tree_node*, tree_node*, bool) ../../src/gcc/cp/pt.c:9043 0x10432e13 template_args_equal(tree_node*, tree_node*, bool) ../../src/gcc/cp/pt.c:8985 0x10432e13 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, bool) ../../src/gcc/cp/pt.c:9072 0x10432e13 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**, bool) ../../src/gcc/cp/pt.c:9052 0x104463bf spec_hasher::equal(spec_entry*, spec_entry*) ../../src/gcc/cp/pt.c:1703 0x104c577f hash_table::find_with_hash(spec_entry* const&, unsigned int) ../../src/gcc/hash-table.h:917 0x1049545b lookup_template_class_1 ../../src/gcc/cp/pt.c:9680 0x10499da3 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../src/gcc/cp/pt.c:10020 0x10499da3 tsubst_aggr_type ../../src/gcc/cp/pt.c:13301 0x1048e023 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:13092 0x1048e66b tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:13040 0x1048e0f3 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:13090 0x10499d4f tsubst_aggr_type ../../src/gcc/cp/pt.c:13295 0x1048e023 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:13092 0x1048965b tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.c:14946 0x10479c0b tsubst_decl ../../src/gcc/cp/pt.c:14377 0x1049a5e3 instantiate_template_1 ../../src/gcc/cp/pt.c:20588 Please submit a full bug report,
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-04-02 Keywords||ice-on-valid-code Target Milestone|--- |10.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||10.0
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #1 from Iain Sandoe --- there's a gist here: https://gist.github.com/jwakely/e131d3a268a78764458186eff02f29ec with Jonathan's valgrind session and some debug output from one case where I managed to catch the fail under a debugger.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
--- Comment #5 from Iain Sandoe ---
(In reply to Nathan Sidwell from comment #4)
> Oh, it is from the template specialization hash table. I suggest making
> that very poor to increase collisions:
>
> pt.c:
> static hashval_t
> hash_tmpl_and_args (tree tmpl, tree args)
> {
> hashval_t val = iterative_hash_object (DECL_UID (tmpl), 0);
>return val; // INSERT THIS LINE
> return iterative_hash_template_arg (args, val);
> }
>
> sorry for not realizing this earlier
[not wishing to disturb the c-reduce sessions already started]
On Darwin17 @r10-7488, which was always succeeding
I bootstrapped with this patch, and then built a --disable-bootstrap with the
"spec_hasher::hash always returns 0" applied too.
Neither made any difference, the entire ranges-v3 suite built without issue.
Maybe that's informative in its own right.
Will hopefully have some kind of reduced test-case for x86-64-linux tomorrow.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #7 from Iain Sandoe --- Created attachment 48175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48175&action=edit un-reduced pre-processed on x86_64-linux working on reducing this.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 --- Comment #8 from Iain Sandoe --- (In reply to Nathan Sidwell from comment #6) > On 4/2/20 12:37 PM, iains at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 > > > > --- Comment #5 from Iain Sandoe --- > > (In reply to Nathan Sidwell from comment #4) > >> Oh, it is from the template specialization hash table. I suggest making > >> that very poor to increase collisions: > > I bootstrapped with this patch, and then built a --disable-bootstrap with > > the > > "spec_hasher::hash always returns 0" applied too. > > Ok, BTW spec_hasher::hash forwards to hash_tmpl_and_args. They must > agree, so ... > > > Neither made any difference, the entire ranges-v3 suite built without issue. > > surprises me. hum .. both alter the code that's executed to compute the hash - which is the code that seems to be complaining. So .. maybe I need to cook up something that computes the hash via the path that's failing, but then throws it away... still might not exercise the case.
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454 Iain Sandoe changed: What|Removed |Added Attachment #48175|0 |1 is obsolete|| --- Comment #9 from Iain Sandoe --- Created attachment 48176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48176&action=edit original unreduced test case on x86_64 linux. the previous attachment had been partially creduce-d (this is the original).
[Bug c++/94528] New: coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94528 Bug ID: 94528 Summary: coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- Created attachment 48237 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48237&action=edit c-reduced reproducer.
[Bug c++/94528] coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94528 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last reconfirmed||2020-04-07 --- Comment #1 from Iain Sandoe --- Created attachment 48238 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48238&action=edit Patch being tested
[Bug c++/94528] coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94528 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.0 Keywords||ice-on-valid-code
[Bug c++/93343] coroutine ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93343 Iain Sandoe changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #2 from Iain Sandoe --- I am marking this as a dup of the one for which I have a reproducer. *** This bug has been marked as a duplicate of bug 94528 ***
[Bug c++/94528] coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94528 Iain Sandoe changed: What|Removed |Added CC||euloanty at live dot com --- Comment #2 from Iain Sandoe --- *** Bug 93343 has been marked as a duplicate of this bug. ***
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #11 from Iain Sandoe --- Created attachment 48251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48251&action=edit Patch for testing coroutines: Fix compile error with symmetric transfers [PR94359] For symmetric transfers to work with C++20 coroutines, it is currently necessary to tail call the callee coroutine from resume method of the caller coroutine. The current codegen marks these resume calls as "MUST_TAIL_CALL" to indicate that the tail call is required for correctness, in the general case. Unfortunately, several targets have ABI constraints that prevent an indirect tail-call, which results in the PRs compile error. The change here tests the target sibcall hook for the resume expression and only marks it as requiring a tail call if that's supported. This doesn't fix the underlying problem; that really a solution is needed to allow the tail-calls (or equivalent) to take place - but that will be deferred until next stage 1. The test case is 'xfail-run-if'd for the targets mentioned in this PR since we still want to test that the compile proceeds without error. At compile-time we can't tell if missing the tail-call will cause a specific code to fail, so that most likely a warning for this case would produce a lot of false positives. gcc/cp/ChangeLog: 2020-04-09 Iain Sandoe PR c++/94359 * coroutines.cc (build_actor_fn): Check that the target can support the resume tail-call before mandating it. gcc/testsuite/ChangeLog: 2020-04-09 Iain Sandoe PR c++/94359 * g++.dg/coroutines/torture/symmetric-transfer-00-basic.C: Expect a run fail for targets without indirect tail-calls.
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.0 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #6 from Iain Sandoe --- (In reply to CVS Commits from comment #5) > The master branch has been updated by Iain D Sandoe : sorry about the bad PR number, this commit is unrelated to the PR.
[Bug c++/94528] coroutines: ICE building cppcoro in gimplify_expr, at gimplify.c:14399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94528 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Iain Sandoe --- so fixed
[Bug c++/94454] ICE 'canonical types differ for identical types'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94454
--- Comment #11 from Iain Sandoe ---
(In reply to Nathan Sidwell from comment #10)
> I cannot reproduce it,
it is frustratingly difficult to do so.
> but looking at the gist referenced in comment #1 I
> see that the complaint is about two instances of the same instantiation of
> struct std::integral_constant >
>
> One of which has __attribute__ ((__abi_tag__ ("cxx11"))) attached to it.
> That seems to be the error -- how did that abi_tag get there? it's not on
> the original declaration.
>
> I can't see how those could have become attached. AFAICT we don't propagate
> attributes from the arguments of an instantiation, to the instantiation
> itself (and that wouldn't explain it here, as 'and_v' and __is_constructible
> are unattributed.
this does not seem to be reproducible, possibly a result of some other bug
that's since been fixed.
- I don't think it's the smoking gun (but could be that the relevant field
contains something random).
[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 Iain Sandoe changed: What|Removed |Added Component|target |c++ --- Comment #12 from Iain Sandoe --- reclassifying as a c++ issue.
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #18 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #17) > So, what exactly happens? Does GCC 4.2 e.g. fail to initialize all members > to zeros in the > - memset (data, 0, sizeof (*data)); > + *data = assign_parm_data_one (); > change? > Would it work to > memset (data, 0, sizeof (*data)); > data->arg = function_arg_info (); > for old GCC, or add for old GCC an explicit default constructor to > struct assign_parm_data_one, or > #if GCC_VERSION < 4300 > memset (data, 0, sizeof (*data)); > #endif > *data = assign_parm_data_one (); > ? > Most of the other changes seem to be just about using different member names > and thus shouldn't really matter much. hmm I don't see a CTOR specified for assign_parm_data_one. So I guess it's using an implicit default, which is perhaps trivial (assuming that the struct assign_parm_data_one is POD, which seems possible). Will poke at this when I have a spare machine supporting that bootstrap compiler.
[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 --- Comment #15 from Iain Sandoe --- (In reply to Andreas Schwab from comment #14) > That completely breaks aarch64 (almost every coroutines test): apologies, do you have any immediate idea why the aarch64_function_ok_for_sibcall is failing there?
[Bug c++/94661] New: coroutine ramp function return value ICE for default copy CTOR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94661
Bug ID: 94661
Summary: coroutine ramp function return value ICE for default
copy CTOR.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48307
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48307&action=edit
fix being tested
Coroutine ramp functions have synthesised return values (the user-authored
function body cannot have an explicit 'return'). The current implementation
attempts to optimise by building the return in-place, in the manner of C++17
code. Clearly,
too ambitious :
The following code ICEs with
internal compiler error: in expand_expr_addr_expr_1, at expr.c:8075
This is because the default copy CTOR conflicts with the inlace construction.
(NOTE: If the Copy CTOR is marked as deleted [which is the most common
programming idiom for this] all is OK).
---
template struct promise {
T _value;
coro::coroutine_handle<> _continuation = nullptr;
struct final_awaitable {
bool _has_continuation;
final_awaitable(bool has_continuation)
: _has_continuation(has_continuation) {}
bool await_ready() const noexcept { return !_has_continuation; }
template
coro::coroutine_handle<>
await_suspend(coro::coroutine_handle coro) noexcept {
return coro.promise()._continuation;
}
void await_resume() noexcept {}
};
auto get_return_object() noexcept {
return coro::coroutine_handle::from_promise(*this);
}
auto initial_suspend() noexcept { return coro::suspend_always(); }
auto final_suspend() noexcept {
return final_awaitable(_continuation != nullptr);
}
void return_value(T value) { _value = value; }
void unhandled_exception() { /*std::terminate();*/ }
};
template struct task {
using promise_type = promise;
coro::coroutine_handle> _handle;
task(coro::coroutine_handle> handle) : _handle(handle) {}
bool await_ready() noexcept { return _handle.done(); }
coro::coroutine_handle<>
await_suspend(coro::coroutine_handle<> handle) noexcept {
_handle.promise()._continuation = handle;
return _handle;
}
T await_resume() noexcept { return _handle.promise()._value; }
};
task
foo()
{
co_return 1;
}
[Bug c++/94661] coroutine ramp function return value ICE for default copy CTOR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94661 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last reconfirmed||2020-04-19 Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug c++/94682] New: coroutines: Promise param preview should get a reference to *this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94682
Bug ID: 94682
Summary: coroutines: Promise param preview should get a
reference to *this.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48322&action=edit
fix being tested.
Reported independently by Michał Dominiak and Lewis Baker.
The static assert fails in the following code, because we should be passing a
reference to *this but we're passing this.
struct promise;
struct future
{
using promise_type = promise;
};
struct promise
{
template
promise(Class &,int) { static_assert(!std::is_pointer::value, ""); }
coro::suspend_never initial_suspend() { return {}; }
coro::suspend_never final_suspend() { return {}; }
future get_return_object() { return {}; }
void return_value(int) {}
void unhandled_exception() {}
};
struct bar
{
future foo(int param)
{
co_return 0;
}
};
[Bug c++/94682] coroutines: Promise param preview should get a reference to *this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94682 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Ever confirmed|0 |1 Keywords||wrong-code Target Milestone|--- |10.0 Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-21
[Bug target/93694] Inconsistent grammar in darwin.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93694 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Iain Sandoe --- Is this sufficiently clear now?
[Bug c++/94661] coroutine ramp function return value ICE for default copy CTOR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94661 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- so fixed.
[Bug c++/94701] New: coroutines: Wrong code for structured bindings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94701
Bug ID: 94701
Summary: coroutines: Wrong code for structured bindings.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48330
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48330&action=edit
patch under test
As reported by Michał Dominiak, the following code gets an incorrect answer -
this is because we fail to check for DECL_VALUE_EXPR in the handling for local
vars.
struct promise;
struct future
{
using promise_type = promise;
};
struct promise
{
template
promise (Args&... args) {}
coro::suspend_never initial_suspend() { return {}; }
coro::suspend_never final_suspend() { return {}; }
future get_return_object() { return {}; }
void return_value(int) {}
void unhandled_exception() {}
};
#include
struct pair
{
int i;
};
pair
something ()
{
return { 1 };
}
future
my_coro ()
{
auto ret = something ();
assert(ret.i == 1);
auto [ i ] = something ();
assert(i == 1);
co_return 1;
}
int main ()
{
my_coro ();
}
[Bug c++/94701] coroutines: Wrong code for structured bindings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94701 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last reconfirmed||2020-04-21 Target Milestone|--- |10.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||wrong-code
[Bug c++/94682] coroutines: Promise param preview should get a reference to *this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94682 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- fixed.
[Bug c++/94288] co_await in while loop crashes g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94288 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Iain Sandoe --- A test case from the original post was committed as r10-7944-g1d072f3eeac4 (I missed the PR number from the commit) so fixed.
[Bug c++/94752] [coroutines] compiler ICE with coroutine with unnamed parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94752 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-25 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- Created attachment 48372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48372&action=edit fix posted thanks for the report
[Bug c++/94752] [coroutines] compiler ICE with coroutine with unnamed parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94752 Iain Sandoe changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |10.0
[Bug c++/94759] New: coroutines: rejects traits specialisation with non-class returns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94759
Bug ID: 94759
Summary: coroutines: rejects traits specialisation with
non-class returns.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48373&action=edit
fix under test
>From the standard:
The header defines the primary template coroutine_traits such that
if ArgTypes is a parameter pack of types and if the qualified-id
R::promise_type is valid and denotes a type, then
coroutine_traits has the following publicly accessible member:
using promise_type = typename R::promise_type;
this should not prevent more specialised cases and the following code should
be accepted, but is currently rejected with
error: coroutine return type ‘void’ is not a class
#include
template
struct std::coroutine_traits {
struct promise_type {
promise_type (HandleRef h, T ...args)
{ h = std::coroutine_handle::from_promise (*this);
PRINT ("Created Promise");
}
void get_return_object() {}
auto initial_suspend() {
return std::suspend_always{};
}
auto final_suspend() { return std::suspend_never{}; }
void return_void() {}
void unhandled_exception() {}
};
};
void
my_coro (std::coroutine_handle<>& h)
{
PRINT ("coro1: about to return");
co_return;
}
[Bug c++/94759] coroutines: rejects traits specialisation with non-class returns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94759 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2020-04-25
[Bug c++/94760] New: coroutines: mismatch between traits and promise parameter preview.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94760
Bug ID: 94760
Summary: coroutines: mismatch between traits and promise
parameter preview.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48374
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48374&action=edit
fix under test
There was considerable confusion about how the various implementations
had interpreted the passing of 'this' and lambda capture object
pointers to traits lookup and the promise methods (constructor and
allocator)
In response, we changed the argument passed to the promise parameter
preview to match a reference to *this. That has made things inconsistent
and we need to match it in the traits
the following code should compile, but fails unable to find a suitable
promise CTOR.
struct Fake {} ;
template
struct std::coroutine_traits {
struct promise_type {
promise_type (CallOp op, T ...args) {}
Fake get_return_object() { return {}; }
std::suspend_always initial_suspend() { return {}; }
std::suspend_never final_suspend() { return {}; }
void return_void() {}
void unhandled_exception() {}
};
};
struct Foo
{
Fake operator() (int a) {
co_return;
}
};
[Bug c++/94760] coroutines: mismatch between traits and promise parameter preview.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94760 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-25 Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug c++/94771] g++.dg/concepts/diagnostic10.C fails on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94771 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-04-27 --- Comment #1 from Iain Sandoe --- the commit you mention appears to be unrelated to the test fail, please could you identify commit the failure started?
[Bug c++/94752] [coroutines] compiler ICE with coroutine with unnamed parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94752 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Iain Sandoe --- so fixed.
[Bug c++/94794] New: coroutines: Support is needed for symmetric transter on targets without arbitrary indirect tail-calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94794 Bug ID: 94794 Summary: coroutines: Support is needed for symmetric transter on targets without arbitrary indirect tail-calls Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- For symmetric transfers to work with C++20 coroutines, it is currently necessary to tail call the callee coroutine from resume method of the caller coroutine. Unfortunately, several targets have ABI constraints that prevent arbitrary indirect tail-calls which means that we do not have a FE design that works consistently (or at all for O < 2). For some targets, where the tail calls are supported, it's possible to mandate their use for O0 etc, but we'd need a target hook to test this - the existing "ok for sib call" is not usable in the FE.
[Bug c++/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94794 --- Comment #18 from Iain Sandoe --- Fixed, PR 94794 tracks the requirement to add symmetric transfer in a more general manner.
[Bug c++/94794] coroutines: Support is needed for symmetric transter on targets without arbitrary indirect tail-calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94794 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-27 Keywords||ABI
[Bug c++/94701] coroutines: Wrong code for structured bindings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94701 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- fixed on master.
[Bug c++/94759] coroutines: rejects traits specialisation with non-class returns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94759 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Sandoe --- fixed on master.
[Bug c++/94760] coroutines: mismatch between traits and promise parameter preview.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94760 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- fixed on master
[Bug c++/94817] ICE in add_stmt, at cp/semantics.c:392 since r10-6063-g49789fd08378e3ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94817 --- Comment #2 from Iain Sandoe --- patch posted here: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544843.html we are very close to branching for 10, so not sure if this will be included in 10.1
[Bug c++/94829] ICE in poplevel, at cp/decl.c:585 since r10-6063-g49789fd08378e3ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94829 --- Comment #2 from Iain Sandoe --- patch posted here: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544843.html we are very close to branching for 10, so not sure if this will be included in 10.1
[Bug c++/94879] coroutines: ICE building folly in captures_temporary, at cp/coroutines.cc:2707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94879 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.0 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-30 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
[Bug c++/94879] New: coroutines: ICE building folly in captures_temporary, at cp/coroutines.cc:2707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94879
Bug ID: 94879
Summary: coroutines: ICE building folly in captures_temporary,
at cp/coroutines.cc:2707
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48421&action=edit
fix under test
The following code should compile, but fails with
Excess errors:
/src-local/cxx-coroutines/gcc/testsuite/g++.dg/coroutines/folly-1.C:48:39:
internal compiler error: in captures_temporary, at cp/coroutines.cc:2707
libbacktrace could not find executable to open
The problem is that we are not properly accounting for proxy variable cases.
namespace std {
template a b(a &&);
template struct d { c e; };
template struct coroutine_traits : f {};
template struct coroutine_handle;
template <> struct coroutine_handle<> {};
template struct coroutine_handle : coroutine_handle<> {};
struct g {};
} // namespace std
class h {};
class i {
i(i &&);
};
namespace ac {
template class ad {
public:
bool await_ready();
void await_resume();
void await_suspend(std::coroutine_handle<>);
i ae;
};
} // namespace ac
template ac::ad operator co_await(ab);
class j {
class l {};
public:
std::g initial_suspend();
l final_suspend();
};
class m : public j {
public:
void get_return_object();
void unhandled_exception();
};
class n {
public:
using promise_type = m;
};
std::d k;
void a() {
auto am = k;
[&]() -> n { co_await std::b(am.e); };
}
[Bug c++/94883] New: coroutines: ICE building folly in verify_gimple_stmt, at tree-cfg.c:4959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94883
Bug ID: 94883
Summary: coroutines: ICE building folly in verify_gimple_stmt,
at tree-cfg.c:4959
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48423&action=edit
fix under test
The following should compile but produces:
folly-2.C:59:1: internal compiler error: in verify_gimple_stmt, at
tree-cfg.c:4959
The problem here is that target cleanup expressions have been added to the
initialisers for the awaitable (and returns of non-trivial values from
await_suspend() calls. This is because the expansion of the co_await into its
control flow is not apparent to the machinery adding the target cleanup
expressions. The solution being tested is simply to recreate target
expressions as the co_awaits are lowered. Teaching the machinery to handle
walking co_await expressions in different ways at different points (outside the
coroutine transformation) seems overly complex.
===
namespace std {
template struct coroutine_traits : a {};
template struct coroutine_handle;
template <> struct coroutine_handle<> {};
template struct coroutine_handle : coroutine_handle<> {};
struct b {
bool await_ready();
void await_suspend(coroutine_handle<>);
void await_resume();
};
} // namespace std
template auto ab(int ac, d ad) -> decltype(ad.e(ac));
int f;
class h {
class j {
public:
bool await_ready();
void await_suspend(std::coroutine_handle<>);
void await_resume();
};
public:
void get_return_object();
std::b initial_suspend();
j final_suspend();
void unhandled_exception();
template
auto await_transform (g c) { return ab(f, c); }
};
template class k {
public:
using promise_type = h;
using i = std::coroutine_handle<>;
class l {
public:
~l();
operator bool();
};
class m {
public:
bool await_ready();
i await_suspend(std::coroutine_handle<>);
l await_resume();
};
class n {
public:
m e(int);
};
n ah();
};
template
k
my_coro (k am, ai) {
if (auto an = co_await am.ah())
;
}
void foo () {
k a;
my_coro (a, [] {});
}
[Bug c++/94883] coroutines: ICE building folly in verify_gimple_stmt, at tree-cfg.c:4959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94883 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last reconfirmed||2020-04-30 Ever confirmed|0 |1 Keywords||ice-on-valid-code Target Milestone|--- |10.0
[Bug c++/94886] New: coroutines: ICE building folly, in transform_local_var_uses, at cp/coroutines.cc:1908
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94886
Bug ID: 94886
Summary: coroutines: ICE building folly, in
transform_local_var_uses, at cp/coroutines.cc:1908
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48424&action=edit
fix under test
the code below should build but produces an ICE
this is because the range-based for generates three artificial variables that
need to be allocated to the coroutine frame but, when walking the BIND_EXR that
contains these, the DECL_INITIAL for one of them refers to an entry appearing
later, which means that the frame entry hasn't been allocated when that INITIAL
is walked.
The solution is to defer walking the DECL_INITIAL/SIZE etc. until all the
BIND_EXPR vars have been processed.
coro1
my_coro ()
{
const std::array expectedValues = {{0, 3, 1, 4, 2}};
for (int expectedValue : expectedValues) {
co_yield expectedValue;
}
}
[Bug c++/94886] coroutines: ICE building folly, in transform_local_var_uses, at cp/coroutines.cc:1908
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94886 Iain Sandoe changed: What|Removed |Added Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Last reconfirmed||2020-04-30 Target Milestone|--- |10.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/94879] coroutines: ICE building folly in captures_temporary, at cp/coroutines.cc:2707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94879 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- so fixed
[Bug c++/94886] coroutines: ICE building folly, in transform_local_var_uses, at cp/coroutines.cc:1908
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94886 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Sandoe --- so fixed
[Bug c++/94883] coroutines: ICE building folly in verify_gimple_stmt, at tree-cfg.c:4959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94883 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Iain Sandoe --- so fixed
[Bug c++/94897] New: range-for produces a variable initialiser with use of a forward decl.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94897
Bug ID: 94897
Summary: range-for produces a variable initialiser with use of
a forward decl.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
It seems that parser.c:cp_convert_range_for () is not implementing the lowering
that its header comment outlines.
for this:
#include
void
foo ()
{
const std::array expectedValues = {{0, 3, 1, 4, 2}};
for (int expectedValue : expectedValues) {
;
}
}
we are getting the statement tree below, the key being (V = Var decl, Va =
artificial var decl) where the first entry initialiser contains a forward ref.
V int expectedValue = E (std::array5>::value_type)E *VD
foo::__for_begin;
Va const std::array5>& __for_range = E (const std::array5>&)E &foo::expectedValues;
Va const std::array5>::value_type* __for_begin;
Va const std::array5>::value_type* __for_end;
=
FD foo ()
- {
S BIND_EXPR [scope 0x10399a3c0] BLOCK #0 not outer [ao] 0x0
[super-ctx] 0x0 SUBBLOCKS 0x10399a360
VARS {
V const std::array5>expectedValues = {E CE {E 0, E
3, E 1, E 4, E 2}};
}
BODY {
- {
CPs<5>expectedValues = {E CE {E 0,
E 3, E 1, E 4, E 2}}; CPE>>
S BIND_EXPR [scope 0x10399a360] BLOCK #0 not outer [ao] 0x0
[super-ctx] 0x10399a3c0 SUBBLOCKS 0x0
VARS {
V int expectedValue = E (std::array5>::value_type)E *VD
foo::__for_begin;
Va const std::array5>& __for_range = E (const
std::array5>&)E &foo::expectedValues;
Va const std::array5>::value_type* __for_begin;
Va const std::array5>::value_type* __for_end;
}
BODY {
- {
sD const std::array5>& __for_range = E (const
std::array5>&)E &foo::expectedValues;
sD const std::array5>::value_type* __for_begin;
CPs<5>::begin (); CPE>>
sD const std::array5>::value_type* __for_end;
CPs<5>::end (); CPE>>
sS for (; E CE foo::__for_begin != foo::__for_end; CPe<>)
sD int expectedValue = E (std::array5>::value_type)E
*VD foo::__for_begin;
}
}
}
}
[Bug c++/94897] range-for produces a variable initialiser with use of a forward decl.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94897 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |11.0 Last reconfirmed||2020-04-30
[Bug translation/93861] typo in warning: %qs is not valid for %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93861 Iain Sandoe changed: What|Removed |Added Target||*-darwin* Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |11.0 Last reconfirmed||2020-05-02
[Bug translation/93861] typo in warning: %qs is not valid for %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93861 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Iain Sandoe --- thus, fixed, thanks for the report!
[Bug target/91520] AVX512 target assembler fails for x86_64 Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91520 --- Comment #5 from Iain Sandoe --- (In reply to Eric Gallager from comment #4) > (In reply to Iain Sandoe from comment #1) > > > > I plan on publishing an update to my alternate assembler/linker pair that > > incorporates the changes from LLVM-9 and isn't dependent on the release > > schedule for Xcode. > > Have you published this update yet? The back port is on my LLVM-7.1.1 branch on github - so if one builds the "llas" tool (only need to build LLVM, it's not necessary to build clang or any of the libs). then you can use --with-as=/path/to/llas the tool follows cctools command line (plus some llvm additions). Hopefully, I'll bring the 7.x stuff forward to 8.x and also add llas to 9 and 10. (but the 7.1.1 llas is sufficient to bootstrap powerpc, i686 and x86-64). Not sure why I mentioned the linker in this context, there are some useful bug-fixes but not relevant to this PR. Not sure if the LLVM fixes have made it into Xcode yet (but that would only be relevant to 10.14+).
[Bug c++/95003] coroutines: Wrong code for some reference capture cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95003 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Keywords||wrong-code Target Milestone|--- |10.2 Last reconfirmed||2020-05-08 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|UNCONFIRMED |NEW
[Bug c++/95003] New: coroutines: Wrong code for some reference capture cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95003
Bug ID: 95003
Summary: coroutines: Wrong code for some reference capture
cases.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 48479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48479&action=edit
patch under test
The following code does not work correctly, the loop is executed but the loop
body is discarded during gimplifcation.
There are several places where we insert bind expressions while making the
coroutine AST transforms. These should be marked as having side-effects where
relevant, which had been omitted - leading to the fail - since, at least in
some cases, such bind expressions are dropped during gimplification.
struct Awaitable {
int v;
Awaitable (int _v) : v(_v) {}
bool await_ready() { return false; }
void await_suspend(std::coroutine_handle) {}
int await_resume() { return v; }
auto operator co_await() { return *this; }
};
coro1
my_coro
(int x)
{
int sum = 0;
for (unsigned i = 0; i < 100; ++i) {
sum += co_await Awaitable{x+1};
}
co_return sum;
}
[Bug objc++/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013 --- Comment #2 from Iain Sandoe --- please would you identify the platform(s) and configuration conditions? I don't see these on at least x86_64-linux-gnu, powerpc64-linux-gnu (m32, m64) or on Darwin15, 18, 19 (m32, m64) at r11-196
[Bug c++/95017] [coroutines] Failure to generate code for co_yield expression if its the only statement in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95017 Iain Sandoe changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Sandoe --- thanks for the report! (an odd case where it's a single line loop which triggers the reference-capture-lifetime-extension). As luck would have it, this was fixed on master yesterday - and I will be back porting the change to 10.2. *** This bug has been marked as a duplicate of bug 95003 ***
[Bug c++/95003] coroutines: Wrong code for some reference capture cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95003 Iain Sandoe changed: What|Removed |Added CC||lewissbaker.opensource@gmai ||l.com --- Comment #2 from Iain Sandoe --- *** Bug 95017 has been marked as a duplicate of this bug. ***
[Bug objc++/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #4 from Iain Sandoe --- (In reply to Rainer Orth from comment #3) > I'm seeing them too on both sparc-sun-solaris2.11 and i386-pc-solaris2.11. > > My immediate suspicion would be that they are due to Nathan's patch: > > [C++] EOF has a location > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545409.html > > Two of the source files (syntax-error-[89].mm lack a newline at EOF), and in > all > cases the message changed from > > obj-c++.dg/syntax-error-10.mm:1:1: error: expected identifier at end of input > > to > > obj-c++.dg/syntax-error-10.mm:1: error: expected identifier at end of input > > i.e. the column number got lost. yeah, my tests were just a few revisions before that patch - at r11-235 I see these on Darwin too, and it seems to be a case for fixing the tests.
[Bug objc++/95013] [11 Regression] FAIL: obj-c++.dg/property/property-neg-6.mm syntax-error-10.mm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95013 Iain Sandoe changed: What|Removed |Added Assignee|iains at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > (In reply to Rainer Orth from comment #3) > > I'm seeing them too on both sparc-sun-solaris2.11 and i386-pc-solaris2.11. > > > > My immediate suspicion would be that they are due to Nathan's patch: > > > > [C++] EOF has a location > > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545409.html > > obj-c++.dg/syntax-error-10.mm:1: error: expected identifier at end of input > > > > i.e. the column number got lost. > yeah, my tests were just a few revisions before that patch - at r11-235 I > see these on Darwin too, and it seems to be a case for fixing the tests. hmm maybe that's a diagnostics regression with the dangling colon (without the colon it would seem reasonable).
[Bug c++/95003] coroutines: Wrong code for some reference capture cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95003 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Iain Sandoe --- so fixed for master and 10.2
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #1 from Iain Sandoe --- There are some gotchas with coroutines and references (both regular and rvalue). * there could still be a bug here, so I want to double-check. Please could you expand your snippets of code into a small test-case that would would expect to work? (FWIW, in my original impl. I tried to be more defensive about lambda captures - but that wasn't correct in the presence of a mutable lambda - and didn't agree with other implementations - or the collective understanding of the intent of the standard - so I backed that out).
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #4 from Iain Sandoe --- (In reply to Avi Kivity from comment #3) > The test case I uploaded only shows the failure, it won't work if gcc worked > as I expect it. I'll try to get a better testcase, unfortunately a small > coroutine testcase is still some work. yeah, I have some boiler-plate code in headers in the GCC test-suite that can help.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #6 from Iain Sandoe --- (In reply to Avi Kivity from comment #5) > This snippet from cppreference: > > If the coroutine is a non-static member function, such as task > my_class::method1(int x) const;, its Promise type is > std::coroutine_traits, const my_class&, int>::promise_type > > implies that both gcc and my interpretation are wrong. gcc passes a pointer > for the lambda, and I'd like the lambda to be passed by value. The > difference between gcc and cppreference is trivial, and both of them make > coroutine lambdas unusable if they contain state and if the lambda is > asynchronous. ( assuming that this is the problem, I haven't yet had a chance to check * could still be a bug ;) ). I have a pending change to pass a reference to the lambda object to the traits, promise preview and allocator lookups. This was a source of considerable discussion amongst the implementors (GCC, clang, MSVC) about how the std should be interpreted. The change I mention will make the lambda capture object pointer behave in the same manner as 'this' (which was the intended behaviour as determined by the long discussion). MSVC implements this now, and clang will be changing to match it also. That won't solve any lifetime issue with the capture object - you will still need to ensure that it exists for the duration of the coroutine * as you would for a class instance with a method coroutine *. We (at least several of us) agree that this is a source of easy programming errors - and I expect there to be some revisiting in c++23. That's a considerable challenge in the face of a mutable lambda - maybe (thinking aloud) needs something like Apple blocks, but with an automatic promotion of the closure to a heap object if it escapes the creating scope.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #9 from Iain Sandoe --- (In reply to Avi Kivity from comment #8) > Created attachment 48526 [details] > less lame testcase thanks, it's in my queue to look at. FWIW see the note in bullet 13 here: http://eel.is/c++draft/dcl.fct.def.coroutine#13 consider also: gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C where, if the closure object were copied into the coroutine frame, the operation would be incorrect.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #14 from Iain Sandoe ---
(In reply to Ville Voutilainen from comment #12)
> It sure seems to me that a coroutine lambda's captures should be copied to
> the coroutine state. I don't think the standard says that anywhere.
Maybe I am missing your point (some of these things were decided long before I
joined the fray)
Well, the standard is pretty much silent on coros + lambdas. However, the
implementors (Richard, Gor, me, et al) had a long discussion on the topic
before Prague - and took what we could from that to Core.
GCC does not comply with the (agreed in that discussion) intent that the
capture object should be treated in the same manner as 'this', and a reference
passed to the traits lookup, promise parms preview and allocator lookup. I
have a patch for this (will post this week) - but the only implementation with
this correct so far is MSVC
clang passes a ref to the traits but does not pass anything for the closure
object pointer to promise param preview or allocator)
GCC currently passes the object pointer to all three.
The idea of bringing the lambda's captures into the coro frame was what I
originally implemented. Richard pointed out that this is wrong when the lambda
is mutable (see gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C)
so if one has
auto X = [...] () -> some_coro {};
X must exist for the duration of the lambda coro [it was pointed out by Lewis
that really this is only the same as saying that if you have a class with a
member function lambda, the instance of that class has to persist for the
duration of the coro].
We are, I believe, collectively agreed that this is a 'foot gun' (and rvalue
refs doubly so); however, making a better mousetrap here might require some
considerable thought.
I'm happy to be educated if there's some different consensus as to what to do,
and to amend the GCC impl. accordingly.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #19 from Iain Sandoe ---
(In reply to Ville Voutilainen from comment #17)
> (In reply to Ville Voutilainen from comment #16)
> > (In reply to Iain Sandoe from comment #14)
> > > (In reply to Ville Voutilainen from comment #12)
> > > The idea of bringing the lambda's captures into the coro frame was what I
> > > originally implemented. Richard pointed out that this is wrong when the
> > > lambda is mutable (see
> > > gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C)
> > >
> > > so if one has
> > >
> > > auto X = [...] () -> some_coro {};
> > >
> > > X must exist for the duration of the lambda coro [it was pointed out by
> > > Lewis that really this is only the same as saying that if you have a class
> > > with a member function lambda, the instance of that class has to persist
> > > for
> > > the duration of the coro].
> >
> > Ah. So the work-around for this problem is to copy the capture to a local
> > variable, and co_return that; then the local variable is in the coro-state.
> > Right?
>
> That is, instead of writing
>
> [x] {co_return x;}
>
> write
>
> [x] {auto xx = x; co_return xx;}
hmm I'm not sure this is sufficient; if the initial suspend is suspend-always,
and the closure object goes away before the initial resume, then xx will be
initialised with garbage.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #21 from Iain Sandoe --- Avi, If we are agreed that there is no GCC bug here (the change from pointer to reference is already in the queue) I would suggest that new design discussion would be better by putting a paper or suggestions to the WG21 evolution list (and certainly involving folks who are not present 'here'). In which case the bug could be closed.
[Bug c++/95050] coroutine: no "mandatory copy elision" for prvalue await_resume expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95050 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.2 Last reconfirmed||2020-05-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #2 from Iain Sandoe --- Hi Rafael, nor me, the coros implementation is a set of AST transforms - so is supposed to present the following code with valid trees - which would be analysed "as normal".
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 Iain Sandoe changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #9 from Iain Sandoe --- some of the issues noted are likely addressed by patches already in my queue - so taking this for now.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #10 from Iain Sandoe ---
It seems that the ubsan complaints look all rather similar.
At least for the following case, ubsan seems to cause a change which introduces
a bogus temporary use.
class-00-co-ret.C u=is a very simple coroutine - this is the output of
-fdump-tree-gimple for the main body of the actor function.
without ubsan.
_7 = &frame_ptr->__p;
frame_ptr->__aw_s.is = coro1::promise_type::initial_suspend (_7);
[return slot optimization]
_8 = &frame_ptr->__aw_s.is;
_9 = coro1::suspend_always_prt::await_ready (_8);
retval.0 = ~_9;
if (retval.0 != 0) goto ; else goto ;
:
frame_ptr->__resume_at = 2;
_10 = &frame_ptr->__aw_s.is;
coro1::suspend_always_prt::await_suspend (_10,
frame_ptr->__self_h);
D.11053 = .CO_YIELD (2, 0, &resume.2, &destroy.2, frame_ptr);
retval.1 = D.11053;
switch (retval.1) , case 0: , case 1:
>
:
.CO_SUSPN (&actor.suspend.ret);
:
goto resume.2;
:
goto destroy.2;
destroy.2:
_11 = &frame_ptr->__aw_s.is;
coro1::suspend_always_prt::~suspend_always_prt (_11);
goto coro.delete.promise;
:
resume.2:
frame_ptr->__i_a_r_c = 1;
_12 = &frame_ptr->__aw_s.is;
coro1::suspend_always_prt::await_resume (_12);
_13 = &frame_ptr->__aw_s.is;
coro1::suspend_always_prt::~suspend_always_prt (_13);
{
puts ("coro1: about to return");
_14 = &frame_ptr->__p;
coro1::promise_type::return_value (_14, 42);
goto final.suspend;
with ubsan
_7 = &frame_ptr->__p;
frame_ptr->__aw_s.is = coro1::promise_type::initial_suspend (_7);
[return slot optimization]
D.11410 = &frame_ptr->__aw_s.is;
.UBSAN_NULL (D.11410, 4B, 0);
_8 = coro1::suspend_always_prt::await_ready (D.11410);
retval.0 = ~_8;
if (retval.0 != 0) goto ; else goto ;
:
frame_ptr->__resume_at = 2;
D.11413 = &frame_ptr->__aw_s.is;
.UBSAN_NULL (D.11413, 4B, 0);
coro1::suspend_always_prt::await_suspend (D.11413,
frame_ptr->__self_h);
D.11322 = .CO_YIELD (2, 0, &resume.2, &destroy.2, frame_ptr);
retval.1 = D.11322;
switch (retval.1) , case 0: , case 1:
>
:
.CO_SUSPN (&actor.suspend.ret);
:
goto resume.2;
:
goto destroy.2;
destroy.2:
D.11415 = &frame_ptr->__aw_s.is;
.UBSAN_NULL (D.11415, 4B, 0);
coro1::suspend_always_prt::~suspend_always_prt (D.11415);
goto coro.delete.promise;
:
resume.2:
frame_ptr->__i_a_r_c = 1;
D.11416 = &frame_ptr->__aw_s.is;
.UBSAN_NULL (D.11416, 4B, 0);
coro1::suspend_always_prt::await_resume (D.11416);
.UBSAN_NULL (D.11415, 4B, 0);
^^^ this is not correct D.11415 is not valid here, (D.11416 would be).
coro1::suspend_always_prt::~suspend_always_prt (D.11415);
{
puts ("coro1: about to return");
D.11417 = &frame_ptr->__p;
.UBSAN_NULL (D.11417, 4B, 4);
coro1::promise_type::return_value (D.11417, 42);
goto final.suspend;
}
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #11 from Iain Sandoe --- perhaps I have some invalid sharing of trees that only causes an issue for ubsan - will try build independent dtor trees for the two cases.
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #6 from Iain Sandoe --- r11-511 + this patch builds a stage1 debug compiler OK for me (issue reported on irc).
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #13 from Iain Sandoe --- Created attachment 48572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48572&action=edit fix for most of the UBSAN fails Most of the UBSAN fails are from a single cause; I reused the built DTOR tree on both resume and destroy edges from the await. There is a single remaining UBSAN fail (which is unrelated). I don't expect this to make any difference to the initial reported fail.
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #15 from Iain Sandoe --- (In reply to Martin Liška from comment #14) > The original problem: > > test.cc:3749:5: runtime error: member call on misaligned address > 0x41b58ab3 for type 'struct awaiter', which requires 8 byte alignment > 0x41b58ab3: note: pointer points here > > > @Iain: How do you allocate the awaiter object? The coro frame is laid out according to the types determined for the objects it contains (the awaiter types are known at the point it's laid out). It just uses the 'normal' struct building rules. Awaiters are most often initialised from return values from some promise method, but they can also be local vars or parms - perhaps I slipped up there. I have a thought that I might be failing to copy across excess alignment applied (which I will look at later). ^^^ these are things on my TO-LOOK-AT list. > > @Rafael: Can you please append output with: > export UBSAN_OPTIONS="print_stacktrace=1"
