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
>53
>marius at t1-105:/tmp > cc -O2 tryfp.c;./a.out
>53
>
>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
>53
>marius at v215:/tmp > cc -O2 tryfp.c;./a.out
>51

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