Bug 8366 - [sparc-sun-solaris2.7] C testsuite failure w/-m64 -fpic -O in execute/loop-2d.c
Bug#: 8366 Product:  gcc Version: 3.2.1
Host:  Target:  Build: 
Status: RESOLVED Severity: normal Priority: P3
Resolution: FIXED Assigned To: ebotcazou@gcc.gnu.org Reported By: ghazi@caip.rutgers.edu
Component: target Target Milestone: ---
Summary: [sparc-sun-solaris2.7] C testsuite failure w/-m64 -fpic -O in execute/loop-2d.c
Keywords:  wrong-code
Opened: 2002-10-26 09:46
Description:   Last confirmed: Opened: 2002-10-26 09:46
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 From Joe Buck 2002-10-28 11:11 -------
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 From Joe Buck 2002-10-28 19:00 -------
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 From Kaveh Ghazi 2002-10-28 19:28 -------
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 From Joe Buck 2002-10-29 09:55 -------
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 From Eric Botcazou 2003-03-08 11:53 -------
Responsible-Changed-From-To: unassigned->ebotcazou
Responsible-Changed-Why: Investigating.

------- Comment #6 From Eric Botcazou 2003-03-08 11:53 -------
State-Changed-From-To: open->analyzed
State-Changed-Why: The combine pass creates an illegitimate address.

------- Comment #7 From Eric Botcazou 2003-03-21 11:36 -------
State-Changed-From-To: analyzed->closed
State-Changed-Why: Fixed. See http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00778.html