This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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


2018-06-27 21:34 GMT+02:00 Thomas Koenig <tkoenig@netcologne.de>:
>
> And we are not going to change Fortran semantics. And I also oppose
> defining our own subset of Fortran in the hope that people will make
> fewer mistakes.
>
> A function is something that produces a value.  If the value is not
> needed to produce the correct result, the function need not be called.

That's a bit oversimplified, isn't it?

The thing that you're talking about, producing a only a value and
nothing else, is actually a pure function. In general a function can
be much more than that: It can not only produce a single value, but
several ones via intent(out) arguments, it can do I/O, it can modify
global/module state. I'd rather say a function is the same as a
subroutine, but with a return value (in addition to everything a
subroutine can do).

And I neither want to change Fortran semantics, nor define my own
subset of Fortran. The primary thing I'm hoping for is a certain level
of compiler-independence, which is supposed to be a central point of
any kind of 'standard'.

So, since it's so incredibly hard to come to any kind of agreement
here, maybe we can come back to the central part of your original
patch, namely throwing a warning for constructs that can not be
guaranteed to be executed in a compiler-independent fashion, i.e.
logical expressions with impure functions.

The patch I proposed at
https://gcc.gnu.org/ml/fortran/2018-06/msg00160.html is the bare
minimum that I hope we can agree upon. Does anyone see any problems
with this, or can I possibly get an ok for committing this to trunk?

Cheers,
Janus


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