https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126014
--- Comment #3 from Rod Kay <rodakay5 at gmail dot com> --- Thanks for taking a look, and understood on the policy — please treat the patch as a proof-of-concept that localises the root cause, not as a submission; consider it withdrawn. What I hope stays useful is the bug report and the minimal reproducer (asyncfn5): a stock compiler can confirm the wrong-slot dispatch from the -gnatD dump, and 'prove_fix.adb' shows the primary-vs-interface view discrepancy with no PCS involved. Agreed that it's likely not the end of the road. The receiver rebuilds the controlling object from a marshalled address with no static concrete type, which seems like one visible symptom of interface types not being fully handled in the Annex E path. On the canonical idiom: that was my first instinct too. The snag was that Flag_Interface_Pointer_Displacement needs a typed conversion operand to derive the offset, and the receiver only has the raw address (the concrete type lives in another partition), so I fell back to a runtime displacement. If the right direction is to restructure the receiver so a proper interface conversion is possible, I'm glad to leave that design and implementation to you. Thanks again for the pointers.
