Re: [patch, fortran] Handling of .and. and .or. expressions

[Janus Weil <janus at gcc dot gnu dot org>]

2018-06-28 13:59 GMT+02:00 N.M. Maclaren <nmm1@cam.ac.uk>:
> On Jun 28 2018, Janus Weil wrote:
>>
>> You mean compilers which transform "if (func() .and. flag)" into "if (flag
>> .and. func())", and then possibly remove the call? If yes, could you tell us
>> which compilers you are talking about specifically?
>
> I am 70, and haven't supported multiple compilers for over a decade!
> No, I can't remember.  If I recall, the most widespread optimising
> compiler of the 1980s did (IBM Fortran Q), as well as several others of
> that era.

I am roughly half your age, so the 80s for me fall under the category
"a really long time ago" ;)

Unfortunately I have no access to the IBM compiler, plus I have no
idea which other compilers were relevant in that era (I was more into
dinosaurs at that time and had no idea about programming yet ;)

If anyone can point me to a present-decade compiler which does this,
I'll be happy to add the warning.


>> Btw, effectively pure functions which are not marked with the PURE
>> attribute should hopefully not be a problem, since gfortran has
>> implicit_pure detection that should deal with that. (However, it might
>> need some further improvements, I think.)
>
> Most practical programmers use external libraries, often supplied as
> binary.  The only information the compiler can rely on is whether the
> function is marked as PURE.
>
> It's moot whether such a warning should rely on implicit pure detection,
> because the gotcha with doing so is the programmer modifies the function,
> adds a side-effect, does NOT recompile the calling code, and can't work
> out why nothing has changed!  Been there - done that :-)  Response to
> self on locating it: you IDIOT, Nick!

I hope that nowadays the necessity for such self-insults is
significantly decreased as more people use a proper build system
(which takes care of dependencies and rebuilds everything as needed).
cmake does a pretty good job with this by now, in particular in
connection with gfortran. So I wouldn't put too much weight into this
argument ...

Cheers,
Janus