Re: The "980505-1.c" bug (The Story Continued)

[Carlo Wood <carlo at runaway dot xs4all dot nl>]

I wrote:

| The WEIRD result of adding this *uninitialized* register to the table is
| that reg_in_table[23] is incremented - without any other change:
| 
| reg_tick[23] == 0
| reg_in_table[23] == 0		<-- Just incremented by one

Woops. I concluded this from the comments at the start of cse.c,
but it should of course read:

  The WEIRD result of adding this *uninitialized* register to the table is
  that reg_in_table[23] is set to 0 - without any other change:
  
  reg_tick[23] == 0
  reg_in_table[23] == 0		<-- Just made equal to reg_tick[23]

---

The "libcall" case is just one of the many cases this can happen :/.
I think therefore that Jeffs patch (cvs diff -c3p -r1.39 -r1.40 cse.c)
is not sufficient for the whole family of bugs of this type.

reg_in_table[i] = reg_tick[i]  occurs at one single line in the code.
When I put the following in front of it:

if (reg_tick[i] == 0)
  abort();

then, with Jeffs patch added, "make check-gcc" fails for THOUSANDS of
test cases!  In other words: It is VERY commmon that an expression with
an uninitialized register is validated as having a meaningful value :/.

I am afraid that the only correct way to go is to tackle all different
cases seperately :/.  In the mean time the following "work around" works:

if (reg_tick[i] > 0)
  reg_in_table[i] = reg_tick[i];

instead of just "reg_in_table[i] = reg_tick[i]" thus.

The disadvantage of this is that it is possible to get less then optimal
optimisation.  But I suppose it doesn't happen that often that it makes a
difference ;) (because out of thousands, only one test case really resulted
in a bug; and I expect an equivalent percentage to get less well optimized).

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>