Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Kaveh R. Ghazi]

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

From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: davem@redhat.com
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        jakub@redhat.com, roger@eyesopen.com, rth@redhat.com
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Date: Thu, 3 Oct 2002 11:05:41 -0400 (EDT)

  > From: "David S. Miller" <davem@redhat.com>
  > 
  >    From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
  >    Date: Wed, 2 Oct 2002 10:46:13 -0400 (EDT)
  >    
  >    So what does that mean with respect to addressing the testcase?
  >    Fixable?  XFAIL it?
  > 
  > It think it would be rediculious to mark such a simple piece of C code
  > as XFAIL on any platform.  Roger reverted his changes it appears, so
  > it should pass now.
 
 Er, I don't think what Roger reverted had anything to do with this
 testcase, e.g. I still get the failure with -m64 from last night's
 CVS bootstrap.  Roger?
 
 --
 Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: Roger Sayle <roger@eyesopen.com>
Cc: "David S. Miller" <davem@redhat.com>, davem@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, ghazi@caip.rutgers.edu,
   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, 7 Oct 2002 11:38:27 -0700

 On Mon, Oct 07, 2002 at 12:04:10PM -0600, Roger Sayle wrote:
 > (mem/u/f:DF (lo_sum:DI (reg/f:DI 110)
 >                        (symbol_ref/u:DI ("*.LLC0"))) [2 S8 A64]
 > 
 > 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.
 
 *That* is a bug.  The lo_sum is a perfectly respectable way
 to do this.
 
 > +	if (GET_CODE (addr) == LO_SUM
 > +	    && GET_CODE (XEXP (addr, 1)) == SYMBOL_REF)
 > +	  addr = XEXP (addr, 1);
 
 Yes, this is reasonable.  You don't even need the SYMBOL_REF
 check here, since that'll get handled ...
 
 > 	if (GET_CODE (addr) != SYMBOL_REF
 > 	    || ! CONSTANT_POOL_ADDRESS_P (addr))
 
 ... here.
 
 
 
 r~

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Roger Sayle]

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

From: Roger Sayle <roger@eyesopen.com>
To: "David S. Miller" <davem@redhat.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, 7 Oct 2002 12:25:48 -0600 (MDT)

 > 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.
 
 Indeed.  The difference is that by foo.c.18.combine the constant
 pool reference has been optimized away on sparc32, but it isn't
 if "-m64" is specified or on sparc64.
 
 > Note, the "/u" flag means unchanging which means it is
 > a constant pool SYMBOL_REF.
 
 Thanks.
 
 >    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.
 
 Excellent.  I'll perform the usual bootstraps and regression tests
 on sparc-sun-solaris2.8, and then post the patch to gcc-patches
 today or tomorrow.
 
 Roger
 --
 

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[David S. Miller]

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.

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Roger Sayle]

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

From: Roger Sayle <roger@eyesopen.com>
To: "David S. Miller" <davem@redhat.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, 7 Oct 2002 12:04:10 -0600 (MDT)

 >    The fixes that I'm still investigating address the sparc64 backend's
 >    convoluted constant pool loading code.
 >
 > There is nothing convoluted about it.  That's a perfectly valid
 > and fine way to output a load from the constant pool and expose
 > all of the instructions to the compiler for scheduling purposes.
 
 I beg to differ.
 
 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]
 
 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:
 
 	if (GET_CODE (x) != MEM)
 	  return x;
 	addr = XEXP (x, 0)
 
 +	if (GET_CODE (addr) == LO_SUM
 +	    && GET_CODE (XEXP (addr, 1)) == SYMBOL_REF)
 +	  addr = XEXP (addr, 1);
 
 	if (GET_CODE (addr) != SYMBOL_REF
 	    || ! CONSTANT_POOL_ADDRESS_P (addr))
 	  return x;
 
 
 Could someone that understands LO_SUM targets confirm that this is
 a reasonable thing to do?  I'm assuming that the ".LLC0" symbol_ref
 will be correctly marked with CONSTANT_POOL_ADDRESS_P.  If it is,
 this should not only solve 20020720-1.c, but also enable many more
 optimizations on sparc64.  RTH?
 
 Roger
 --
 

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Kaveh R. Ghazi]

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

