home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!usc!rutgers!faatcrl!iecc!compilers-sender
- From: chased@rbbb.Eng.Sun.COM (David Chase)
- Newsgroups: comp.compilers
- Subject: Re: -O4 in SunOS compiler
- Keywords: sparc, optimize, C
- Message-ID: <92-09-017@comp.compilers>
- Date: 1 Sep 92 23:10:58 GMT
- References: <92-08-164@comp.compilers> <92-09-003@comp.compilers>
- Sender: compilers-sender@iecc.cambridge.ma.us
- Reply-To: chased@rbbb.Eng.Sun.COM (David Chase)
- Organization: Sun Microsystems, Mt. View, Ca.
- Lines: 25
- Approved: compilers@iecc.cambridge.ma.us
-
- 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
- --
- Send compilers articles to compilers@iecc.cambridge.ma.us or
- {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
-