gcc code generation problems

[Marius Strobl]

On Thu, Mar 04, 2010 at 07:31:34AM +1100, Peter Jeremy wrote:
> On 2010-Mar-03 20:53:55 +0100, Marius Strobl <marius at alchemy.franken.de> wrote:
> >On Mon, Mar 01, 2010 at 06:23:30AM +1100, Peter Jeremy wrote:
> >> I've been trying to use FreeBSD 8-stable from a couple of weeks ago on
> >> a SunBlade 1500 to investigate some perl problems I'm seeing on
> >> Solaris and have bumped into different and more worrying problems on
> >> FreeBSD.
> >> 
> >> In particular, the test program used to determine the number of
> >> fraction bits in a double (slightly adapted variant attached) is
> >
> >There was no attachment.
> 
> Oops, sorry.  It's attached now.  Try comparing the output from
> running "cc tryfp.c;./a.out" with "cc -O2 tryfp.c;./a.out".
> 
> The correct answer is 53.
> 

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

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?
Unfortunately, I currently fail to find a reference to this
although I remember to have read at least one analysis of this
issue on the web and a note about it in some ABI documentation.

Marius