From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: davem@gcc.gnu.org, davem@redhat.com, gcc-bugs@gcc.gnu.org,
        gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, jakub@redhat.com,
        roger@eyesopen.com, rth@redhat.com
Cc:  
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Date: Mon, 7 Oct 2002 13:16:05 -0400 (EDT)

 BTW, I think there are two problems with the XFAIL code that was
 recently added.  With the first hunk, you set torture_execute_xfail
 and I believe the testcase fails to *compile* on those targets.  (You
 get the link failure when the opt doesn't occur right?)  If the
 testcase compiles you should never expect an execute failure.
 
 I came to this conclusion via visual inspection not any direct
 testing, but I believe you need to set torture_compile_xfail there
 instead.
 
 
 The second hunk for sparc -m64 looks correct, but it doesn't work for
 me for some reason.  See:
 http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00194.html
 I'm not sure why, perhaps that one only looks for execute failures,
 not compile failures?  Not sure.  Can you reproduce it?
 
 		--Kaveh
 --
 Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[David S. Miller]

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 09:18:51 -0700 (PDT)

    From: Roger Sayle <roger@eyesopen.com>
    Date: Mon, 7 Oct 2002 10:08:04 -0600 (MDT)
    
    The REG_EQUAL notes is a separate issue.  The fixes that I'm still
    investigating address the sparc64 backend's convoluted constant
    pool loading code.
 
 There is nothing convoluted about it.  That's a perfectly valid
 and fine way to output a load from the constant pool and expose
 all of the instructions to the compiler for scheduling purposes.
 
 It's very complicated to "defer" the full-blown load till later
 in the compilatio if that's the idea you have.  You have to
 force the thing into a register early to get good code and
 sane behavior.
 
 Ignoring REG_EQUAL is a bug, and once that bug is fixed the sparc64
 "convoluted" constant pool load works as well as "(set reg
 (const_double 0.0))"

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Roger Sayle]

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

From: Roger Sayle <roger@eyesopen.com>
To: "David S. Miller" <davem@redhat.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, 7 Oct 2002 10:08:04 -0600 (MDT)

 >    Just to let you know, I'm still investigating a solution.
 >
 > Ok.  I would prefer if a seperate PR is opened for the REG_EQUAL
 > problem, since that is a generic compiler issue actually.
 
 The REG_EQUAL notes is a separate issue.  The fixes that I'm still
 investigating address the sparc64 backend's convoluted constant
 pool loading code.
 
 Roger
 --
 

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[David S. Miller]

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 09:05:44 -0700 (PDT)

    From: Roger Sayle <roger@eyesopen.com>
    Date: Mon, 7 Oct 2002 09:54:51 -0600 (MDT)
    
    Just to let you know, I'm still investigating a solution.
 
 Ok.  I would prefer if a seperate PR is opened for the REG_EQUAL
 problem, since that is a generic compiler issue actually.
 
 I wonder how hard it would be to just create a dummy:
 
 	(set DEST CONTENTS_OF_REG_EQUAL_NOTE)
 
 when such a note is present and then use that for the transformations
 in combine or whatever.

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Roger Sayle]

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

From: Roger Sayle <roger@eyesopen.com>
To: <davem@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>,
        <ghazi@caip.rutgers.edu>, <rth@redhat.com>, <davem@redhat.com>,
        <jakub@redhat.com>, <roger@eyesopen.com>, <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in
 execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Date: Mon, 7 Oct 2002 09:54:51 -0600 (MDT)

 > Synopsis: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
 >
 > State-Changed-From-To: analyzed->closed
 > State-Changed-By: davem
 > State-Changed-When: Mon Oct  7 00:22:29 2002
 > State-Changed-Why:
 >     Bug marked as XFAIL in current sources.
 >
 
 This is still a problem with sparc64.  It probably still deserves
 a Problem Report.  It was marked XFAIL to indicate that it isn't
 an immediate problem, i.e. a concern to GCC users, but the problem
 itself hasn't gone away.
 
 Toon's original complex division example still produces inferior
 code on sparc64 than it does on 32-bit sparc.  Perhaps reducing
 the priority may have been more appropriate?
 
 Just to let you know, I'm still investigating a solution.
 
 Roger
 --
 

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[davem]

