More exactly, what is undefined is to jump inside the statement
expression with a computed goto.
Of course, once the address of such a label is taken, it's generaly
impossible to track if it will be used or not to jump inside the
statement expression.
So, for now, handle taking the address of such a label from outside
the statement expression, exactly as if a computed goto is effectively
done from there and so issue an error message and also mark the function
as useless for linearization.
Note: this is only partially correct since:
1) the address could be taken from outside the statement
and never used for a computed goto.
2) the address could be taken from outside the statement
but the corresponding computed goto only done from
inside, which is perfectly fine.
3) the address could be taken from inside but a computed
goto done from outside.
Note: the real problem, like for the regular goto, is that the
statement expression can be eliminated before linearization,
the correspondng gotos corresponding then to branches to
unexistent BBs.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx>
---
expression.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/expression.c b/expression.c
index f8a8f03e7402..bbbc24e6b561 100644
--- a/expression.c
+++ b/expression.c
@@ -691,6 +691,7 @@ static struct token *unary_expression(struct token *token, struct expression **t
sym->ctype.modifiers |= MOD_ADDRESSABLE;
add_symbol(&function_computed_target_list, sym);
}
+ check_label_usage(sym, token->pos);
label->flags = CEF_ADDR;
label->label_symbol = sym;
*tree = label;
--
2.26.2
