Re: Uninitialized variable warnings

[Joern Rennecke <amylaar@cygnus.co.uk>]

> I've added some more test cases to the testsuite.  I will be sending
> patches for the real bugs and the documented failures shortly.  If
> people could look at the questionable cases, I'd appreciate it.
> 
> The list:
> 
> -- possibly real bugs --
> file		function		variable
...
> regmove.c	fixup_match_1		dst_note

No bug here.  The use of dst_note depends on (success != 0) .  Success is
initialized to 0, and only set to 1 in a code path where dest_note is
initialized.

> regmove.c	fixup_match_1		insn_const

No bug here, either.  Early in the function, either code is set to NOTE,
or insn_const is set, or the function returns early.
insn_const is never used if code is NOTE.

> reload.c	find_reloads		goal_alternative_number
> reload.c	find_reloads		goal_earlyclobber
> 
> I think these may be real bugs, but the logic is so convoluted that I
> can't be sure one way or the other. I'd appreciate people more
> familiar with these parts of the compiler looking at them.
> 
> -- definitely real bugs --
...
definitely not!

> reload1.c	reload			    is_scalar

is_scalar is always set when reg_equiv_memory_loc[i] is non-zero.
addr is only set when reg_equiv_mem[i] or reg_equiv_address[i] is non-zero.

One of the latter two is always non-zero if reg_equiv_memory_loc[i] is
non-zero (of course the compiler doesn't know about that when compiling
itself, which just goes to show that -Wuninitialized can't work quite
right without solving the halting problem).

is_scalar is only used when addr is set.

> varasm.c	const_hash		    hi

This is pretty straightforward setting hi in both arms of an if-else
or even unconditionally in each of the disjoint lifetimes.