Warnings for numerical operations on logical objects

[IanH]

I'm not sure whether the compiler is required to diagnose this sort of silliness or not with /stand, but it would be nice if it did.

PROGRAM LogicalOperations
  IMPLICIT NONE
  LOGICAL :: la, lb
  
  la = .TRUE.
  lb = .FALSE.
  
  PRINT *, -la
  PRINT *, +la
  PRINT *, la + lb
  PRINT *, la - lb
  PRINT *, la * lb
  PRINT *, lb / la
  PRINT *, la ** lb
END PROGRAM LogicalOperations

>ifort /check:all /warn:all /standard-semantics /stand "2014-09-21 logical-operations.f90"
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 15.0.0.108 Build 20140726
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2014-09-21 logical-operations.exe"
-subsystem:console
"2014-09-21 logical-operations.obj"

[Steven_L_Intel1]

Yes, it should warn about this. I'm rather astonished it doesn't. I will let the developers know. Thanks.

[Steven_L_Intel1]

Escalated as DPD200361277.

[dboggs]

How old are "the developers"? Once upon a time (in a galaxy far far away) it was very common to perform arithmetic on logical variables and it was considered quite acceptable. Assuming that the arithmetic statements shown perform some useful results, I dare say it would be quite verbose and more difficult to decipher to accomplish the same thing using "modern" code involving nested IF THEN statements.

Nevertheless one must appreciate the modern dogma which forbids this (along with other things like computed GO TO) and yes, if the modern Fortran rules say not to do this, then the compiler should AT LEAST warn about it. Old timers would not get so excited however.

Is it forbidden now because compilers are not required to equate .FALSE. = 0 and .TRUE. = 1?

[IanH]

It was never permitted in standard code. Those operations are explicitly described in the standards over the years as being for integer, real (and double precision) or complex type. A separate set of operations is defined for logical and character. Similarly, there was never any requirement for the integer value of a logical constant (LOGICAL(C_BOOL) perhaps aside in more recent times). I thought using -1 for .true. was common.

[TimP]

dboggs wrote:

Is it forbidden now because compilers are not required to equate .FALSE. = 0 and .TRUE. = 1?

Prior to availability of MERGE, some compilers supported schemes for treating logical expressions as masks (requiring .true. to match -1). You may have noticed that ifort -standard-semantics invokes the rather ancient -fpscomp:logicals making .true. match 1 in support of iso_c_interop.

[Steven_L_Intel1]

As Ian says, it has always been prohibited in the language. But limited mixing of integer and logical made some coding simpler, though typically not with arithmetic operators. Back on VMS, the condition handling standard defined status codes explicitly so that you could test for success/failure by doing an odd/even test on the value, which is where the Intel Fortran odd/even test for logicals came from.

Note that .TRUE. is indeed 1 with fpscomp:logicals, that doesn't mean that only the value 1 tests as true. The test is zero/nonzero.

[Steven_L_Intel1]

A future major release of the compiler will warn about this situation when standards checking is enabled.