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:
They are not standard Fortran. Using Hollerith constants this way was
the way of encoding strings before there was a Character type in
Fortran, so the current behavior is intentional. Whether there actually
is code that uses logicals to encode strings, I can't tell. I CCed Feng
Wang who added the original Hollerith support, and Steve who last
modified the testcase.
If using logicals is required to store all the bits of the constants
(and similarly for TRANSFER from integer to logical), then I'm afraid the
Fortran FE would have to stop using BOOLEAN_TYPE for logical, as the
middle-end BOOLEAN_TYPE really has the semantics that it is either false or
true, nothing else.
For TRANSFER I found:
but I'm still unconvinced. I'd say arguing that the logical must
hold all the bits is the same as if you said
real(kind=8), parameter :: a = transfer (transfer (3.1415926d0, 0), 0.d0)
print *, a
must print 3.14159... A precondition of the two transfers giving identity
is IMHO that no bits are lost, but if the precision of the middle-type
is smaller than of the other type, it can't be fully preserved. The
precision of integer(kind=4) is smaller than of real(kind=8), and similarly
I'd say for logical(kind=4) and integer(kind=4), because logical:
"The logical type has two values which represent true and false."
Hm, I haven't found Richard Maine's post that is mentioned in the old
thread, but Fortran has the notion of storage unit. LOGICAL*4,
INTEGER*4 and REAL*4 all occupy 4 storage units. If a circular
transfer(transfer (...) ...) between types with the same number of
storage units is required to return the original value (as Richard Maine
apparently argued), then we'll probably have no choice but to stop using
BOOLEAN_TYPE for LOGICALs.
Maybe Brooks can point us to the comp.lang.fortran thread.