Re: middle-end/5877: negative offset to array index leads to inefficient code

Re: middle-end/5877: negative offset to array index leads to inefficient code

[rodrigc]

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

Re: middle-end/5877: negative offset to array index leads to inefficient code

[Janis Johnson]

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

Re: middle-end/5877: negative offset to array index leads to inefficient code

[rodrigc]

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

Re: middle-end/5877: negative offset to array index leads to inefficient code

[jakub]

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

middle-end/5877: negative offset to array index leads to inefficient code

[janis187]

>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: