Date: Fri, 5 Mar 2010 06:02:16 +1100 From: Peter Jeremy <peterjeremy@acm.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: freebsd-sparc64@freebsd.org Subject: Re: gcc code generation problems Message-ID: <20100304190216.GF17640@server.vk2pj.dyndns.org> In-Reply-To: <20100303221409.GM18466@alchemy.franken.de> References: <20100228192329.GA68252@server.vk2pj.dyndns.org> <20100303195354.GA38017@alchemy.franken.de> <20100303203134.GA13366@server.vk2pj.dyndns.org> <20100303221409.GM18466@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Mar-03 23:14:09 +0100, Marius Strobl <marius@alchemy.franken.de> wr= ote: >Hrm, this appears to be CPU specific (but neither FreeBSD nor compiler >version specific): >marius@t1-105:/tmp > grep cpu0 /var/run/dmesg.boot=20 >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=20 >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 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 >=3D 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) =3D=3D 0.0 A precision loss would mean that it saw (double)(1UL | 1UL << 52) =3D=3D (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. --=20 Peter Jeremy --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuQA7gACgkQ/opHv/APuIcZpwCdH8aWkVZa9BfU71t1HXVKKGcG EToAoK5qvKbobtqaVWZ9u+Y+oU89ooOS =nhaz -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100304190216.GF17640>