Re: -O4 in SunOS compiler

chased@rbbb.Eng.Sun.COM (David Chase) writes:
>>The last item is common to all optimizing compilers (at least for C),
>>since aliasing analysis relies on some assumptions that must hold for a
>>program, e.g. the sequence 'p = &i; *(p+offset) = 123;' will access (a
>>component of) i, but no other variable. Of course, you cannot enforce this
>>in C.
>
>What you have there is a case of "undefined behavior" (as specified by the
>ANSI and ISO C language standards). When this is the case, it is not
>"wrong" to produce code that has different results depending upon the
>optimization level. Detecting such code is difficult, but not impossible.
>(Example implementation -- generate a map for all of memory, and check
>each instance of pointer arithmetic and dereferencing to ensure that it
>conforms to the C standard. You may find this too costly, but it is not
>at all impossible.)


No, it *is* impossible.
For example:


int i = 1, j = 2; /* &j == &i + 1 */
int *p = &i;
if (fermats_theorem_is_false()) *(p+1) = 3;
printf("%d %d\n", i, j);


in this case, it is not possible for the compiler to determine whether the
statement *(p+1) = 3 will ever be executed or not. The best the compiler
can do is issue a warning "execution of this statement would cause
undefined behaviour". Similarly it is easy to come up with examples where
the best the compiler can do is issue a warning "execution of this
statement *might* cause undefined behaviour", eg. something like
*(p + somefunc()) = 3;
where the compiler cannot detect whether somefunc() will return 0, return 1,
or loop forever.
--
Fergus Henderson fjh@munta.cs.mu.OZ.AU
--

Return to the comp.compilers page.
Search the comp.compilers archives again.