This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Found gcc bug while trying to correct another one


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]