Synopsis: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

State-Changed-From-To: analyzed->closed
State-Changed-By: davem
State-Changed-When: Mon Oct  7 00:22:29 2002
State-Changed-Why:
    Bug marked as XFAIL in current sources.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8087

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[David S. Miller]

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

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

    From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
    Date: Wed, 2 Oct 2002 10:46:13 -0400 (EDT)
    
    So what does that mean with respect to addressing the testcase?
    Fixable?  XFAIL it?
 
 It think it would be rediculious to mark such a simple piece of C code
 as XFAIL on any platform.  Roger reverted his changes it appears, so
 it should pass now.

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Kaveh R. Ghazi]

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

From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: roger@eyesopen.com, rth@redhat.com
Cc: davem@redhat.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
        gcc-prs@gcc.gnu.org, jakub@redhat.com
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Date: Wed, 2 Oct 2002 10:46:13 -0400 (EDT)

  > From: Roger Sayle <roger@eyesopen.com>
  > 
  > > One is sort of meaningless all on its own.  You have to know what
  > > sort of comparison is going to be used with it.o
  > > Hum, actually that's true with NaN and UNORDERED as well.
  > > I.e. this is all bogus for COMPARE targets.
  > 
  > My apologies to that sparc64 maintainers.  The HP-UX solution is
  > indeed inapplicable for COMPARE targets.
  > 
  > I also now realize my mistake trying to analyze this problem.  I was
  > running "cc1" with "-m64 -O2" whilst debuging in gdb, as these were
  > the same flags I used to run gcc.  The problem is that gcc also
  > passes  "-mcpu=v9" to cc1, and this flag is required to exhibit
  > the problem.  It turns out that its the sparc64's constant pool
  > handling that hides the optimization, rather than the optimization
  > triggering and not being representable in the machine description.
 
 So what does that mean with respect to addressing the testcase?
 Fixable?  XFAIL it?
 
 		--Kaveh
 --
 Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Roger Sayle]

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

From: Roger Sayle <roger@eyesopen.com>
To: Richard Henderson <rth@redhat.com>
Cc: <gcc-bugs@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <ghazi@caip.rutgers.edu>,
        <davem@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, 30 Sep 2002 18:03:59 -0600 (MDT)

 > One is sort of meaningless all on its own.  You have to know what
 > sort of comparison is going to be used with it.o
 > Hum, actually that's true with NaN and UNORDERED as well.
 > I.e. this is all bogus for COMPARE targets.
 
 My apologies to that sparc64 maintainers.  The HP-UX solution is
 indeed inapplicable for COMPARE targets.
 
 I also now realize my mistake trying to analyze this problem.  I was
 running "cc1" with "-m64 -O2" whilst debuging in gdb, as these were
 the same flags I used to run gcc.  The problem is that gcc also
 passes  "-mcpu=v9" to cc1, and this flag is required to exhibit
 the problem.  It turns out that its the sparc64's constant pool
 handling that hides the optimization, rather than the optimization
 triggering and not being representable in the machine description.
 
 Sorry for the confusion.  You can tell I haven't done much work
 with gcc on sparc/solaris.
 
 Roger
 --
 Roger Sayle,                         E-mail: roger@eyesopen.com
 OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
 Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
 Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833
 

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: "David S. Miller" <davem@redhat.com>
Cc: davem@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   ghazi@caip.rutgers.edu, nobody@gcc.gnu.org, jakub@redhat.com,
   roger@eyesopen.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, 30 Sep 2002 16:51:51 -0700

 On Mon, Sep 30, 2002 at 04:22:33PM -0700, David S. Miller wrote:
 >    I.e. this is all bogus for COMPARE targets.
 >    
 > The whole set FCC bit, or just the "1" case?
 
 The whole set fcc bit.  "0" and "1" have no meaning for
 COMPARE.  Only for a particular NE/LT/etc result.
 
 
 r~

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[David S. Miller]

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

