[Bug fortran/89039] Logical read from stream file that is neither 0 nor 1

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89039

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Jakub Benda from comment #0)
> Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
> 
> Logicals read from an unformatted stream file that are neither 0 nor 1
> behave like this:
> 
>     print *, b, .not. b
> 
>     T T
> 
> i.e., both they and their negations evaluate to .true.
> 
> This reduces portability of stream files. For example, ifort uses -1 as
> .true., but when such stream files are read by gfortran, the nonzero value
> is not converted to gfortran's .true.
> 
> (Maybe there is nothing that requires it, I don't know.)

gfortran's behavior is documented in its accompanying manual:

***************

5.2 Internal representation of LOGICAL variables
================================================

The Fortran standard does not specify how variables of 'LOGICAL' type
are represented, beyond requiring that 'LOGICAL' variables of default
kind have the same storage size as default 'INTEGER' and 'REAL'
variables.  The GNU Fortran internal representation is as follows.

   A 'LOGICAL(KIND=N)' variable is represented as an 'INTEGER(KIND=N)'
variable, however, with only two permissible values: '1' for '.TRUE.'
and '0' for '.FALSE.'.  Any other integer value results in undefined
behavior.

****************

If you want a payload in a variable, I suggest you use an INTEGER type.
Also, this seems to have been addressed by Intel.

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/529134

I inclined to close this as either INVALID or WONTFIX.