This is the mail archive of the
gcc-patches@gcc.gnu.org
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: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Tobias Schlüter <Tobias dot Schlueter at physik dot uni-muenchen dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, Feng Wang <wf_cs at yahoo dot com>
- Date: Tue, 11 Nov 2008 12:25:05 -0800
- 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> <4919A8A4.8000001@physik.uni-muenchen.de>
On Tue, Nov 11, 2008 at 04:45:40PM +0100, Tobias Schlüter wrote:
> 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:
> >logical l
> >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
> >preserved.
> >
> >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.
>
My changes in hollerith.f90 were of the form 'complex*16 --> complex(kind=8)'.
It would not have any affect on Jakub proposed patched.
In reviewing the thread, it appears that gfortran may need
to abandon BOOLEAN_TYPE because the description of TRANSFER is
quite clear:
If D and E are scalar variables such that the physical representation
of D is as long as or longer than that of E, the value of
TRANSFER (TRANSFER (E, D), E) shall be the value of E.
unless gfortran can provide a special case for the above. Also, note
that
integer f, e
logical d
e = 42
f = transfer(transfer(e,d),e)
if (f /= e) abort()
end
and
integer f, e
logical d
e = 42
d = transfer(e,d)
f = transfer(d,e)
if (f /= e) abort()
end
can be argued to have different results because the latter has two
explicitly assignments and hence type conversions whereas the
former has only a single assignment with an accompanying type
conversion.
--
Steve