public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* middle-end/5877: negative offset to array index leads to inefficient code
@ 2002-03-07 16:06 janis187
0 siblings, 0 replies; 5+ messages in thread
From: janis187 @ 2002-03-07 16:06 UTC (permalink / raw)
To: gcc-gnats
>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:
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: middle-end/5877: negative offset to array index leads to inefficient code
@ 2002-03-08 10:11 jakub
0 siblings, 0 replies; 5+ messages in thread
From: jakub @ 2002-03-08 10:11 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, jakub, janis187, nobody
Synopsis: negative offset to array index leads to inefficient code
Responsible-Changed-From-To: unassigned->jakub
Responsible-Changed-By: jakub
Responsible-Changed-When: Fri Mar 8 10:11:17 2002
Responsible-Changed-Why:
Being the guilty one, debugging this...
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5877
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: middle-end/5877: negative offset to array index leads to inefficient code
@ 2002-03-10 11:13 rodrigc
0 siblings, 0 replies; 5+ messages in thread
From: rodrigc @ 2002-03-10 11:13 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, jakub, janis187
Synopsis: negative offset to array index leads to inefficient code
State-Changed-From-To: open->feedback
State-Changed-By: rodrigc
State-Changed-When: Sun Mar 10 11:13:56 2002
State-Changed-Why:
Can you verify if this solves the problem?
2002-03-09 Jakub Jelinek <jakub@redhat.com>
PR middle-end/5877
* expr.c (highest_pow2_factor): Check TREE_INT_CST_LOW
even for non-representable constants.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5877
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: middle-end/5877: negative offset to array index leads to inefficient code
@ 2002-03-11 8:46 Janis Johnson
0 siblings, 0 replies; 5+ messages in thread
From: Janis Johnson @ 2002-03-11 8:46 UTC (permalink / raw)
To: jakub; +Cc: gcc-prs
The following reply was made to PR middle-end/5877; it has been noted by GNATS.
From: Janis Johnson <janis187@us.ibm.com>
To: rodrigc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
jakub@gcc.gnu.org, janis187@us.ibm.com, gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: middle-end/5877: negative offset to array index leads to inefficient code
Date: Mon, 11 Mar 2002 08:49:41 -0800
On Sun, Mar 10, 2002 at 07:13:56PM -0000, rodrigc@gcc.gnu.org wrote:
> Synopsis: negative offset to array index leads to inefficient code
>
> State-Changed-From-To: open->feedback
> State-Changed-By: rodrigc
> State-Changed-When: Sun Mar 10 11:13:56 2002
> State-Changed-Why:
> Can you verify if this solves the problem?
>
>
>
> 2002-03-09 Jakub Jelinek <jakub@redhat.com>
>
> PR middle-end/5877
> * expr.c (highest_pow2_factor): Check TREE_INT_CST_LOW
> even for non-representable constants.
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5877
Yes, it does. Thanks, Jakub!
Janis
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: middle-end/5877: negative offset to array index leads to inefficient code
@ 2002-03-11 9:19 rodrigc
0 siblings, 0 replies; 5+ messages in thread
From: rodrigc @ 2002-03-11 9:19 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, jakub, janis187
Synopsis: negative offset to array index leads to inefficient code
State-Changed-From-To: feedback->closed
State-Changed-By: rodrigc
State-Changed-When: Mon Mar 11 09:19:31 2002
State-Changed-Why:
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00393.html
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5877
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-03-11 17:19 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-07 16:06 middle-end/5877: negative offset to array index leads to inefficient code janis187
2002-03-08 10:11 jakub
2002-03-10 11:13 rodrigc
2002-03-11 8:46 Janis Johnson
2002-03-11 9:19 rodrigc
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).