Re: -O4 in SunOS compiler (Fergus James HENDERSON)
Wed, 2 Sep 1992 08:38:37 GMT

          From comp.compilers

Related articles
-O4 in SunOS compiler (Jon Allen Boone) (1992-08-26)
Re: -O4 in SunOS compiler wismuell@Informatik.TU-Muenchen.DE (1992-08-31)
Re: -O4 in SunOS compiler chased@rbbb.Eng.Sun.COM (1992-09-01)
Re: -O4 in SunOS compiler khb@chiba.Eng.Sun.COM (1992-09-01)
Re: -O4 in SunOS compiler (1992-09-02)
-O4 in SunOS compiler (1992-09-03)
Re: -O4 in SunOS compiler (1992-09-04)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Fergus James HENDERSON)
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 2 Sep 1992 08:38:37 GMT
References: 92-08-164 92-09-017
Keywords: sparc, optimize, C

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

Post a followup to this message

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