https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102088
Bug ID: 102088
Summary: poor uninitialized warning points to an initialized
variable, no note to uninitialized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The uninitialized warning below is valid, but the quality is poor. The message
refers to an 'x' but the caret is under 'z'. There also is no note pointing to
x's declaration, which compounds the confusion.
$ cat z.c && gcc -O2 -S -Wall z.c
int f (int i, int j)
{
int x, y = j, z;
if (i)
z = x;
else
z = y;
return z;
}
z.c: In function ‘f’:
z.c:9:10: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
9 | return z;
| ^
With the patch in
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578130.html installed GCC
does print a helpful note, but the warning still refers to 'z':
z.c: In function ‘f’:
z.c:9:10: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
9 | return z;
| ^
z.c:3:7: note: ‘x’ was declared here
3 | int x, y = j, z;
| ^
The warning should underline the whole return statement, e.g., like so:
9 | return z;
| ^~~~~~~~
but the location of the return statement is the same as that of z. So that
seems like a bug earlier on. The output of -fdump-tree-gimple-lineno shows:
[z.c:9:10] return D.2358;
indicating that this might be a front-end problem. Sure enough, the C front
end in c_finish_return() does this:
case RID_RETURN:
c_parser_consume_token (parser);
if (c_parser_next_token_is (parser, CPP_SEMICOLON))
{
stmt = c_finish_return (loc, NULL_TREE, NULL_TREE);
c_parser_consume_token (parser);
}
else
{
location_t xloc = c_parser_peek_token (parser)->location;
struct c_expr expr = c_parser_expression_conv (parser);
mark_exp_read (expr.value);
stmt = c_finish_return (EXPR_LOC_OR_LOC (expr.value, xloc), <<<
statement location
expr.value, expr.original_type);
goto expect_semicolon;
}
