Lack of standard diagnostics for unary operator applied to logical

[Harald1]

Even when asking for standard conformance, an invalid use of a unary + or - in front of a logical is not always diagnosed:

program p
  print *,             (+(.true.))  ! Warning (OK)
  print *, [ integer :: +(.true.)]  ! No warning (not OK)
end program p

With ifort 2021.7.0 I get:

% ifort ifort-type-mismatch.f90 -stand f18
ifort-type-mismatch.f90(2): warning #6139: Fortran 2018 does not allow arithmetic operations in an expression involving LOGICAL(s).
  print *,             (+(.true.))  ! Warning (OK)
--------------------------^

So one case is detected, but not the other.  Same with replacing 'integer' by 'real' or 'complex'.

Thanks,

Harald

[JohnNichols]

Using Visual Studio 2022 if I turn on standard sematics with IFX I get  second picture and if I turn it off I get third picture.  I tried /stand f18  and got the same as third picture.  Could not generate a warning?  

So you lost me a bit.  I had ten minutes to spare whilst downloading file.  Sorry I only use Visual Studio - long habit. 

My interest is why the difference in answers, the -1 does not make semantic sense, the others do in a weird ok strange mathematics way. 

[Steve_Lionel]

Conversion between logical and numeric types is an artifact of an old DEC extension from the VAX/VMS days. On VMS, condition codes (status values) use the low two bits to indicate severity. 0=warning, 1=success, 2=error, 3=informational, 4=severe. Note that the low bit is 0 if something went wrong, 1 if not. It was typical in VAX FORTRAN (uppercase) to do logical tests on statuses, such as:

integer ret
ret = SYS$somesystemcall() ! returns integer
if (.not. ret) then
! report error

So, then you need a value for .TRUE. and .FALSE. that match this convention, hence -1 for .TRUE. and 0 for .FALSE. This was well before C existed, which would have 0 and non-zero as true and false. Intel Fortran does support the C convention if you use the /fpscomp:logicals option (because Microsoft Fortran PowerStation used it), and this is now implied by /standard-semantics because the Fortran standard now implies a potential correspondence between logical types and C's bool.

The situation was worse in the past, in that there was free conversion between logical and numeric in list-directed and namelist I/O. I successfully lobbied for that to change, though there is a compile option to still allow it.

For a bit more on this topic, see Doctor Fortran in "To .EQV. or to .NEQV., that is the question", or "It's only LOGICAL" - Doctor Fortran (stevelionel.com)

[JohnNichols]

Can we generate the warning and error, is the original post correct?  

[Steve_Lionel]

The compiler should have offered a standards warning for both of the uses in the original post. I was providing some background as to why ifort allows you to use an arithmetic operator on a logical value. I'd be quite happy if this extension was turned off by default, as it is a continued source of confusion and errors.

[Harald1]

> I'd be quite happy if this extension was turned off by default, as it is a continued source of confusion and errors.

I would support that, as well as more consistent behavior.  Why should the array constructor make a difference in the first place...?

[JohnNichols]

i could not turn it on in Visual studio - how would you?

[andrew_4619]

John maybe you confusing he /stand and /standard-semantics  which are different  options

[Barbara_P_Intel · Accepted solution]

Thanks for reporting this. I filed a bug, CMPLRLLVM-40856. I'll let you know when it's fixed.

[Barbara_P_Intel]

@Harald1, do the warning messages look better with the compilers that were released this week? Please check it out!

[Harald1]

Yes, the warnings I get with the flag "-stand" are fine.

Thanks for fixing this!