From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlo Wood To: egcs@cygnus.com Cc: law@cygnus.com Subject: Re: The "980505-1.c" bug (The Story Continued) Date: Fri, 10 Jul 1998 23:00:00 -0000 Message-id: <199807110128.DAA16618@jolan.ppro> References: <199807100056.CAA11845@jolan.ppro> X-SW-Source: 1998-07/msg00407.html 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