This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fold VIEW_CONVERT_EXPR <type, STRING_CST> generated by Fortran FE a lot (PR target/35366)
Jakub Jelinek wrote:
> How is LOGICAL supposed to behave if it is storage associated with an
> integer? Defined only if the integer stored has been 0 or 1, or 0 .false.
> and non-zero .true., or something else?
Note: I strongly believe that EQUIVALENCE*, COMMON* and TRANSFER are no
true problems - using them is outside the Fortran standard and using
them does not make much sense. (* here applies: "When a variable of a
given type becomes defined, all associated variables of different type
The only real problem are Hollerith variables. Here, preserving the bit
pattern is crucial. As written before, I think the number of
still-in-use programs which use this Fortran-66-only features with
LOGICAL variables is very small. However, as (if?) they still exist,
some solution needs to be found.
(My preferred solution is to stick by default to the current middle-end
representation any print a warning or error for assignments of Hollerith
constants to logical variables; having a compiler flag to uses
internally integer values instead of booleans would be a bonus [I don't
see ad hoc how much work this would be].)
> But does the standard really say anything about this? Isn't assignment
> to a LOGICAL value supposed to set to to .false. or .true.?
I think the standard leaves this to the implementor as long as for
"logical = .true." "logical" is true and for "logical = .false." it is
false, the program should be standard conform, independent what internal
value "logical" has; that the bit pattern remains the same is a pure
* * *
For whatever it is worth: I posted to comp.lang.fortran to ask whether
there is anything in the Fortran 77 to 2008 standard which mandates that
the bit pattern is preserved (I don't think so); I further asked whether
there is some compelling real-world case for preserving it. See: