On 10/21/21 1:02 PM, Andrew MacLeod via Gcc-patches wrote:
As I'm tweaking installing ranger as the VRP2 pass, I am getting a stage
2 bootstrap failure now:
In file included from
/opt/notnfs/amacleod/master/gcc/gcc/fortran/trans-decl.c:28:
/opt/notnfs/amacleod/master/gcc/gcc/tree.h: In function ‘void
gfc_conv_cfi_to_gfc(stmtblock_t*, stmtblock_t*, tree, tree, gfc_symbol*)’:
/opt/notnfs/amacleod/master/gcc/gcc/tree.h:244:56: error: ‘rank’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
244 | #define TREE_CODE(NODE) ((enum tree_code) (NODE)->base.code)
| ^~~~
/opt/notnfs/amacleod/master/gcc/gcc/fortran/trans-decl.c:6671:8: note:
‘rank’ was declared here
6671 | tree rank, idx, etype, tmp, tmp2, size_var = NULL_TREE;
| ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1136: fortran/trans-decl.o] Error 1
looking at that function, in the middle I see:
if (sym->as->rank < 0)
{
/* Set gfc->dtype.rank, if assumed-rank. */
rank = gfc_get_cfi_desc_rank (cfi);
gfc_add_modify (&block, gfc_conv_descriptor_rank (gfc_desc), rank);
}
else if (!GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (gfc_desc)))
/* In that case, the CFI rank and the declared rank can differ. */
rank = gfc_get_cfi_desc_rank (cfi);
else
rank = build_int_cst (signed_char_type_node, sym->as->rank);
so rank is set on all paths here. However, stepping back a bit,
earlier in the function I see:
if (!sym->attr.dimension || !GFC_DESCRIPTOR_TYPE_P (TREE_TYPE
(gfc_desc)))
{
tmp = gfc_get_cfi_desc_base_addr (cfi);
gfc_add_modify (&block, gfc_desc,
fold_convert (TREE_TYPE (gfc_desc), tmp));
if (!sym->attr.dimension)
goto done;
}
The done: label occurs *after* that block of initialization code, and
bit furtehr down , I see this:
gfc_add_modify (&loop_body, tmpidx, idx);
stmtblock_t inner_loop;
gfc_init_block (&inner_loop);
tree dim = gfc_create_var (TREE_TYPE (rank), "dim");
I cannot convince myself by looking at the intervening code that this
can not be executed along this path. Perhaps someone more familiar with
the code can check it out. However, It seems worthwhile to at least
initialize rank to NULL_TREE, thus we can be more likely to see a trap
if that path ever gets followed.
And it makes the warning go away :-)
OK?
Initializing variables on declaration is commonly recommended
as a best C/C++ etc. programming practice. If it silences
a warning and makes the code more readable, who could possibly
say no? ;)
Andrew
PS as a side note, it would be handy to have the def point *and* the use
point that might be undefined. Its a big function and it took me a
while just to see where a possible use might be.
The use point should be the what the warning points to. In
the case above it's the result of macro expansion so it less
than helpfully points to the macro definition. I would expect
it to also point to its expansion like in other warnings.
Something must be interfering with it. I've opened pr102887
to remind us to look into it.
Martin
