https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123600
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
&&label extension is meant to be used with computed goto.
If there is no computed goto that could possibly branch to those, the labels
will be defined somewhere, but the compiler doesn't guarantee where exactly
within the function, it can be around the spot where user put it, but might
not.
If there are computed gotos (which could have used that particular &&label
value), then the compiler has an abnormal edge from the computed goto to the
basic block starting at the user label referenced in &&label (well, under the
hood it is actually abnormal edge to a magic bb and from the magic bb to the
label, so that with 1000 such labels and 1000 computed gotos there aren't
million edges but just 2000).
If there is no such edge, optimizations could merge basic blocks and move the
label somewhere else, or e.g. in RTL can turn a CODE_LABEL into NOTE with
NOTE_DELETED_LABEL etc.
