This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Found gcc bug while trying to correct another one
- To: egcs at cygnus dot com
- Subject: Found gcc bug while trying to correct another one
- From: Martin Kahlert <martin dot kahlert at mchp dot siemens dot de>
- Date: Fri, 5 Jun 1998 15:35:44 +0200
- Cc: egcs-bugs at cygnus dot com
Hi,
i'm new to gcc-hacking but tried to figure out, what causes this
bug: (-O2 has to be used)
#include <stdio.h>
int main(int argc,const char *argv[])
{
int i;
for(i=3;i<10;i++);
if(i==10)
puts("OK");
else
printf("not ok: %d != 10\n",i);
return 0;
}
The problem is: the loop for(i=3;i<10;i++); is first reversed
by check_dbra_loop() to something like
for(i=6;i>=0;i--); (that's o.k, since i is marked as reversed).
Then the loop goes through strength_reduce and this info is lost
at the line
loop_iv_list = 0;
near the start of this routine.
>From now on the reversed loop appears as if it had been
written that way originally.
Thus end value will be computed by final_biv_value()
(the new iteration variable i has reversed-field not set!) and
it correctly calculates the value 7.
Thus the problem is, that the info about the reversed loop is
thrown away in strength_reduce().
Then I wanted to check, why the line
loop_iv_list = 0;
did not look like that:
for (bl = loop_iv_list; bl;)
{
obfree(bl);
tmp=bl->next;
bl=tmp;
}
The reason is: You get a segfault.
When I put in this:
{
struct iv_class *bl;
for (bl = loop_iv_list; bl; bl = bl->next)
{
printf("%d : ",(int)bl);
fflush(stdout);
printf("%d\n",bl->reversed);
fflush(stdout);
}
}
I got a segmentation Fault during the make step of gcc
(Signal 11) in
/home/kahlert/LOCAL/obj/gcc/xgcc
-B/home/kahlert/LOCAL/obj/gcc/ -DIN_GCC -DUSE_GNULIBC_1
-g -O2 -I./include -I. -I/home/kahlert/LOCAL/egcs-19980531/gcc
-I/home/kahlert/LOCAL/egcs-19980531/gcc/config \
-c /home/kahlert/LOCAL/egcs-19980531/gcc/objc/hash.c -o objc/hash.o
with the final output
136451592 : 1
140 : xgcc: Internal compiler error: program cc1 got fatal signal 11
So somebody seems to overwrite the next-field in the biv at
address 136451592 with 140.
This looks like a further gcc bug to me,
which hasn't anything to do with my bug.