This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
middle-end/5877: negative offset to array index leads to inefficient code
- From: janis187 at us dot ibm dot com
- To: gcc-gnats at gcc dot gnu dot org
- Date: 7 Mar 2002 23:56:58 -0000
- Subject: middle-end/5877: negative offset to array index leads to inefficient code
- Reply-to: janis187 at us dot ibm dot com
>Number: 5877
>Category: middle-end
>Synopsis: negative offset to array index leads to inefficient code
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: pessimizes-code
>Submitter-Id: net
>Arrival-Date: Thu Mar 07 16:06:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Janis Johnson
>Release: gcc version 3.1 20020307 (prerelease)
>Organization:
>Environment:
Itanium, Red Hat 7.1.94 (Roswell)
>Description:
This test case, when compiled on ia64-unknown-linux-gnu with
the current 3.1 branch or the current mainline, with any
level of optimization, splits up the RHS integer value into
individual bytes and then stores them one at a time.
The behavior started with this change, which seems to have
exposed a latent problem:
2002-02-20 Roger Sayle <roger@eyesopen.com>
Jakub Jelinek <jakub@redhat.com>
PR c/4389
* tree.c (host_integerp): Ensure that the constant
integer is representable in a HOST_WIDE_INT or an
unsigned HOST_WIDE_INT when pos is zero or non-zero
respectively. Clarify comment.
* c-format.c (check_format_info_recurse): Fix
host_integerp usage; the pos argument should be zero
when assigning to a signed HOST_WIDE_INT.
The test case has an array offset that is a negative value
but whose tree node says that it is unsigned. The old
version of post_integerp returned 1 for that value and POS
of 0, but now it returns 0. The creation of the array
offset and the call to post_integerp all happen within
expand_assignment. My first attempts to fix this caused
ICEs, so I'll leave it to someone who understands this code
and get back to other things.
This behavior (eight single-byte stores instead of one
eight-byte store) is a regression from 3.0.4.
>How-To-Repeat:
Compile the following test case on ia64 and examine the
generated instructions. There should be a single 8-byte
store to the array element within the loop rather than a
series of 1-byte stores.
long a[1004];
void
foo ()
{
int i;
for (i = 4; i < 1004; i++)
a[i-4] = i;
}
>Fix:
Unknown.
>Release-Note:
>Audit-Trail:
>Unformatted: