https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86983
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
We are doing it wrong, both on documentation and implementation sides.
What matters is taking the address of a label. Looking through goto argument
like the quoted code does is poor logic: as inlining can remap normal labels,
it should be equally able to remap address-taken labels.
In other words: decisions whether some BB or function may be duplicated should
be driven by whether they have address-taken labels, not indirect gotos.
We are inconsistent in whether labels are similar to automatic variables or
function-scope static variables. The documentation explains them mostly as if
they are similar to automatic variables, but then it allows using their
addresses in constant expression context, for which they act similar to static
variables.
We should make the distinction between 'auto' and 'static' labels clear both in
documentation and implementation.
What I suggest is to make labels fully auto-like, implying their addresses are
not constant expressions. Auto labels can be safely remapped during inlining.
For static labels we could require declaring them with 'static __label', and to
keep backwards compatibility also deduce that a label should be static if its
address needs to be usable in a constant expression.
PR 80053 gives an example where we miscompile due to a similar confusion.
Does my proposed way forward make sense?
