User account creation filtered due to spam.

Bug 8366 - [sparc-sun-solaris2.7] C testsuite failure w/-m64 -fpic -O in execute/loop-2d.c
Summary: [sparc-sun-solaris2.7] C testsuite failure w/-m64 -fpic -O in execute/loop-2d.c
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.2.1
: P3 normal
Target Milestone: ---
Assignee: Eric Botcazou
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2002-10-26 09:46 UTC by Kaveh Ghazi
Modified: 2010-10-27 16:58 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kaveh Ghazi 2002-10-26 09:46:01 UTC
I'm getting an abort with the 3.2.x prerelease on sparc-solaris2.7 running the binary from execute/loop-2d.c when compiled with -m64 -fpic -O.  I also get the failure on sparcv9-solaris2.7 with just -fpic -O.  (See: http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00944.html )  The abort goes away if I remove any of those flags or change the optimization level.  I've pasted the .s file in case that helps catch it by eye, it's not too long.  This abort also occurs in a binary generated by the 3.2 release as well as the 3.1.1 release so I can't say it's a regression, however on sparcv9 it merely requires -fpic -O and our release criteria specify that -fpic failures are important, so I think it's worth a quick look before the next 3.2.x release if time permits and the fix is safe.

        .file   "loop-2d.c"
        .section        ".text"
        .align 4
.LLGETPC0:
        retl
        add     %o7, %l7, %l7
        .align 4
        .global f
        .type   f,#function
        .proc   04
f:
        !#PROLOGUE# 0
        save    %sp, -192, %sp
        sethi   %hi(_GLOBAL_OFFSET_TABLE_-4), %l7
        call    .LLGETPC0
        add     %l7, %lo(_GLOBAL_OFFSET_TABLE_+4), %l7
        sllx    %i0, 2, %i2
        ldx     [%l7+a], %i1
        add     %i2, %i1, %i2
        add     %i0, -1, %i1
        cmp     %i1, -1
        be,pn   %icc, .LL8
        ld      [%l7+a+4], %g4
.LL6:
        add     %i2, -4, %i2
        sll     %i1, 1, %i0
        add     %i0, %i1, %i0
        add     %i0, %g4, %i0
        add     %i1, -1, %i1
        cmp     %i1, -1
        bne,pt  %icc, .LL6
        st      %i0, [%i2]
.LL8:
        nop
        return  %i7+8
        nop
.LLfe1:
        .size   f,.LLfe1-f
        .align 4
        .global main
        .type   main,#function
        .proc   04
main:
        !#PROLOGUE# 0
        save    %sp, -192, %sp
        sethi   %hi(_GLOBAL_OFFSET_TABLE_-4), %l7
        call    .LLGETPC0
        add     %l7, %lo(_GLOBAL_OFFSET_TABLE_+4), %l7
        ldx     [%l7+a], %l0
        st      %g0, [%l0+4]
        st      %g0, [%l0]
        call    f, 0
        mov     2, %o0
        ld      [%l0], %o1
        cmp     %o1, %l0
        bne,pt  %icc, .LL11
        add     %o1, 3, %o1
        ld      [%l0+4], %o0
        cmp     %o0, %o1
        be,pn   %icc, .LL10
        nop
.LL11:
        call    abort, 0
         nop
.LL10:
        call    exit, 0
        mov     0, %o0
        nop
.LLfe2:
        .size   main,.LLfe2-main
        .common a,8,4
        .ident  "GCC: (GNU) 3.2.1 20021025 (prerelease)"

Release:
gcc version 3.2.1 20021025 (prerelease)

Environment:
sparc-sun-solaris2.7 or sparcv9-sun-solaris2.7

How-To-Repeat:
Compile with:

cc1 -fpreprocessed loop-2d.i -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet -dumpbase loop-2d.c -m64 -O -version -fpic -o loop-2d.s

 /usr/ccs/bin/as -V -Qy -s -K PIC -xarch=v9 -o loop-2d.o loop-2d.s

collect2 -V -Y P,/usr/lib/sparcv9 -Qy /tmp/kg/321/build/gcc/sparcv9/crt1.o /tmp/kg/321/build/gcc/sparcv9/crti.o /usr/ccs/lib/sparcv9/values-Xa.o /tmp/kg/321/build/gcc/sparcv9/crtbegin.o -L/tmp/kg/321/build/gcc/sparcv9 -L/tmp/kg/321/build/gcc -L/usr/ccs/bin/sparcv9 -L/usr/ccs/bin -L/usr/ccs/lib/sparcv9 -L/usr/ccs/lib -L/lib/sparcv9 -L/usr/lib/sparcv9 loop-2d.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /tmp/kg/321/build/gcc/sparcv9/crtend.o /tmp/kg/321/build/gcc/sparcv9/crtn.o

