This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

From: Roger Sayle <>
To: Richard Henderson <>
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 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 Sayle,                         E-mail:
 OpenEye Scientific Software,         WWW:
 Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
 Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]