Re: -O4 in SunOS compiler

Alfred.Kayser@dnpap.et.tudelft.nl (Alfred Kayser)
Fri, 4 Sep 1992 08:01:40 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: Alfred.Kayser@dnpap.et.tudelft.nl (Alfred Kayser)
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Fri, 4 Sep 1992 08:01:40 GMT
References: 92-09-017 92-09-032
Keywords: sparc, optimize, C, comment

dolf@toet.echo.tds.philips.nl (Dolf Grunbauer) writes:


>David Chase wrote:
>>> * The compiler may produce 'wrong' code ...
>An interesting simple program might be the following C code.
>Depending on the level of optimalisation the answer varies.
>I tested this on Sun 4.1.1..
>Options -g, -O and -O2 give a 1 while -O3 and -O4 give 2.
>(This program has previously been dealt with in comp.lang.c):


Program deleted...


statement of importance: dummy(x.func(&x), x.func(&x));


You've demonstrated why it is bad practice to call functions, with
side-effects (ie they change the global status from within) in a context
where the exact calling sequence is undefined... Functions called to
produce arguments for another function can be called in random order...


Even this statement would produce unprodictable answers:
dummy(x.val, x.func(&x));
as it is not defined that x.func is called after or before the value of
x.val is pushed on the stack...


About the optimization problems, the problem with misusing pointers
(aliasing things) is that not the optimizer goes wrong, but you did. Al
these examples of code which produce unprodictable answers, are very fine
examples of very bad programming practise. Even the best compilers can be
fooled...


Alfred
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
[Enough already, we all know that it's easy to write C programs with
--


Post a followup to this message

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