Uninitialized variable warnings

[Zack Weinberg]

I have gone through all the uninitialized variable warnings in a
bootstrap of current CVS and classified them.  The majority are
the documented case where gcc gets it wrong:

if(flag) var = value;
...
if(flag) use(value);

although there are a number of cases where I can't prove this due to
extreme code obfuscation.  (Who was it wrote all those 6000 line
functions, anyway?)

There are a number of other places where gcc has gotten it wrong, and
a few places where the warning indicates a real bug.  There's also one
worrisome case, where we get it right or not unpredictably:

if(x == THING_1) var = val1;
else if(x == THING_2) var = val2;
else if(x == THING_3) var = val3;
...
else abort();
...
use(var);

or the equivalent

switch(x)
{
  case THING_1: var = val1; break;
  case THING_2: var = val2; break;
  case THING_3: var = val3; break;
  ...
  default: abort();
}
...
use(var);

This is documented to work correctly.

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

combine.c	find_split_point	inner
combine.c	find_split_point	pos
combine.c	find_split_point	unsignedp
integrate.c	subst_constants		op0_mode
regmove.c	fixup_match_1		dst_note
regmove.c	fixup_match_1		insn_const
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 --
cp/call.c	add_function_candidate	    convs
graph.c		node_data		    result
java/verify.c	verify_jvm_instructions	    oldpc
objc/objc-act.c	add_objc_string		    chain
objc/objc-act.c	build_keyword_selector	    key_name
objc/objc-act.c	build_message_expr	    sel_name
objc/objc-act.c	build_selector_expr	    selname
objc/objc-act.c	gen_declarator		    str
objc/objc-act.c	generate_protocol_list	    expr_decl
objc/objc-act.c	get_objc_string_decl	    chain
objc/objc-act.c	synth_id_with_class_suffix  string
reload1.c	reload			    is_scalar
varasm.c	const_hash		    hi

The objc ones are all assumptions that a parameter can only have some
limited range of values - which may be true if the data structure is
correct, but gcc can't know that and it isn't especially robust.  The
rest are odd corner cases or oversights.

-- spurious warnings indicating a bug in the compiler --
objc/objc-act.c	generate_protocol_list	plist
optabs.c	emit_cmp_insn		wider_mode
optabs.c	expand_float		libfcn
integrate.c	expand_inline_function	copy
integrate.c	save_for_inline_copying	copy

We get near-identical cases right.  We ought to get these right too.

-- spurious warnings, not the documented case --
java/class.c	build_utf8_ref		field
java/decl.c	init_decl_processing	field
java/verify.c	verify_jvm_instructions	last
java/verify.c	verify_jvm_instructions	prevpc
optabs.c	expand_binop		carry_in
optabs.c	expand_binop		carry_out
reg-stack.c	convert_regs		insn
reload1.c	emit_reload_insns	where

These warnings are spurious but (in most cases) gcc would have to be a
lot cleverer than it is to get them right.  In some cases it would
need to know things about functions other than the one currently being
compiled.

-- probably the documented spurious case --
cse.c		cse_insn		src_eqv_hash
cse.c		cse_insn		src_eqv_in_memory
cse.c		cse_insn		src_eqv_in_struct
cse.c		cse_insn		src_eqv_volatile
loop.c		move_movables		first
reload1.c	choose_reload_regs	mode
reload1.c	emit_reload_insns	store_insn
reload1.c	reload_combine		const_reg
stmt.c		expand_end_case		maxval
stmt.c		expand_end_case		minval
stmt.c		expand_end_case		range
varasm.c	output_constructor	byte
unroll.c	unroll_loop		local_label

Logic in these functions is too convoluted for me to be sure,
but I think these are just the documented spurious warning.  Again,
I'd like someone who understands these sections of the compiler to
review.

-- spurious warnings matching the documented case --
combine.c	simplify_if_then_else	c1
combine.c	simplify_if_then_else	op
combine.c	try_combine		i2_code_number
combine.c	try_combine		other_code_number
cse.c		cse_insn		sets
dbxout.c	dbxout_block		blocknum
fold-const.c	fold (MULT_EXPR)	alt0
fold-const.c	fold (MULT_EXPR)	alt1
fold-const.c	make_range		arg0
fold-const.c	make_range		arg1
function.c	instantiate_virtual_regs_1	offset
genopinit.c	gen_insn		m1
genopinit.c	gen_insn		m2
genopinit.c	gen_insn		op
integrate.c	mark_stores		mode
libgcc2.c	throw_helper		handler_p
libgcc2.c	throw_helper		pc_p
local-alloc.c	block_alloc		r1
loop.c		check_dbra_loop		comparison_val
loop.c		load_mems		end_label
loop.c		recombine_givs		life_end
loop.c		recombine_givs		life_start
loop.c		strength_reduce		increment
objc/objc-act.c	build_selector_translation_table    decl
optabs.c	expand_binop		op0_xhigh
optabs.c	expand_binop		op1_xhigh
reg-stack.c	record_asm_reg_life	clobber_reg
reg-stack.c	subst_asm_stack_regs	clobber_loc
reg-stack.c	subst_asm_stack_regs	clobber_reg
regmove.c	fixup_match_1		set2
reload.c	decompose		base
reload.c	find_valid_class	best_class
sched.c		schedule_block		regs_sometimes_live
sched.c		schedule_block		sometimes_max
splay-tree.c	splay_tree_insert	comparison
stupid.c	stupid_life_analysis	chain
unroll.c	copy_loop_body		copy
unroll.c	unroll_loop		unroll_type
varasm.c	assemble_variable	size_tree

These are uninteresting.

zw