public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* target/10348: sparc64-sun-solaris2.7 testsuite failure in execute/20020720-1.c with -fpic/-fPIC
@ 2003-04-08 14:56 ghazi
  0 siblings, 0 replies; 3+ messages in thread
From: ghazi @ 2003-04-08 14:56 UTC (permalink / raw)
  To: gcc-gnats; +Cc: roger


>Number:         10348
>Category:       target
>Synopsis:       sparc64-sun-solaris2.7 testsuite failure in execute/20020720-1.c with -fpic/-fPIC
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 08 14:56:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Kaveh Ghazi
>Release:        gcc version 3.3 20030408 (prerelease)
>Organization:
>Environment:
sparc64-sun-solaris2.7
>Description:
As noted here:
http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00483.html

I'm getting testsuite failures in execute/20020720-1.c on sparc64-sun-solaris2.7 at -O1 and above when adding -fpic or -fPIC to the testsuite pass.  The logfile shows that the function `link_error' is still called, i.e. the call is not being optimized away like it should.

>How-To-Repeat:
Target sparc64-sun-solaris2.7 and compile 20020720-1.i with:

cc1 -fpreprocessed 20020720-1.i -quiet -dumpbase 20020720-1.c -auxbase 20020720-1 -O -version -fpic -o 20020720-1.s

If you grep for `link_error' in the .s file you'll see it's still being called.  If you take out -fpic, the optimization succeeds.


# 1 "20020720-1.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "20020720-1.c"






extern void abort (void);
extern double fabs (double);
extern void link_error (void);

void
foo (double x)
{
  double p, q;

  p = fabs (x);
  q = 0.0;
  if (p < q)
    link_error ();
}

int
main()
{
  foo (1.0);
  return 0;
}
>Fix:

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: target/10348: sparc64-sun-solaris2.7 testsuite failure in execute/20020720-1.c with -fpic/-fPIC
@ 2003-04-10 14:16 Roger Sayle
  0 siblings, 0 replies; 3+ messages in thread
From: Roger Sayle @ 2003-04-10 14:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Roger Sayle <roger@www.eyesopen.com>
To: Kaveh Ghazi <ghazi@caip.rutgers.edu>,
   Eric Botcazou <ebotcazou@libertysurf.fr>
Cc: gcc-gnats@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>
Subject: Re: target/10348: sparc64-sun-solaris2.7 testsuite failure in
 execute/20020720-1.c with -fpic/-fPIC
Date: Thu, 10 Apr 2003 07:11:31 -0600 (MDT)

 On Thu, 10 Apr 2003, Eric Botcazou wrote:
 > > I'm getting testsuite failures in execute/20020720-1.c on
 > > sparc64-sun-solaris2.7 at -O1 and above when adding -fpic or -fPIC to the
 > > testsuite pass.  The logfile shows that the function `link_error' is still
 > > called, i.e. the call is not being optimized away like it should.
 >
 > Note that this happens on sparc-sun-solaris2.9 too with -mcpu=v7|v8|v9.
 
 Unfortunately, there is no simple fix to the problem.  The 64-bit sparc
 PIC targets require three instructions to compare a floating point value
 against zero: the first to store the constant pool address+offset in a
 register, the second to load this into a FP register and a third to do
 the comparison.  Hence comparing "fabs" against zero requires four
 instructions.  This is one too many for combine, where this optimization
 normally gets applied, which only considers up to three instructions.
 
 I would recommend marking 20020720-1.x as XFAIL on sparc with a 64bit
 CPU type and -fpic or -fPIC, and lowering the GNATS PR priority to low.
 However, I believe the issue should be resolved shortly as soon as my
 "REG_EQUAL notes on cond_jumps" patch gets approved.  Its been a month!
 http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00824.html
 
 This patch should allow GCSE to optimize "fabs(x) < 0.0" itself,
 independently of the floating point load and conditional branch
 instructions provided by the target's machine description.  I suspect
 this will fix 20020720-1.c on all GCC targets that don't require FP
 comparisons to be performed by libcalls (but that currently require
 four or more instructions).  I'm also investigating a libcall fix.
 
 Roger
 --
 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: target/10348: sparc64-sun-solaris2.7 testsuite failure in execute/20020720-1.c with -fpic/-fPIC
@ 2003-04-10  8:36 Eric Botcazou
  0 siblings, 0 replies; 3+ messages in thread
From: Eric Botcazou @ 2003-04-10  8:36 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: ghazi@caip.rutgers.edu
Cc: gcc-gnats@gcc.gnu.org,
 gcc-bugs@gcc.gnu.org,
 roger@eyesopen.com
Subject: Re: target/10348: sparc64-sun-solaris2.7 testsuite failure in execute/20020720-1.c with -fpic/-fPIC
Date: Thu, 10 Apr 2003 10:25:24 +0200

 > I'm getting testsuite failures in execute/20020720-1.c on
 > sparc64-sun-solaris2.7 at -O1 and above when adding -fpic or -fPIC to the
 > testsuite pass.  The logfile shows that the function `link_error' is still
 > called, i.e. the call is not being optimized away like it should.
 
 Note that this happens on sparc-sun-solaris2.9 too with -mcpu=v7|v8|v9.
 
 -- 
 Eric Botcazou


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-04-10 14:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-08 14:56 target/10348: sparc64-sun-solaris2.7 testsuite failure in execute/20020720-1.c with -fpic/-fPIC ghazi
2003-04-10  8:36 Eric Botcazou
2003-04-10 14:16 Roger Sayle

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).