Re: -O4 in SunOS compiler

chased@rbbb.Eng.Sun.COM (David Chase)
Tue, 1 Sep 1992 23:10:58 GMT

          From comp.compilers
Related articles
-O4 in SunOS compiler jb3o+@andrew.cmu.edu (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 fjh@mundil.cs.mu.OZ.AU (1992-09-02)
-O4 in SunOS compiler dolf@toet.echo.tds.philips.nl (1992-09-03)
Re: -O4 in SunOS compiler Alfred.Kayser@dnpap.et.tudelft.nl (1992-09-04)
| List of all articles for this month |
Newsgroups: comp.compilers
From: chased@rbbb.Eng.Sun.COM (David Chase)
Organization: Sun Microsystems, Mt. View, Ca.
Date: Tue, 1 Sep 1992 23:10:58 GMT
Keywords: sparc, optimize, C
References: 92-08-164 92-09-003

wismuell@Informatik.TU-Muenchen.DE (Roland Wismueller) writes:
>So -O4 has several consequences:
      ...
> * The compiler may produce 'wrong' code


>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.)


David Chase
Sun
--

Post a followup to this message

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