From: "David S. Miller" <davem@redhat.com>
To: rth@redhat.com
Cc: davem@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        ghazi@caip.rutgers.edu, nobody@gcc.gnu.org, jakub@redhat.com,
        roger@eyesopen.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, 30 Sep 2002 16:22:33 -0700 (PDT)

    From: Richard Henderson <rth@redhat.com>
    Date: Mon, 30 Sep 2002 16:24:21 -0700
 
    Not really.  Zero is easy:
    
    	fzeros	%f0
 
 I know this :-) but these instructions are TARGET_VIS only.
 Although it may seem like it, sparc64 != ultrasparc and I know
 quite a few people turning -mvis off in the work they are doing
 for other sparc64 processors.
 
    I.e. this is all bogus for COMPARE targets.
    
 The whole set FCC bit, or just the "1" case?

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: davem@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   ghazi@caip.rutgers.edu, nobody@gcc.gnu.org, davem@redhat.com,
   jakub@redhat.com, roger@eyesopen.com, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
Date: Mon, 30 Sep 2002 16:24:21 -0700

 On Mon, Sep 30, 2002 at 10:52:04PM -0000, davem@gcc.gnu.org wrote:
 >     The problem is, it's REALLY REALLY expensive to set the
 >     float condition codes to a constant value (two FPU synchronizing
 >     memory operations).
 
 Not really.  Zero is easy:
 
 	fzeros	%f0
 	fnot1s	%f1, %f0
 	fcmps	%fcc0, %f1, %f0
 
 (note that ~0 is a NaN).  One is sort of meaningless all on its own.
 You have to know what sort of comparison is going to be used with it.o
 Hum, actually that's true with NaN and UNORDERED as well.  I.e. this
 is all bogus for COMPARE targets.
 
 
 
 r~

Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[davem]

Synopsis: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

State-Changed-From-To: open->analyzed
State-Changed-By: davem
State-Changed-When: Mon Sep 30 15:52:04 2002
State-Changed-Why:
    The problem is, it's REALLY REALLY expensive to set the
    float condition codes to a constant value (two FPU synchronizing memory operations).
    
    If I implement these patterns, will they actually be output
    ever?
    
    I think it's really totally silly to require a backend
    to implement these patterns.  I can think of a few other
    platforms where this is quite expensive.
    
    Is there some way to remove the requirement?
    
    Has the compiler documentation been updated to reflect
    this new pattern requirement?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8087

target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64

[ghazi]

>Number:         8087
>Category:       target
>Synopsis:       sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 28 21:46:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Kaveh Ghazi
>Release:        gcc version 3.3 20020928 (experimental)
>Organization:
>Environment:
sparc-sun-solaris2.7
sparcv9-sun-solaris2.8
sparc64-sun-solaris2.8
>Description:
There are failures in execute/20020720-1.c with sparc -m64 or on sparcv9/sparc64, see:

http://gcc.gnu.org/ml/gcc-testresults/2002-09/msg00640.html
http://gcc.gnu.org/ml/gcc-testresults/2002-09/msg00822.html
http://gcc.gnu.org/ml/gcc-testresults/2002-09/msg00533.html
>How-To-Repeat:
On sparc-sun-solaris2.7, compile the testcase with -m64 -O, i.e.:

cc1 -fpreprocessed 20020720-1.i -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet -dumpbase 20020720-1.c -m64 -auxbase 20020720-1 -O -version -o 20020720-1.s

>Fix:
Roger Sayle suggested this:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01729.html

>Release-Note:
>Audit-Trail:
>Unformatted: