Date: Sun, 21 Mar 2010 00:30:04 GMT From: Peter Jeremy <peterjeremy@acm.org> To: freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/144900: [patch] SPARC64 Floating point fixes Message-ID: <201003210030.o2L0U4mY051303@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR sparc64/144900; it has been noted by GNATS.
From: Peter Jeremy <peterjeremy@acm.org>
To: Marius Strobl <marius@alchemy.franken.de>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: sparc64/144900: [patch] SPARC64 Floating point fixes
Date: Sun, 21 Mar 2010 11:28:32 +1100
--cvVnyQ+4j833TQvp
Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ"
Content-Disposition: inline
--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2010-Mar-20 21:49:41 +0100, Marius Strobl <marius@alchemy.franken.de> wr=
ote:
>On Sat, Mar 20, 2010 at 08:11:20PM +1100, Peter Jeremy wrote:
>> - Parts of the emulator code must be compiled with no-strict-aliasing
>> specified to function correctly. CFLAGS is updated to include the
>> relevant gcc option. (This will add -fno-strict-aliasing to all of
>> libc - which is excessive but I don't believe it's possible to compile
>> only part of libc that way).
>
>Could you please elaborate on what exactly breaks when compiling
>with strict aliasing rules? I think there actually is a way to
>limit -no-strict-aliasing to the emulator part but I'd like to
>understand what's going on and make sure there's no way it can
>be solved by the code affected before turning it on.
OK. I spent some time looking at fpu_explode.c and came up with the
attached patch which seems to remove the requirement for=20
no-strict-aliasing (and I think the code looks cleaner as well).
--=20
Peter Jeremy
--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="sparc_fpu.diff2"
Content-Transfer-Encoding: quoted-printable
Index: lib/libc/sparc64/fpu/fpu_explode.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /usr/ncvs/src/lib/libc/sparc64/fpu/fpu_explode.c,v
retrieving revision 1.8.2.1
diff -u -r1.8.2.1 fpu_explode.c
--- lib/libc/sparc64/fpu/fpu_explode.c 3 Aug 2009 08:13:06 -0000 1.8.2.1
+++ lib/libc/sparc64/fpu/fpu_explode.c 21 Mar 2010 00:24:51 -0000
@@ -258,14 +261,12 @@
struct fpn *fp;
int type, reg;
{
- u_int32_t s, *sp;
- u_int64_t l[2];
- void *vl =3D l;
+ u_int32_t s;
+ u_int64_t l0, l1;
=20
if (type =3D=3D FTYPE_LNG || type =3D=3D FTYPE_DBL || type =3D=3D FTYPE_E=
XT) {
- l[0] =3D __fpu_getreg64(reg & ~1);
- sp =3D vl;
- fp->fp_sign =3D sp[0] >> 31;
+ l0 =3D __fpu_getreg64(reg & ~1);
+ fp->fp_sign =3D l0 >> 63;
} else {
s =3D __fpu_getreg(reg);
fp->fp_sign =3D s >> 31;
@@ -273,7 +274,7 @@
fp->fp_sticky =3D 0;
switch (type) {
case FTYPE_LNG:
- s =3D __fpu_xtof(fp, l[0]);
+ s =3D __fpu_xtof(fp, l0);
break;
=20
case FTYPE_INT:
@@ -285,12 +286,13 @@
break;
=20
case FTYPE_DBL:
- s =3D __fpu_dtof(fp, sp[0], sp[1]);
+ s =3D __fpu_dtof(fp, (u_int32_t)(l0 >>32), (u_int32_t)l0);
break;
=20
case FTYPE_EXT:
- l[1] =3D __fpu_getreg64((reg & ~1) + 2);
- s =3D __fpu_qtof(fp, sp[0], sp[1], sp[2], sp[3]);
+ l1 =3D __fpu_getreg64((reg & ~1) + 2);
+ s =3D __fpu_qtof(fp, (u_int32_t)(l0 >>32), (u_int32_t)l0,
+ (u_int32_t)(l1 >>32), (u_int32_t)l1);
break;
=20
default:
--mP3DRpeJDSE+ciuQ--
--cvVnyQ+4j833TQvp
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iEYEARECAAYFAkulaDAACgkQ/opHv/APuIetpgCeOw1phQBmIylc66Ym4x7Sm6tq
J7kAoMFI7KFt+hoR1sMLdPwUPjEB6aPI
=lfMD
-----END PGP SIGNATURE-----
--cvVnyQ+4j833TQvp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003210030.o2L0U4mY051303>