Date: Wed, 3 Mar 2010 23:14:09 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Peter Jeremy <peterjeremy@acm.org> Cc: freebsd-sparc64@freebsd.org Subject: Re: gcc code generation problems Message-ID: <20100303221409.GM18466@alchemy.franken.de> In-Reply-To: <20100303203134.GA13366@server.vk2pj.dyndns.org> References: <20100228192329.GA68252@server.vk2pj.dyndns.org> <20100303195354.GA38017@alchemy.franken.de> <20100303203134.GA13366@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 04, 2010 at 07:31:34AM +1100, Peter Jeremy wrote: > On 2010-Mar-03 20:53:55 +0100, Marius Strobl <marius@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@t1-105:/tmp > grep cpu0 /var/run/dmesg.boot cpu0: Sun Microsystems UltraSparc-IIi Processor (440.04 MHz CPU) marius@t1-105:/tmp > cc tryfp.c;./a.out 53 marius@t1-105:/tmp > cc -O2 tryfp.c;./a.out 53 marius@v215:/tmp > grep cpu0 /var/run/dmesg.boot cpu0: Sun Microsystems UltraSparc-IIIi Processor (1504.00 MHz CPU) marius@v215:/tmp > cc tryfp.c;./a.out 53 marius@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100303221409.GM18466>