From: Jeffrey A Law <law@cygnus.com>
To: Toon Moene <toon@moene.indiv.nluug.nl>
Cc: egcs@cygnus.com
Subject: Re: Fortran array indexing on 64-bit targets & snapshot 971023
Date: Fri, 24 Oct 1997 08:03:00 -0000 [thread overview]
Message-ID: <11138.877705479@hurl.cygnus.com> (raw)
In-Reply-To: <9710241223.AA02380@moene.indiv.nluug.nl>
In message < 9710241223.AA02380@moene.indiv.nluug.nl >you write:
> Hi,
>
> It seems that Richard Henderson's `expr.c' (get_inner_reference)
> patch didn't make into snapshot 971023.
>
> Was there a compelling reason to exclude it ?
Jim had some questions about it, which nobody has answered yet:
Jim:
> The get_inner_reference and f/com.c patch are both doing the same thing,
> forcing array indexing calculations to sizetype. If we assume that sizetype
> is an efficient type, then this is the right thing to do. If sizetype is
> larger than a word, then this may result in worse code. That is probably
> a case we shouldn't worry about. One would expect that changing the type of
> the expression might cause it to compute the wrong value, but I can't see
> any obvious case where it would be different. This might be a language bias.
> The low_bound will always be zero for C and one for Fortran. It can be
> other things for a more complicated language like Ada. It is interesting to
> note that in expand_expr in the ARRAY_REF case, there is similar code, with
> a FIXME comment that claims it isn't right. If this comment is true, then
> these changes may cause a problem. If there is a problem, we can probably
> exclude the failing cases, and still support the Fortran lower_bound = 1
> case which should always be OK.
The comment about ARRAY_REF in expr.c in particular worries me that we
might be missing some important issue.
I believe Jim is referring to this:
case ARRAY_REF:
if (TREE_CODE (TREE_TYPE (TREE_OPERAND (exp, 0))) != ARRAY_TYPE)
abort ();
{
tree array = TREE_OPERAND (exp, 0);
tree domain = TYPE_DOMAIN (TREE_TYPE (array));
tree low_bound = domain ? TYPE_MIN_VALUE (domain) : integer_zero_node;
tree index = TREE_OPERAND (exp, 1);
tree index_type = TREE_TYPE (index);
HOST_WIDE_INT i;
/* Optimize the special-case of a zero lower bound.
We convert the low_bound to sizetype to avoid some problems
with constant folding. (E.g. suppose the lower bound is 1,
and its mode is QI. Without the conversion, (ARRAY
+(INDEX-(unsigned char)1)) becomes ((ARRAY+(-(unsigned char)1))
+INDEX), which becomes (ARRAY+255+INDEX). Oops!)
But sizetype isn't quite right either (especially if
the lowbound is negative). FIXME */
if (! integer_zerop (low_bound))
index = fold (build (MINUS_EXPR, index_type, index,
convert (sizetype, low_bound)));
next prev parent reply other threads:[~1997-10-24 8:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-10-24 5:26 Toon Moene
1997-10-24 8:03 ` Jeffrey A Law [this message]
1997-10-24 11:21 ` Toon Moene
1997-10-26 5:26 ` Toon Moene
1997-10-26 8:09 ` Jeffrey A Law
1997-10-26 10:31 ` Per Bothner
1997-10-27 14:46 ` Jim Wilson
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=11138.877705479@hurl.cygnus.com \
--to=law@cygnus.com \
--cc=egcs@cygnus.com \
--cc=toon@moene.indiv.nluug.nl \
/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).