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: Potential patch for PR fortran/6491


Toon Moene <toon@moene.indiv.nluug.nl> writes:

> > PR 6491 requires that a .and. of two logical*4 variables, when using
> > -fugly-logint, be implemented using an integer AND operation.  The
> > result is then assigned to a logical*4 variable.
> > PR 12633 requires that the result of a .or. of two logical variables,
> > when using -fugly-logint, produce a logical result.
> 
> Hmmm, that's not how I understand it.  The problem is that, with
> -fugly-logint, LOGICALs should be treated as INTEGERs in expressions
> that are assigned to (INTEGERs), while being treated as LOGICALs in
> "logical" expressions (i.e., when a .true./.false. value is expected).
> 
> I.e.,
> 
>        LOGICAL LA, LB
>        INTEGER I
>        ...
>        I = LA .OR. LB  ! I is set to the bitwise OR of LA and LB
> 
> whereas
> 
>         LOGICAL LA, LB
>         ...
>         IF (LA .OR. LB) THEN
>            .... ! Executed when either LA or LB is .true.
> 
> IOW, the way to evaluate the expression depends on its context -
> that's why it's so hard to implement in g77, because that's counter to
> the way Fortran is defined.

Interesting.

This sort of boils down to the values used for true and false.  For
example, let's suppose that true has the value 1 and false has the
value 0.  If that is the case, then, when working exclusively with
logical values, it doesn't matter whether we use bitwise operations or
logical operations.  We will always get the right result.

What happens when working with integer values kind of depends upon the
exact integer value.  For example, if we use a bitwise operation, then
2 AND TRUE will yield FALSE.  If we use a logical operation, and treat
all non-zero values as TRUE, then 2 AND TRUE will yield TRUE.

So I think the relevant question here is what
    INTEGER I
    LOGICAL A
    IF (A .AND. I) THEN
is supposed to do when using -fugly-logint.  Does it do a bitwise and
or a logical and?

The patch I sent (which was closely based on the patch by Hassan
Aurag) will convert A into an integer, and then do a bitwise and,
producing an integer result.  The IF will presumably convert that back
into a logical value.

Consider this test case:

        program foo1

        logical a
        integer i

        i = 1
        a = .true.

        if (a .and. i) then
           write (*,*) "true"
        else
           write (*,*) "false"
        endif

        i = 2
        a = .true.

        if (a .and. i) then
           write (*,*) "true"
        else
           write (*,*) "false"
        endif

        end

With the patch I sent, the output is
 true
 false

Without the patch I sent, this program does not compile, even when
using -fugly-logint.  I get this error:

foo1.f:9: 
           if (a .and. i) then
                 1     2
Boolean/logical operator at (1) must operate on two scalar (not array) subexpressions, two function invocations returning logical scalars, or a combination of both -- but the subexpression at (2) is an array

So, to sum up: if you use exclusively logical operands, then my patch
should work as expected.  If you use exclusively integer operands,
then my patch should have no effect.  If you combine logical and
integer operands, then the effect with my patch depends entirely upon
the values of the integer operands.

What should happen when logical and integer operands are combined when
using -fugly-logint?

Ian


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