Odpověď na názor

Ted netuším, na kterou část reagujete.

Víceméně se implementace GCC a Clang neliší, nebo jen v nuancích. Clang mi přijde, že generuje o pár procent menší framy a optimálnější kód v řádu promile, než GCC. Clang umí rozbalit a optimalizovat různé konstrukce awaiterů, takže nakonec to co má několik desítek řádek kódu se smrskne na jednu instrukci. Přepínání framů umí lépe optimalizovat Clang, který mezi corutinama skáče instrukcí JMP. Zatímco GCC někdy nezvládne TCO a vytváří zbytečně zásobníkové framy, ale naštěstí se tak neděje při symetrickém transferu, o tom snad ještě napíšu.

Obecně třeba s výpočtem velikosti frame je problém, že jeho velikost se spočítá až po optimalizaci kódu, kdy už musí být všechny konstanty známy. Tohle číslo pak tedy pouze propadne do operátoru new pro alokaci jako "ne-konstanta" (není to constexpr)

GCC oproti tomu má několik ještě neopravených a nepochopitelných bugů, které se v clangu nijak neprojevují. Jako je dost znát, že to má dětské nemoci, protože jako Clang, tak GCC umí nevhodně napsaným kódem sestřelit na SIGSEGV

Jak to dělá Visual C++ netuším, neměl jsem tu čest.

V ostatních "problémech" - něco definuje norma, ale platí, že to co norma nedefinuje (například MT Safe u korutin), to je UB. Je třeba se vyhnout takové situaci - synchronizovat