From: "Paul Richard Thomas" <paul.richard.thomas@gmail.com>
To: "Tobias Schlüter" <Tobias.Schlueter@physik.uni-muenchen.de>
Cc: "Jakub Jelinek" <jakub@redhat.com>,
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: <339c37f20811110821u10e9aa05k8f125d8b84bcecb7@mail.gmail.com> (raw)
In-Reply-To: <4919A8A4.8000001@physik.uni-muenchen.de>
Tobi and Jakub,
> 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.
I am not so sure about that in the case of transfer_simplify_4.f90 -
we have already had serious amounts of correspondence about it as
witnessed in PR33759. What the standard says is:
>
13.14.110 TRANSFER (SOURCE, MOLD [, SIZE])
Description. Returns a result with a physical representation identical
to that of SOURCE but interpreted with the type and type parameters of
MOLD.
Class. Transformational function.
Arguments.
SOURCE may be of any type and may be scalar or array valued.
MOLD may be of any type and may be scalar or array valued.
SIZE (optional) shall be scalar and of type integer. The corresponding
actual argument shall not be an optional dummy argument.
Result Characteristics. The result is of the same type and type
parameters as MOLD.
Case (i): If MOLD is a scalar and SIZE is absent, the result is a scalar.
Case (ii): If MOLD is array valued and SIZE is absent, the result is
array valued and of rank one. Its size is as small as possible such
that its physical representation is not shorter than that of SOURCE.
Case (iii): If SIZE is present, the result is array valued of rank one
and size SIZE.
Result Value. If the physical representation of the result has the
same length as that of SOURCE, the physical representation of the
result is that of SOURCE. If the physical representation of the result
is longer than that of SOURCE, the physical representation of the
leading part is that of SOURCE and the remainder is undefined. If the
physical representation of the result is shorter than that of SOURCE,
the physical representation of the result is the leading part of
SOURCE. 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. IF D is an
array and E is an array of rank one, the value of TRANSFER (TRANSFER
(E, D), E, SIZE (E)) shall be the value of E.
or... as Jakub paraphrases it:
> (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.
I would say that it conforms to the standard.
Cheers
Paul
next prev parent reply other threads:[~2008-11-11 16:22 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 ` Paul Richard Thomas [this message]
2008-11-11 16:45 ` Tobias Schlüter
2008-11-11 16:22 ` Jakub Jelinek
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 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=339c37f20811110821u10e9aa05k8f125d8b84bcecb7@mail.gmail.com \
--to=paul.richard.thomas@gmail.com \
--cc=Tobias.Schlueter@physik.uni-muenchen.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--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).