From: Jakub Jelinek <jakub@redhat.com>
To: "Tobias Schlüter" <Tobias.Schlueter@physik.uni-muenchen.de>
Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org,
Steve Kargl <sgk@troutmask.apl.washington.edu>,
Feng Wang <wf_cs@yahoo.com>
Subject: Re: [PATCH] Fold VIEW_CONVERT_EXPR <type, STRING_CST> generated by Fortran FE a lot (PR target/35366)
Date: Tue, 11 Nov 2008 16:22:00 -0000 [thread overview]
Message-ID: <20081111161100.GE3572@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <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.
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:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01903.html
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
end
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."
Jakub
next prev parent reply other threads:[~2008-11-11 16:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-11 13:27 Jakub Jelinek
2008-11-11 15:40 ` Richard Guenther
2008-11-11 15:53 ` Tobias Schlüter
2008-11-11 16:22 ` Jakub Jelinek [this message]
2008-11-11 16:26 ` Tobias Schlüter
2008-11-11 17:21 ` Jakub Jelinek
2008-11-11 17:22 ` Tobias Schlüter
2008-11-11 18:10 ` Jakub Jelinek
2008-11-11 19:07 ` Janne Blomqvist
2008-11-11 19:22 ` Brooks Moses
2008-11-11 19:36 ` Tobias Burnus
2008-11-11 20:50 ` Brooks Moses
2008-11-11 21:38 ` Jakub Jelinek
2008-11-11 21:41 ` Brooks Moses
2008-11-11 21:46 ` Jakub Jelinek
2008-11-11 22:31 ` Brooks Moses
2008-11-11 21:27 ` Thomas Koenig
2008-11-11 19:17 ` Brooks Moses
2008-11-11 19:34 ` Jakub Jelinek
2008-11-11 19:38 ` Brooks Moses
2008-11-11 17:30 ` Tobias Burnus
2008-11-11 16:22 ` Paul Richard Thomas
2008-11-11 16:45 ` Tobias Schlüter
2008-11-11 21:56 ` Steve Kargl
2008-11-11 22:53 Tobias Burnus
2008-11-12 14:20 ` Jakub Jelinek
2008-11-12 15:34 ` Paul Richard Thomas
2008-11-12 18:09 ` Feng Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081111161100.GE3572@tyan-ft48-01.lab.bos.redhat.com \
--to=jakub@redhat.com \
--cc=Tobias.Schlueter@physik.uni-muenchen.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=sgk@troutmask.apl.washington.edu \
--cc=wf_cs@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).