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)
- From: Tobias Schlüter <Tobias dot Schlueter at physik dot uni-muenchen dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, Steve Kargl <sgk at troutmask dot apl dot washington dot edu>, Feng Wang <wf_cs at yahoo dot com>
- Date: Tue, 11 Nov 2008 16:45:40 +0100
- Subject: Re: [PATCH] Fold VIEW_CONVERT_EXPR <type, STRING_CST> generated by Fortran FE a lot (PR target/35366)
- References: <20081111131749.GZ3572@tyan-ft48-01.lab.bos.redhat.com>
Jakub Jelinek wrote:
Unfortrunately, it causes 2 Fortran testsuite failures, hollerith.f90
and transfer_simplify_4.f90, both at all optimization levels.
I believe the tests are just invalid though. The first one does:
l = 4Ho wo
and expects all the 32 bits preserved, but that is certainly against
the semantics of BOOLEAN_TYPE and from quick skimming of the Fortran
standard also LOGICAL type. BOOLEAN_TYPE has just two values, false
and true (similarly for LOGICAL .false. and .true.) and so the folder
IMHO correctly folds this into
l = .true.
(4Ho wo is non-zero). The transfer_simplify_4.f90 testcase transfers an
integer into logical and back and expects again all the 32-bits to be
Fortran folks, can you please look at these 2 testcases and say whether
they are valid Fortran or just undefined behavior?
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.