Hi Jason > On 11 Jun 2025, at 23:50, Jason Merrill <ja...@redhat.com> wrote: > > On 6/9/25 4:12 PM, Iain Sandoe wrote:
>> There was some discussion of this in the PR116775 comments. In the >> end I have matched what clang does in this circumstance, since that >> seems reasonable - and we may ignore the attributes as needed. >> + warning_at (loc_n, OPT_Wattributes,"assumption ignored" >> + " because it contains possible side-effects"); >> + *stmt = build_empty_stmt (loc_n); >> + } >> + } > > Why is this in coroutines.cc? Because, at the moment I am not sure where else it can be handled ( although I have now a semi-propsal, below ). await expressions, when [normally] lowered, depend on and effect the state of the function (that is, they are lowered to something that alters the code of the function - which cannot work in the intent of an assumption). we are permitted to ignore these attributes, and therefore punting on them when they contain await expressions seemed a reasonable initial stance. > We do badly at assume of even trivial calls > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118995) but any warning about > that should be emitted by the code that chooses to give up, not in the front > end. I see. So i’ve read more of the assumption machinery code. Perhaps I could mark any await expression inside an assumption and then expand it thus: ({ awaiter_type aw; if (!aw.await_ready()) { aw.await_suspend (h); goto suspend_return; } aw.await_resume (); }) NOTE1; This is not connected in any way to the coroutine state machine; the presence of an assumption cannot have any cognisance of the multiple possible invocations. We cannot connect this to the state machine without altering the code-gen (at least, I did not currently try to invent some way to do it at compile-time only) NOTE2: There’s no destruction pathway - because of 1 - we’d have to figure out how to dispatch to it at compile-time [this all sounds like function-level flow-dependent analysis - and that does not seem to me to be what assumptions are doing]. NOTE3: Since the current implementation of assumption check functions renders any jump out of the test block as a ‘return false’ whether the await suspend might return a handle to which we’d jump or whether it returns via suspend (void), or whether it re-starts the dispatch (bool) - all of these would end up with the false return from the assumption check function. So… that is my semi-proposal: 1) does it seem that it might be any more use than just punting? 2) any other ideas? cheers Iain
