This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Hi Janus,


I don't think it's ok to not evaluate expressions that have side
effects


The Fortran standard disagrees with you (as you know, this has
been quoted previously).

Evaluating a function in such a case is a missed optimization.

> but as long as it is guarded by a non-default
> optimization flag, I'm perfectly happy with optimizing away stuff with
> side effects as well.

Why would we need a non-default flag for an optimization that is
perfectly OK with the language standard?

I think we should follow the example of -fstrict-aliasing: Optimize by
default according to what the language rules permit, and warn (with
a flag included with -Wall) if we do so.  I had always thought this
to be the gcc way. Or would you also like to change the behavior of
this flag?

Regards

	Thomas
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]