public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 11:46 Richard Henderson
0 siblings, 0 replies; 19+ messages in thread
From: Richard Henderson @ 2002-10-07 11:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 11:46 Roger Sayle
0 siblings, 0 replies; 19+ messages in thread
From: Roger Sayle @ 2002-10-07 11:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 11:36 David S. Miller
0 siblings, 0 replies; 19+ messages in thread
From: David S. Miller @ 2002-10-07 11:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 11:26 Roger Sayle
0 siblings, 0 replies; 19+ messages in thread
From: Roger Sayle @ 2002-10-07 11:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 10:26 Kaveh R. Ghazi
0 siblings, 0 replies; 19+ messages in thread
From: Kaveh R. Ghazi @ 2002-10-07 10:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 9:26 Roger Sayle
0 siblings, 0 replies; 19+ messages in thread
From: Roger Sayle @ 2002-10-07 9:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 9:26 David S. Miller
0 siblings, 0 replies; 19+ messages in thread
From: David S. Miller @ 2002-10-07 9:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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))"
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 9:16 Roger Sayle
0 siblings, 0 replies; 19+ messages in thread
From: Roger Sayle @ 2002-10-07 9:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
--
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 9:16 David S. Miller
0 siblings, 0 replies; 19+ messages in thread
From: David S. Miller @ 2002-10-07 9:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-07 0:22 davem
0 siblings, 0 replies; 19+ messages in thread
From: davem @ 2002-10-07 0:22 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, ghazi, nobody, rth, davem, jakub, roger
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-03 8:06 Kaveh R. Ghazi
0 siblings, 0 replies; 19+ messages in thread
From: Kaveh R. Ghazi @ 2002-10-03 8:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-02 17:26 David S. Miller
0 siblings, 0 replies; 19+ messages in thread
From: David S. Miller @ 2002-10-02 17:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-10-02 7:56 Kaveh R. Ghazi
0 siblings, 0 replies; 19+ messages in thread
From: Kaveh R. Ghazi @ 2002-10-02 7:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-09-30 17:26 Roger Sayle
0 siblings, 0 replies; 19+ messages in thread
From: Roger Sayle @ 2002-09-30 17:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-09-30 16:56 Richard Henderson
0 siblings, 0 replies; 19+ messages in thread
From: Richard Henderson @ 2002-09-30 16:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-09-30 16:36 David S. Miller
0 siblings, 0 replies; 19+ messages in thread
From: David S. Miller @ 2002-09-30 16:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-09-30 16:26 Richard Henderson
0 siblings, 0 replies; 19+ messages in thread
From: Richard Henderson @ 2002-09-30 16:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-09-30 15:52 davem
0 siblings, 0 replies; 19+ messages in thread
From: davem @ 2002-09-30 15:52 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, ghazi, nobody, rth, davem, jakub, roger
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64
@ 2002-09-28 21:46 ghazi
0 siblings, 0 replies; 19+ messages in thread
From: ghazi @ 2002-09-28 21:46 UTC (permalink / raw)
To: gcc-gnats; +Cc: rth, davem, jakub, roger
>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:
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2002-10-07 18:46 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-07 11:46 target/8087: sparc-sun-solaris2.7 C testsuite failures in execute/20020720-1.c w/-m64 or on sparcv9/sparc64 Richard Henderson
-- strict thread matches above, loose matches on Subject: below --
2002-10-07 11:46 Roger Sayle
2002-10-07 11:36 David S. Miller
2002-10-07 11:26 Roger Sayle
2002-10-07 10:26 Kaveh R. Ghazi
2002-10-07 9:26 Roger Sayle
2002-10-07 9:26 David S. Miller
2002-10-07 9:16 Roger Sayle
2002-10-07 9:16 David S. Miller
2002-10-07 0:22 davem
2002-10-03 8:06 Kaveh R. Ghazi
2002-10-02 17:26 David S. Miller
2002-10-02 7:56 Kaveh R. Ghazi
2002-09-30 17:26 Roger Sayle
2002-09-30 16:56 Richard Henderson
2002-09-30 16:36 David S. Miller
2002-09-30 16:26 Richard Henderson
2002-09-30 15:52 davem
2002-09-28 21:46 ghazi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).