Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28809 Discussions

Lack of standard diagnostics for unary operator applied to logical

Harald1
New Contributor II
1,817 Views

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

 

0 Kudos
1 Solution
Barbara_P_Intel
Employee
1,655 Views

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



View solution in original post

0 Kudos
10 Replies
JohnNichols
Valued Contributor III
1,783 Views

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. 

 

Screenshot 2022-10-09 084240.png

Screenshot 2022-10-09 084215.pngScreenshot 2022-10-09 084645.png

0 Kudos
Steve_Lionel
Honored Contributor III
1,779 Views

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)

 

 

 

 

 

0 Kudos
JohnNichols
Valued Contributor III
1,772 Views

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

0 Kudos
Steve_Lionel
Honored Contributor III
1,759 Views

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.

0 Kudos
Harald1
New Contributor II
1,750 Views

> 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...?

 

0 Kudos
JohnNichols
Valued Contributor III
1,735 Views

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

0 Kudos
andrew_4619
Honored Contributor III
1,719 Views

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

0 Kudos
Barbara_P_Intel
Employee
1,656 Views

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



0 Kudos
Barbara_P_Intel
Employee
1,088 Views

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


0 Kudos
Harald1
New Contributor II
1,058 Views

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

Thanks for fixing this!

 

0 Kudos
Reply