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

Jakub Jelinek jakub@redhat.com
Wed Jun 27 06:16:00 GMT 2018


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 have not seen the
> >> documentation; it just happens to match what we currently
> >> see (which may be due to missed optimizatins in the back end,
> >> or the lack of test cases exposing this).
> >
> > If you are talking about what the middle-end does, TRUTH_AND_EXPR
> > always evaluates side-effects in both operands, while for
> > TRUTH_ANDIF_EXPR it evaluates the second operand only if the first operand
> > is not false.
> 
> thanks for the comments. Looking into gfc_conv_expr_op, I see:
> 
>     case INTRINSIC_AND:
>       code = TRUTH_ANDIF_EXPR;
>       lop = 1;
>       break;
> 
>     case INTRINSIC_OR:
>       code = TRUTH_ORIF_EXPR;
>       lop = 1;
>       break;
> 
> That seems to indicate that Fortran's logical .AND. operator is
> translated into TRUTH_ANDIF_EXPR, right? Also the empirically observed
> behavior matches Jakub's description of TRUTH_ANDIF_EXPR, where the
> first operator is always evaluated and the second one only on demand.
> Therefore I think my patch is correct in warning about an impure
> function only if it occurs in the second operand of an and/or
> operator.

Is that what we want though?  Are there in Fortran any ways to have
side-effects in expressions other than function calls?  E.g.
VOLATILE variable reads?  Is it ok not to evaluate those on .and. or .or.
expressions?  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 operands if one operand is cheap to evaluate and another one
contains function calls, by optimizing it into TRUTH_{AND,OR}IF_EXPR where
the cheap operand is the first operand and operand with function calls is
the second.

	Jakub



More information about the Gcc-patches mailing list