Re: Number of compiler passes

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Fri, 01 Aug 2008 17:26:39 -0800

          From comp.compilers

Related articles
[10 earlier articles]
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-07-28)
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-07-29)
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-07-29)
Re: Number of compiler passes m.helvensteijn@gmail.com (Michiel) (2008-07-29)
Re: Number of compiler passes m.helvensteijn@gmail.com (Michiel) (2008-07-29)
Re: Number of compiler passes barry.kelly@codegear.com (Barry Kelly) (2008-07-30)
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-08-01)
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-08-03)
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-08-03)
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Fri, 01 Aug 2008 17:26:39 -0800
Organization: Compilers Central
References: 08-07-041 08-07-044 08-07-048 08-07-058 08-07-059 08-07-068 08-08-003
Keywords: analysis, optimize, Fortran
Posted-Date: 02 Aug 2008 10:01:42 EDT

Michiel wrote:


> glen herrmannsfeldt wrote:


>>I believe for Fortran INTENT(OUT) dummy variables, you must
>>write first, but you can then read the value just as any other
>>variable. They are not write-only.


> I thought about this. But there is no (easy) way at compile time to figure
> out if a variable has actually been written to. Think of this example:


As I understand it, it is a promise to the compiler
that you won't use the value before setting it.


If you do, you might get the wrong answer.


Compilers might flag it if it can be determined at
compile time, otherwise it is up to the programmer
to get it right.


> int f(out int a) {
> if (rnd(0,10) > 5) {
> a <- 5;
> }
> result <- a; // is this allowed?
> }


> Note:
> * rnd returns a random number
> * <- is the assignment operator
> * the language has no return statement, but rather a result variable


Like Fortran. I usually use READ to read in a variable
such that the compiler can't be sure of its value, but a
random number generator should be fine, also.


>>Among other reasons, Fortran allows either call by reference
>>or call by value result (sometimes called copy-in copy-out).
>>In the latter case, INTENT(OUT) might not do the copy in.
>>It can also affect the way the optimizer works.


> I believe the optimizer could do much with the guarantee that a variable
> will never be read.


> Anyway, there are ways around this, of course. Just assign to a local
> variable first, so you can use the value again.


Or have the compiler do that for you...


The other case that comes up in Fortran is optional arguments.


Subroutines can have optional arguments, with the PRESENT
built-in function to test if the argument exists. If it
doesn't, you can't use the dummy variable at all.


In many cases, it would be convenient to have a default value
when the variable isn't present. The only way with the current
(Fortran 2003) standard is to have a separate variable and copy
the variable yourself. Then copy back before returning.


-- glen



Post a followup to this message

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