From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 4 19:02:25 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 977EF106566B for ; Thu, 4 Mar 2010 19:02:25 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 261E58FC1D for ; Thu, 4 Mar 2010 19:02:24 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-253-149.belrs3.nsw.optusnet.com.au [122.106.253.149]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o24J2IVj023775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Mar 2010 06:02:19 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o24J2GDK047266; Fri, 5 Mar 2010 06:02:16 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o24J2GGB047265; Fri, 5 Mar 2010 06:02:16 +1100 (EST) (envelope-from peter) Date: Fri, 5 Mar 2010 06:02:16 +1100 From: Peter Jeremy To: Marius Strobl Message-ID: <20100304190216.GF17640@server.vk2pj.dyndns.org> References: <20100228192329.GA68252@server.vk2pj.dyndns.org> <20100303195354.GA38017@alchemy.franken.de> <20100303203134.GA13366@server.vk2pj.dyndns.org> <20100303221409.GM18466@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: <20100303221409.GM18466@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-sparc64@freebsd.org Subject: Re: gcc code generation problems X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 19:02:25 -0000 --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 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--