optimization/7799: [3.2/3.3 regression] Loop bug with optimization flag -Os in gcc

Andrew Haley aph@redhat.com
Fri Dec 13 06:52:00 GMT 2002


Christian Ehrhardt writes:
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7799
 > 
 > Hi,
 > 
 > this PR is about the following code snippet that is miscompiled with -Os
 > 
 > void fill (int* p, int* q[10])
 > {
 >         int i;
 >         for (i = 0; i < 10; i++)
 >                 *q++ = &p[i];
 > }
 > If p is initially 0x7ffffffc the comparison must be treated as unsigned,
 > however, if p is initially 0xfffffffc the comparison must be treated as
 > signed.

How can p be initially 0xfffffffc ?  On an x86 you'd wrap around zero
and the next &p[i] would return a null pointer.  

malloc() won't return a block of memory that includes address zero.
The only way you could get such an address is to cast an int to a
pointer, in which case it's your responsibility to make sure the
address is valid.

Andrew.



More information about the Gcc mailing list