added: tests for uninit variable warnings

added: tests for uninit variable warnings

[Zack Weinberg]

I've added to the testsuite the files gcc.dg/uninit-[1234].c.  These
are tests for spurious uninitialized variable warnings.  uninit-1.c
and uninit-3.c are understandable weaknesses in data flow analysis.
uninit-2.c is slightly less understandable.  It ought to recognize
that rest_args cannot be nonzero on the first trip through the loop.

uninit-4.c is bizarre: the warning goes away if you remove the '1'
case, or if you replace 'struct operation' by an int, or even if you
make 'struct operation' smaller!  Also, if you take out the default
case _and_ the '1' case, the warning goes away, but it shouldn't (what
if cpp_lex returns 3?)

The tests are marked XFAIL - all systems.  I'm interested to know if
they pass on anyone's machine.

Note that any improvements that lead to uninit-[123] passing will
probably also lead to better loop optimization.

zw

Re: added: tests for uninit variable warnings

[Jeffrey A Law]

  In message < 199903120010.TAA03507@blastula.phys.columbia.edu >you write:
  > uninit-4.c is bizarre: the warning goes away if you remove the '1'
  > case, or if you replace 'struct operation' by an int, or even if you
  > make 'struct operation' smaller!  Also, if you take out the default
  > case _and_ the '1' case, the warning goes away, but it shouldn't (what
  > if cpp_lex returns 3?)
Not weird at all.  Changing the numberof cases or density of the switch may
cause the compiler to emit it as a series of cascaded if/else statements which
the compiler is better able to analyze.

Structures also present some interesting problems to the uninitialized
variable analysis.  It's quite a bit more difficult for the compiler to
determine that an entire structure has been initialized as opposed to a simple
integer or floating point variable.


  > The tests are marked XFAIL - all systems.  I'm interested to know if
  > they pass on anyone's machine.
They probably will pass on some machines because of differences in switch
table density threshholds (at least uninit-4)

jeff

Re: added: tests for uninit variable warnings

[Jeffrey A Law]

  In message < 199903120010.TAA03507@blastula.phys.columbia.edu >you write:
  > uninit-4.c is bizarre: the warning goes away if you remove the '1'
  > case, or if you replace 'struct operation' by an int, or even if you
  > make 'struct operation' smaller!  Also, if you take out the default
  > case _and_ the '1' case, the warning goes away, but it shouldn't (what
  > if cpp_lex returns 3?)
Not weird at all.  Changing the numberof cases or density of the switch may
cause the compiler to emit it as a series of cascaded if/else statements which
the compiler is better able to analyze.

Structures also present some interesting problems to the uninitialized
variable analysis.  It's quite a bit more difficult for the compiler to
determine that an entire structure has been initialized as opposed to a simple
integer or floating point variable.


  > The tests are marked XFAIL - all systems.  I'm interested to know if
  > they pass on anyone's machine.
They probably will pass on some machines because of differences in switch
table density threshholds (at least uninit-4)

jeff

added: tests for uninit variable warnings

[Zack Weinberg]

I've added to the testsuite the files gcc.dg/uninit-[1234].c.  These
are tests for spurious uninitialized variable warnings.  uninit-1.c
and uninit-3.c are understandable weaknesses in data flow analysis.
uninit-2.c is slightly less understandable.  It ought to recognize
that rest_args cannot be nonzero on the first trip through the loop.

uninit-4.c is bizarre: the warning goes away if you remove the '1'
case, or if you replace 'struct operation' by an int, or even if you
make 'struct operation' smaller!  Also, if you take out the default
case _and_ the '1' case, the warning goes away, but it shouldn't (what
if cpp_lex returns 3?)

The tests are marked XFAIL - all systems.  I'm interested to know if
they pass on anyone's machine.

Note that any improvements that lead to uninit-[123] passing will
probably also lead to better loop optimization.

zw