From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16207 invoked by alias); 10 Apr 2003 14:16:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 16110 invoked by uid 71); 10 Apr 2003 14:16:01 -0000 Date: Thu, 10 Apr 2003 14:16:00 -0000 Message-ID: <20030410141601.16109.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Roger Sayle Subject: Re: target/10348: sparc64-sun-solaris2.7 testsuite failure in execute/20020720-1.c with -fpic/-fPIC Reply-To: Roger Sayle X-SW-Source: 2003-04/txt/msg00435.txt.bz2 List-Id: The following reply was made to PR target/10348; it has been noted by GNATS. From: Roger Sayle To: Kaveh Ghazi , Eric Botcazou Cc: gcc-gnats@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 --