gcc code generation problems

[Peter Jeremy]

On 2010-Mar-01 06:23:30 +1100, Peter Jeremy <peterjeremy at acm.org> wrote:
>The correct answer is '53', but if optimisation is enabled, I'm
>getting '51' instead.  Disabling the printf() and/or using
>-fno-strict-aliasing has no effect.
>
>$ cc -DXXX -O tryfp.c; ./a.out
>a 4503599627370495 != 0
>51
>$ cc -DXXX -O2 tryfp.c; ./a.out
>a 4503599627370495 != 0
>51
>$ cc -DXXX tryfp.c; ./a.out
>a 18014398509481983 != 18014398509481984
>53
>$ 

I've done a bit more investigating and come to the conclusion that the
FP emulation code for fxtod is trashing %f12.  The problem does not
exist on OpenSolaris.  On FreeBSD, gcc expands a double to unsigned
long cast to:

	if (d >= (double)(1UL << 63)) {
		ul = (1UL << 63) ^ (long)(d - (double)(1UL << 63));
	} else {
		ul = (long)d;
	}

In the sample code, gcc calculates (double)(1UL << 63) at the top of
the function and stores it in %f12.  Somehow, this register turns into
0 on the 51st iteration, though nothing updates it.  If I pick a
different unused register (I've tried %f16, %f24 and %f32) then the
code works.  The "UltraSPARC IIIi Processor User's Manual", indicates
that fxtod will trap for operands >= 2^51 (fdtox will trap for
operands >= 2^53 and is therefore executed in hardware) which seems to
point the finger at the FP emulation code in the userland trap handler.

I am still looking into the emulation code.

-- 
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/20100308/1a98192f/attachment.pgp