2018-06-29 9:28 GMT+02:00 Jakub Jelinek :
> On Thu, Jun 28, 2018 at 07:36:56PM -0700, Steve Kargl wrote:
>> === gfortran Summary ===
>>
>> # of expected passes47558
>> # of unexpected failures6
>> # of expected failures 104
>> # of unsupported tests
On Thu, Jun 28, 2018 at 07:36:56PM -0700, Steve Kargl wrote:
> === gfortran Summary ===
>
> # of expected passes47558
> # of unexpected failures6
> # of expected failures 104
> # of unsupported tests 85
>
> FAIL:
> 2018-06-27 10:09 GMT+02:00 Janne Blomqvist :
> >
> > How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and then
> > check benchmark results (polyhedron, spec etc.)? If performance worsens, we
> > revert, if it improves, great, lets keep it?
>
> I would definitely support that. I
On Thu, Jun 28, 2018 at 10:34:35AM -0700, Steve Kargl wrote:
> On Thu, Jun 28, 2018 at 07:03:05PM +0200, Jakub Jelinek wrote:
> > > In fact, I'll be submitting a bug report for a missed optimization.
> > >
> > > subroutine foo(x,y) subroutine foo(x,y)
> > >real x(10), y(10)
On Jun 28 2018, Toon Moene wrote:
And - most interesting - that's how Fortran 77 formulated it (way before
PURE/IMPURE functions entered the language):
"6.6.1 Evaluation of Operands
It is not necessary for a processor to evaluate all of the operands of
an expression if the value of the
On 06/28/2018 06:22 PM, Steve Kargl wrote:
You continue to miss my point or conveniently ignore it.
You want to special case the forced evaluation of the
operands in two specific logical expressions; namely, .and.
and .or. If you want to force evaluation of operands, then
do it for all binary
On Thu, Jun 28, 2018 at 07:21:21PM +0200, Janus Weil wrote:
> 2018-06-28 18:22 GMT+02:00 Steve Kargl :
> >
> > Why I think it a warning should be emitted: symmetry!.
> >
> > You complained about the lack of symmetry in 'check() .and. .false.'
> > and '.false. .and. check()'.
>
> well, my
On Thu, Jun 28, 2018 at 07:03:05PM +0200, Jakub Jelinek wrote:
> > In fact, I'll be submitting a bug report for a missed optimization.
> >
> > subroutine foo(x,y) subroutine foo(x,y)
> >real x(10), y(10) real x(10), y(10)
> >y = 0*sin(x)
Am 28.06.2018 um 19:21 schrieb Janus Weil:
One thing that I always failed to comprehend is people's fixation on
optimization. What's so great about your code running 0.1% faster if
the second compiler you try gives you totally different results, with
no hints
The warning added for my patch is
2018-06-28 18:22 GMT+02:00 Steve Kargl :
> On Thu, Jun 28, 2018 at 05:52:43PM +0200, Janus Weil wrote:
>> 2018-06-28 16:41 GMT+02:00 Steve Kargl :
>> >> > Technically, the standard says an operand need not be evaluate,
>> >> > but you've asked people not to cite the Standard. I've also
>> >> >
On Jun 28 2018, Steve Kargl wrote:
You continue to miss my point or conveniently ignore it.
You want to special case the forced evaluation of the
operands in two specific logical expressions; namely, .and.
and .or. If you want to force evaluation of operands, then
do it for all binary
On Thu, Jun 28, 2018 at 07:41:30AM -0700, Steve Kargl wrote:
> I am opposed to the change of TRUTH_AND_EXPR to TRUTH_ANDIF_EXPR,
> where you are special casing logical expressions that involve
> .and. and .or.
I think using TRUTH_AND_EXPR is the right thing to do, and if
fortran functions can
On Thu, Jun 28, 2018 at 05:52:43PM +0200, Janus Weil wrote:
> 2018-06-28 16:41 GMT+02:00 Steve Kargl :
> >> > Technically, the standard says an operand need not be evaluate,
> >> > but you've asked people not to cite the Standard. I've also
> >> > pointed you to F2018 Note 10.28 where it very
2018-06-28 16:41 GMT+02:00 Steve Kargl :
>> > Technically, the standard says an operand need not be evaluate,
>> > but you've asked people not to cite the Standard. I've also
>> > pointed you to F2018 Note 10.28 where it very clearly says that
>> > a function need not be evaluated with example
On Thu, Jun 28, 2018 at 07:58:22AM +0200, Janus Weil wrote:
> 2018-06-27 23:47 GMT+02:00 Steve Kargl :
> > On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
> >> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
> >> >
> >> > And we are not going to change Fortran semantics. And I also oppose
>
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
2018-06-28 13:05 GMT+02:00 N.M. Maclaren :
> On Jun 28 2018, Janus Weil wrote:
>>
>>
>>> if we add a warning, we should add it both for
>>>
>>> if (flag .and. func())
>>> and for
>>> if (func() .and. flag)
>>>
>>> because the standard also allows reversing the test (which my
>>> original test
On Jun 28 2018, Janus Weil wrote:
if we add a warning, we should add it both for
if (flag .and. func())
and for
if (func() .and. flag)
because the standard also allows reversing the test (which my
original test did).
well, I really don't want to warn for hypothetical problems. Since we
Hi Thomas,
> if we add a warning, we should add it both for
>
> if (flag .and. func())
>
> and for
>
> if (func() .and. flag)
>
> because the standard also allows reversing the test (which my
> original test did).
well, I really don't want to warn for hypothetical problems. Since we
currently do
On Thu, Jun 28, 2018 at 8:58 AM, Janus Weil wrote:
> But that still leaves us with a problem: The standard allows the
> short-circuiting but it doesn't require it. Meaning that any other
> compiler that does not do it (like ifort) is not in conflict with the
> standard either.
>
> Many people
Hi Janus,
if we add a warning, we should add it both for
if (flag .and. func())
and for
if (func() .and. flag)
because the standard also allows reversing the test (which my
original test did).
Regards
Thomas
2018-06-27 23:47 GMT+02:00 Steve Kargl :
> On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
>> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
>> >
>> > 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
On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
> >
> > 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
Am 27.06.2018 um 21:15 schrieb Janne Blomqvist:
If the semantic model is unclear on whether a function with potential
side-effects might or might not be evaluated, then IMNSHO the semantic
model is shit, and should be fixed or replaced.
I disagree here, strongly. We are talking Fortran, and
On Wed, Jun 27, 2018 at 8:26 PM, N.M. Maclaren wrote:
> On Jun 27 2018, Janus Weil wrote:
>
>> What is so complicated about putting a statement into the Fortran
>> standard that says: "Ok, if this function has side effects, we
>> definitely must evaluate it, otherwise we lose the side effects.
On Wed, Jun 27, 2018 at 7:46 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> On Wed, Jun 27, 2018 at 11:09:56AM +0300, Janne Blomqvist wrote:
> >
> > How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and
> then
> > check benchmark results (polyhedron, spec etc.)? If
On Jun 27 2018, Janus Weil wrote:
I'm not completely sure what you deduce from all these quoted
paragraphs, but applied to the cases we're discussing here, e.g.
A = .false. .and. my_boldly_impure_function()
I read them as saying that a compiler does not have to invoke the
function if it
On Wed, Jun 27, 2018 at 11:09:56AM +0300, Janne Blomqvist wrote:
>
> How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and then
> check benchmark results (polyhedron, spec etc.)? If performance worsens, we
> revert, if it improves, great, lets keep it?
>
> To clarify, I'm not
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
>
On Wed, Jun 27, 2018 at 08:15:13AM +0200, Jakub Jelinek wrote:
>
> I think best would be to change the above to
> code = TRUTH_AND_EXPR and code = TRUTH_OR_EXPR and have some
> non-default aggressive optimization option that would optimize
> away in the FE impure function calls from those
2018-06-27 15:43 GMT+02:00 N.M. Maclaren :
> On Jun 27 2018, Janus Weil wrote:
>>
>>
>> It is very unfortunate, and it means that the Fortran standard simply
>> does not provide a measure for "more correct" here. (My common-sense
>> drop-in notion of correctness would be that an optimization is
>>
On Jun 27 2018, Janus Weil wrote:
It is very unfortunate, and it means that the Fortran standard simply
does not provide a measure for "more correct" here. (My common-sense
drop-in notion of correctness would be that an optimization is
'correct' as long as it can be proven to not change any
2018-06-27 10:09 GMT+02:00 Janne Blomqvist :
> On Wed, Jun 27, 2018 at 10:52 AM, Janus Weil wrote:
>>
>> 2018-06-27 9:42 GMT+02:00 Jakub Jelinek :
>> > On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
>> >> > and have some non-default aggressive
>> >> > optimization option that would
On Wed, Jun 27, 2018 at 10:52 AM, Janus Weil wrote:
> 2018-06-27 9:42 GMT+02:00 Jakub Jelinek :
> > On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
> >> > and have some non-default aggressive
> >> > optimization option that would optimize away in the FE impure
> function calls
> >>
>
On Wed, Jun 27, 2018 at 09:52:04AM +0200, Janus Weil wrote:
> 2018-06-27 9:42 GMT+02:00 Jakub Jelinek :
> > On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
> >> > and have some non-default aggressive
> >> > optimization option that would optimize away in the FE impure function
> >> >
2018-06-27 9:42 GMT+02:00 Jakub Jelinek :
> On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
>> > and have some non-default aggressive
>> > optimization option that would optimize away in the FE impure function
>> > calls
>>
>> IMHO an optimization to remove functions calls is
On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
> > and have some non-default aggressive
> > optimization option that would optimize away in the FE impure function calls
>
> IMHO an optimization to remove functions calls is unproblematic only
> for pure functions, but as long as it is
2018-06-27 8:15 GMT+02:00 Jakub Jelinek :
> On Wed, Jun 27, 2018 at 07:52:59AM +0200, Janus Weil wrote:
>> >> with your patch, we would only warn about
>> >>
>> >> var .and. func()
>> >>
>> >> and not about
>> >>
>> >> func() .and. var.
>> >>
>> >> AFAIK, TRUTH_AND_EXPR does not guarantee that
On Wed, Jun 27, 2018 at 07:52:59AM +0200, Janus Weil wrote:
> >> with your patch, we would only warn about
> >>
> >> var .and. func()
> >>
> >> and not about
> >>
> >> func() .and. var.
> >>
> >> AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
> >> always be exectued, or if it does, I
2018-06-26 23:16 GMT+02:00 Jakub Jelinek :
> On Tue, Jun 26, 2018 at 11:12:40PM +0200, Thomas Koenig wrote:
>> Hi Janus,
>>
>> with your patch, we would only warn about
>>
>> var .and. func()
>>
>> and not about
>>
>> func() .and. var.
>>
>> AFAIK, TRUTH_AND_EXPR does not guarantee that func()
On Tue, Jun 26, 2018 at 11:12:40PM +0200, Thomas Koenig wrote:
> Hi Janus,
>
> with your patch, we would only warn about
>
> var .and. func()
>
> and not about
>
> func() .and. var.
>
> AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
> always be exectued, or if it does, I have not
Hi Janus,
with your patch, we would only warn about
var .and. func()
and not about
func() .and. var.
AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
always be exectued, or if it does, I have not seen the
documentation; it just happens to match what we currently
see (which may be
Hi Thomas, hi all,
I'm back from holidays and have more time to deal with this now ...
2018-06-17 0:38 GMT+02:00 Janus Weil :
>
> Am 16. Juni 2018 23:14:08 MESZ schrieb Thomas Koenig :
>>In my patch, I have tried to do all three things at the same time, and
>>after this discussion, I still think
Am 16. Juni 2018 23:14:08 MESZ schrieb Thomas Koenig :
>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
On Sat, Jun 16, 2018 at 11:14:08PM +0200, Thomas Koenig wrote:
> 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
On Sat, Jun 16, 2018 at 10:42:16PM +0200, Janus Weil wrote:
>
> Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl
> :
> >On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote:
> >>
> >>
> >> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
> >:
> >> >On Sat, Jun 16, 2018 at 01:09:36PM
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
Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl
:
>On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote:
>>
>>
>> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
>:
>> >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>> >>
>> >>
>> >> Am 15. Juni 2018 20:38:17 MESZ
On Sat, Jun 16, 2018 at 01:00:14PM -0700, Steve Kargl wrote:
> Untested.
>
> Index: trans-expr.c
> ===
> --- trans-expr.c (revision 261674)
> +++ trans-expr.c (working copy)
> @@ -3429,6 +3429,10 @@ gfc_conv_expr_op (gfc_se
On Sat, Jun 16, 2018 at 12:43:08PM -0700, Steve Kargl wrote:
>
> This is a different answer than what you gave in
> the PR when I asked if you were special casing
> .and. and .or. It is trivial to force the evaluation
> of operands. I already posted the diff in the PR
> where I special cased
On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote:
>
>
> Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
> :
> >On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
> >>
> >>
> >> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
> >:
> >> >> But at least for pure
Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
:
>On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>>
>>
>> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
>:
>> >> But at least for pure functions, this optimization looks Ok.
>> >>
>> >
>> >Why is everyone fixated on PURE
On Sat, Jun 16, 2018 at 06:56:49PM +0100, graham stott wrote:
> if i read this correctly it appears that IMPURE/PURE are not the normal
> pure attribute used by gcc but some entirely diff attribute specific to
> FORTAN so people are taking about different things
>
PURE and IMPURE are prefix-spec
)
To: Janus Weil
Cc: Janne Blomqvist , Thomas Koenig
, fort...@gcc.gnu.org, gcc-patches
Subject: Re: [patch, fortran] Handling of .and. and .or. expressions
On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>
>
> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
> :
>
On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>
>
> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
> :
> >> But at least for pure functions, this optimization looks Ok.
> >>
> >
> >Why is everyone fixated on PURE vs IMPURE functions?
>
> Simply because it makes a difference
Am 16.06.2018 um 12:53 schrieb Janus Weil:
Yes. Back when I followed c.l.f, several experts did advise people to
never
use functions unless they were pure (or more or less effectively so, if
they didn't fulfill the standard requirements for purity). Considering
that
at least some of those same
Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
:
>> But at least for pure functions, this optimization looks Ok.
>>
>
>Why is everyone fixated on PURE vs IMPURE functions?
Simply because it makes a difference in this context!
That the Fortran standard does not acknowledge this fact is
Am 15. Juni 2018 19:49:42 MESZ schrieb Janne Blomqvist
:
>On Fri, Jun 15, 2018 at 12:22 PM, Janus Weil wrote:
>
>> Am 14. Juni 2018 12:40:19 MESZ schrieb Janne Blomqvist <
>> blomqvist.ja...@gmail.com>:
>> In Fortran, it still feels like functions as such are second-class
>> citizens. People
Am 15. Juni 2018 19:10:01 MESZ schrieb Thomas Koenig :
>Am 14.06.2018 um 10:38 schrieb Janus Weil:
>>> Also, there are AFAIU other similar weirdness with impure functions.
>>> The
>>> standard allows a compiler to optimize
>>>
>>> y = f(x) + f(x)
>>>
>>> into
>>>
>>> y = 2 * f(x)
>>>
>>> even
On Fri, Jun 15, 2018 at 08:27:49PM +0300, Janne Blomqvist wrote:
> On Fri, Jun 15, 2018 at 8:06 PM, Thomas Koenig
> wrote:
>
> >
> > What about more complicated expressions like, say, "func() .and. flag .and
> >> func2() .and. flag2" etc.? Can it move all the function calls to the end?
> >>
> >
On Fri, Jun 15, 2018 at 12:22 PM, Janus Weil wrote:
> Am 14. Juni 2018 12:40:19 MESZ schrieb Janne Blomqvist <
> blomqvist.ja...@gmail.com>:
> In Fortran, it still feels like functions as such are second-class
> citizens. People seriously advise against using them. Doesn't really help
> the
On Fri, Jun 15, 2018 at 8:06 PM, Thomas Koenig
wrote:
> Hi Janne,
>
> What about more complicated expressions like, say, "func() .and. flag .and
>> func2() .and. flag2" etc.? Can it move all the function calls to the end?
>>
>
> Not at the moment.
>
> Like many of the front-end optimizations,
Am 14.06.2018 um 11:55 schrieb Jakub Jelinek:
Or warn users that there is no evaluation ordering between the first and
second operand, that both operands are evaluated and it is unspecified which
is evaluated first? Wouldn't you then just warn all the time? Even without
any impure procedures,
Am 14.06.2018 um 10:38 schrieb Janus Weil:
Also, there are AFAIU other similar weirdness with impure functions.
The
standard allows a compiler to optimize
y = f(x) + f(x)
into
y = 2 * f(x)
even if f is impure, which is totally bonkers. Or even not call f at
all,
if the compiler determines
Hi Janne,
What about more complicated expressions like, say, "func() .and. flag .and
func2() .and. flag2" etc.? Can it move all the function calls to the end?
Not at the moment.
Like many of the front-end optimizations, this aims for the easy 80%
which are relatively easy to achieve.
IMHO
Am 15. Juni 2018 11:22:44 MESZ schrieb Janus Weil :
but
>>> >> >even b) would be better than leaving it undefined.
>>> >>
>>> >> Agreed.
>>> >>
>>> >> In my opinion the best strategy for gfortran in the current
>>situation
>>> >> would be to apply short-circuiting whenever it can be proven
Am 14. Juni 2018 12:40:19 MESZ schrieb Janne Blomqvist
:
>> >> >Either
>> >> >
>> >> >a) short-circuiting in left-to-right order
>> >> >
>> >> >or
>> >> >
>> >> >b) must evaluate all the arguments in left-to-right order
>> >> >
>> >> >My preference would be for a) as that is what most
On Thu, Jun 14, 2018 at 11:55:45AM +0200, Jakub Jelinek wrote:
>
> I bet gfortran evaluates the side-effects left-to-right and evaluates both
> arguments always, right?
>
Currently, gfortran evaluates a logical expression left-to-right
due to its use of the middle-end's TRUTH_AND_EXPR. The
On Thu, Jun 14, 2018 at 1:14 PM, Janus Weil wrote:
>
>
> Am 14. Juni 2018 11:41:03 MESZ schrieb Janne Blomqvist <
> blomqvist.ja...@gmail.com>:
> >On Thu, Jun 14, 2018 at 11:38 AM, Janus Weil
> >wrote:
> >
> >>
> >> Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist <
> >>
Am 14. Juni 2018 11:41:03 MESZ schrieb Janne Blomqvist
:
>On Thu, Jun 14, 2018 at 11:38 AM, Janus Weil
>wrote:
>
>>
>> Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist <
>> blomqvist.ja...@gmail.com>:
>>
>> >Either
>> >
>> >a) short-circuiting in left-to-right order
>> >
>> >or
>> >
>>
On Wed, Jun 13, 2018 at 10:39:38PM +0200, Thomas Koenig wrote:
> Am 13.06.2018 um 14:20 schrieb Janus Weil:
> > Hi Thomas,
> >
> >
> > > the attached patch introduces the following changes:
> >
> > thanks a lot for working on this!
> >
> >
> > > If a logical .and. or .or. expression contains
Am 13. Juni 2018 22:39:38 MESZ schrieb Thomas Koenig :
>>> If a logical .and. or .or. expression contains a reference to a
>>> function
>>> which is impure and which also does not behave like a pure function
>>> (i.e. does not have the implicit_pure attribute set), it emits a
>>> warning with
On Thu, Jun 14, 2018 at 11:38 AM, Janus Weil wrote:
>
> Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist <
> blomqvist.ja...@gmail.com>:
>
> >Either
> >
> >a) short-circuiting in left-to-right order
> >
> >or
> >
> >b) must evaluate all the arguments in left-to-right order
> >
> >My
Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist
:
>> There is already quite some discussion in the PRs, especially 85599,
>> where not all people were of the same opinion. Let us see where the
>> discussion here leads us.
>
>IMHO it's a mistake that the standard refuses to specify the
On Mon, Jun 11, 2018 at 10:22 PM, Thomas Koenig
wrote:
> Hello world,
>
> the attached patch introduces the following changes:
>
> If a logical .and. or .or. expression contains a reference to a function
> which is impure and which also does not behave like a pure function
> (i.e. does not have
On Mon, Jun 11, 2018 at 09:22:27PM +0200, Thomas Koenig wrote:
>
> Regression-tested (which found one bug in the testsuite).
>
> OK for trunk?
>
I fine with the intent of the patch (see below).
PS: I think there may be some confusion on what IMPURE implies.
> Index: fortran/resolve.c
>
Am 13.06.2018 um 14:20 schrieb Janus Weil:
Hi Thomas,
the attached patch introduces the following changes:
thanks a lot for working on this!
If a logical .and. or .or. expression contains a reference to a
function
which is impure and which also does not behave like a pure function
(i.e.
Hi Thomas,
>the attached patch introduces the following changes:
thanks a lot for working on this!
>If a logical .and. or .or. expression contains a reference to a
>function
>which is impure and which also does not behave like a pure function
>(i.e. does not have the implicit_pure attribute
78 matches
Mail list logo
