On 08/05/2015 08:18 AM, Richard Sandiford wrote:
Building some targets results in a warning about orig_dup[i] potentially
being used uninitialised. I think the warning is fair, since it isn't
obvious that the reog_data-based loop bound remains unchanged between:
for (i = 0; i < recog_data.n_dups; i++)
orig_dup[i] = *recog_data.dup_loc[i];
and:
for (i = 0; i < recog_data.n_dups; i++)
*recog_data.dup_loc[i] = orig_dup[i];
Tested on x86_64-linux-gnu. OK to install?
Thanks,
Richard
gcc/
* reload1.c (elimination_costs_in_insn): Make it obvious to the
compiler that the n_dups and n_operands loop bounds are invariant.
There's a BZ about this issue. 55035.
What I want is to make sure we don't lose track of the false positive in
55035 (caused by a miss jump thread due to aliasing issues).
So perhaps the way forward is to install your change and twiddle the
summary of 55035 in some way that makes it more obvious the bz tracks a
false positive from -Wuninitialized and attach 55035 to the
-Wuninitialized meta bug (24639).
Does that work for you?
Jeff
