Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!mckinley!rob
From: rob@mckinley.eng.ohio-state.edu (Rob Carriere)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <1991Apr28.191544.22321@ee.eng.ohio-state.edu>
Date: 28 Apr 91 19:15:44 GMT
References: <RJC.91Apr25134502@brodie.cstr.ed.ac.uk> <22720@lanl.gov> <5079@cernvax.cern.ch>
Sender: news@ee.eng.ohio-state.edu
Organization: The Ohio State University Dept of Electrical Engineering
Lines: 25

In article <5079@cernvax.cern.ch> burow@cernvax.cern.ch (burkhard burow)
writes: 
>jlg@cochiti.lanl.gov (Jim Giles) gives us the example 
[IM alias in C]
>Now lets rewrite this in everybody's favourite language
[same example in FORTRAN]
>Now I just don't get it. If the C compiler/linker/what_ever_you_call_it can't
>optimize the nonalias in func3, and not screw up with the alias in func2,
>what's so magical about FORTRAN? It would seem to be in the same boat.

Nope, it isn't.  FORTRAN simple states that such programs ar illegal.
(undefined behavior is the C standard speak, I'm no longer sure of the
FORTRANesque).  So basically, in FORTRAN you are responsible for staying out
of the compiler's way, and in C it's the other way around.  This makes for
safer programming on the C side of the fence (never thought you'd hear _that_
about C, right :-), but it also makes the C compiler's[1] job _much_ harder.

>hoping somebody reads this line.

I did. :-)

SR
[1] compiler is used here to mean translator+linker+loader.  It was
    convenient, and I feel like Humpty Dumpty today.  :-)
---