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