From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-22661-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12221 invoked by alias); 7 Oct 2002 18:36:02 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 12207 invoked by uid 71); 7 Oct 2002 18:36:01 -0000
Date: Mon, 07 Oct 2002 11:36:00 -0000
Message-ID: <20021007183601.12205.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: "David S. Miller" <davem@redhat.com>
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in
 execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Reply-To: "David S. Miller" <davem@redhat.com>
X-SW-Source: 2002-10/txt/msg00268.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR target/8087; it has been noted by GNATS.

From: "David S. Miller" <davem@redhat.com>
To: roger@eyesopen.com
Cc: davem@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        ghazi@caip.rutgers.edu, rth@redhat.com, jakub@redhat.com,
        gcc-gnats@gcc.gnu.org
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in
 execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Date: Mon, 07 Oct 2002 11:20:31 -0700 (PDT)

    From: Roger Sayle <roger@eyesopen.com>
    Date: Mon, 7 Oct 2002 12:04:10 -0600 (MDT)
 
    The sparc64 backend represents a load from the constant pool as:
    
    (mem/u/f:DF (lo_sum:DI (reg/f:DI 110)
                           (symbol_ref/u:DI ("*.LLC0"))) [2 S8 A64]
    
 So does sparc32, at different stages of the compilation, for
 example for something simple like "double foo(void){return 0.0;}"
 the foo.c.00.rtl has:
 
 (insn 11 10 13 (set (reg/f:SI 109)
         (lo_sum:SI (reg:SI 110)
             (symbol_ref/u:SI ("*.LLC0")))) -1 (nil)
     (expr_list:REG_EQUAL (symbol_ref/u:SI ("*.LLC0"))
         (nil)))
 
 
 Which has the SYMBOL_REG inside of a LO_SUM construct.
 
 Note, the "/u" flag means unchanging which means it is
 a constant pool SYMBOL_REF.
 
    The problem is that the code in "avoid_constant_pool_reference"
    in simplify-rtx.c (line 149), assumes that constant pool references
    are of the form "(mem (symbol_ref ...))".  Indeed the macro
    CONSTANT_POOL_ADDRESS_P assumes that it is always passed a naked
    symbol_ref.
    
    A possible fix may be to extend this test is also allow the constant
    pool to be indexed via LO_SUM.  Something like:
    
 This looks perfectly fine to me.  I think it will improve code
 on all platforms that use LO_SUM, not just sparc64 and sparc32.