gcc code generation problems

Peter Jeremy peterjeremy at acm.org
Thu Mar 4 19:02:25 UTC 2010

On 2010-Mar-03 23:14:09 +0100, Marius Strobl <marius at alchemy.franken.de> wrote:
>Hrm, this appears to be CPU specific (but neither FreeBSD nor compiler
>version specific):
>marius at t1-105:/tmp > grep cpu0 /var/run/dmesg.boot 
>cpu0: Sun Microsystems UltraSparc-IIi Processor (440.04 MHz CPU)
>marius at t1-105:/tmp > cc tryfp.c;./a.out
>marius at t1-105:/tmp > cc -O2 tryfp.c;./a.out
>marius at v215:/tmp > grep cpu0 /var/run/dmesg.boot 
>cpu0: Sun Microsystems UltraSparc-IIIi Processor (1504.00 MHz CPU)
>marius at v215:/tmp > cc tryfp.c;./a.out
>marius at v215:/tmp > cc -O2 tryfp.c;./a.out

Interesting.  My SB1500 has:
cpu0: Sun Microsystems UltraSparc-IIIi Processor (1062.00 MHz CPU)
Unfortunately, I don't have access to any other SPARCs running FreeBSD
or any older SPARCs at all.

>There's some well known difference between spitfire-class (i.e.
>sun4u < USIII) and cheetah-class (i.e. sun4u >= USIII) CPUs where
>IIRC the latter do some floating point operations with higher
>precision in hardware while the former rely on software emulation,
>leading to different albeit both "correct" results as only the
>less precise software emulation is guaranteed.  Could this also
>be the reason for the unexpected result you're seeing?

I recall seeing references to long double being emulated but I wasn't
aware that any CPUs emulated double operations.

I will do some more investigating but I don't see this as being
an explanation as the USIIIi answer is not correct: enabling the
prints shows that, with optimisation, the USIIIi reports
  (double)(1UL | 1UL << 52) == 0.0
A precision loss would mean that it saw
  (double)(1UL | 1UL << 52) == (double)(1UL << 52)

Note that Sun Studio 12.1 on OpenSolaris gets the correct answer,
as does gcc without optimisation, so even if it is hardware issue,
it can be worked around in software.

Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20100304/8b53c483/attachment.pgp

More information about the freebsd-sparc64 mailing list