Am 16. Juni 2018 23:14:08 MESZ schrieb Thomas Koenig <tkoe...@netcologne.de>:
>Hi Janus,
>
>> I happen to hold the opinion that optimizing out a call to a pure
>> function may be reasonable if it does not influence the result of an
>> expression, but optimizing out an effectively impure function (i.e.
>one
>> with side effects) is not a good idea at any time, since such an
>> 'optimization' can drastically change the program flow and all
>numerical
>> results of a piece of code.
>
>Well, I am of a different opinion
Of course opinions can differ. But could you explain what in my above
statements sounds unreasonable to you? Otherwise it's hard to have an
argument-based discussion.
>and so is the Fortran standard.
I don't think anything I wrote is in conflict with the standard. As I see it,
the standard neither demands nor forbids short-circuiting. I'm just trying to
fill that void in a reasonable way (having as much optimization as possible
without altering results).
>I think the compiler should strive to, in that order,
>
>- conform to the language standard
>- generate fast programs
>- warn about features which may trip the user
I certainly agree to all of that, with the amendment that generating correct
results should have precedence over generating fast programs.
>In my patch, I have tried to do all three things at the same time, and
>after this discussion, I still think that this is the right path
>to follow.
>
>So, here is an update on the patch, which also covers ALLOCATED.
>
>Regression-tested. OK?
I absolutely welcome the warnings for impure functions as second operand to
.and./.or. operators, but (as noted earlier) I disagree with changing the
ordering of operands. As our lengthy discussions show, things are already
complicated enough, and this additional optimization just adds to the confusion
IMHO.
Cheers,
Janus