then run the binary file
Comment 1 Joe Buck 2002-10-28 11:11:05 UTC
From: Joe Buck <jbuck@synopsys.com>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, rth@redhat.com,
   davem@redhat.com, jakub@redhat.com, mark@codesourcery.com,
   ghazi@caip.rutgers.edu
Cc:  
Subject: Re: target/8366: sparc-sun-solaris2.7 C testsuite failure w/-m64
 -fpic -O in execute/loop-2d.c
Date: Mon, 28 Oct 2002 11:11:05 -0800

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8366
 
 Just trying to do some triage to see if we can ever have a release ...
 
 It appears from Kaveh's comment that no one has confirmed that this 
 report is
 even a regression.  If it isn't, the priority of target/8366 should be 
 downgraded
 and attention focused elsewhere.
 
 Do we have any reports of this testcase working for 64-bit sparc and any 
 release?
 

Comment 2 Joe Buck 2002-10-28 19:00:11 UTC
From: Joe Buck <jbuck@synopsys.com>
To: ghazi@caip.rutgers.edu (Kaveh R. Ghazi)
Cc: davem@redhat.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
   jakub@redhat.com, Joe.Buck@synopsys.COM, mark@codesourcery.com,
   rth@redhat.com
Subject: Re: target/8366: sparc-sun-solaris2.7 C testsuite failure w/-m64 -fpic -O in execute/loop-2d.c
Date: Mon, 28 Oct 2002 19:00:11 -0800 (PST)

 I wrote:
 >  > Do we have any reports of this testcase working for 64-bit sparc
 >  > and any release?
 
 Kaveh writes:
 > I'm content with this PR not being a "regression" and thus getting
 > less attention.  However our release criteria state that we will test
 > with PIC flags too.  See http://gcc.gnu.org/gcc-3.1/criteria.html
 > under "Regresstion Tests".  I offer the report and the sparc
 > maintainers can decide if it warrants pursuing in 3.2.x or later on
 > the trunk.  I'm fine with whatever they decide.
 
 Fixing a non-regression in 3.2.1 would violate the release criteria for
 point releases.  I wouldn't object to an exception if we had a fix in
 hand, but with 18 release-critical bugs we need to start getting real, and
 looking at what to drop.  And it's the release manager's decision, not the
 sparc maintainer's decision.
 
 If it were me, I'd punt this one to 3.3 and look for others to punt as
 well.
 
 
 
 

Comment 3 Kaveh Ghazi 2002-10-28 19:28:08 UTC
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: davem@redhat.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
        jakub@redhat.com, jbuck@synopsys.com, mark@codesourcery.com,
        rth@redhat.com
Cc:  
Subject: Re: target/8366: sparc-sun-solaris2.7 C testsuite failure w/-m64 -fpic -O in execute/loop-2d.c
Date: Mon, 28 Oct 2002 19:28:08 -0500 (EST)

  > From: Joe Buck <jbuck@synopsys.com>
  > 
  > Do we have any reports of this testcase working for 64-bit sparc
  > and any release?
 
 In addition to the 3.2 and 3.1.1 releases, I also just tried GCC 3.0.4
 on sparcv9 and still got the error.  (Regular sparc bi-arch is
 disabled in 3.0.4, so I couldn't try plain sparc with -m64.)  I also
 tried 2.95 but couldn't get sparcv9 to build there.
 
 I'm content with this PR not being a "regression" and thus getting
 less attention.  However our release criteria state that we will test
 with PIC flags too.  See http://gcc.gnu.org/gcc-3.1/criteria.html
 under "Regresstion Tests".  I offer the report and the sparc
 maintainers can decide if it warrants pursuing in 3.2.x or later on
 the trunk.  I'm fine with whatever they decide.
 
 		--Kaveh
 
 PS: Minor note, we don't have any updated 3.2.x or 3.3 criteria AFAICT.
 
 --
 Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Comment 4 Joe Buck 2002-10-29 09:55:06 UTC
From: Joe Buck <jbuck@synopsys.com>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, rth@redhat.com,
   davem@redhat.com, jakub@redhat.com, mark@codesourcery.com,
   ghazi@caip.rutgers.edu
Cc:  
Subject: Re: target/8366: sparc-sun-solaris2.7 C testsuite failure w/-m64
 -fpic -O in execute/loop-2d.c
Date: Tue, 29 Oct 2002 09:55:06 -0800

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8366
 
 I am reducing the priority of this bug to "medium" because it is not a 
 regression.
 
Comment 5 Eric Botcazou 2003-03-08 11:53:44 UTC
Responsible-Changed-From-To: unassigned->ebotcazou
Responsible-Changed-Why: Investigating.
Comment 6 Eric Botcazou 2003-03-08 11:53:44 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: The combine pass creates an illegitimate address.
Comment 7 Eric Botcazou 2003-03-21 11:36:12 UTC
State-Changed-From-To: analyzed->closed
State-Changed-Why: Fixed. See http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00778.html