From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32273 invoked by alias); 14 Mar 2008 17:09:19 -0000 Received: (qmail 31880 invoked by uid 22791); 14 Mar 2008 17:09:18 -0000 X-Spam-Check-By: sourceware.org Received: from h1283867.stratoserver.net (HELO smtp.plastictree.net) (85.214.127.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Mar 2008 17:08:25 +0000 Received: (qmail 32019 invoked from network); 14 Mar 2008 17:08:16 -0000 Received: from private (HELO private) (6c1fea9302378c1f46ec4a21e5c4ce6d4a8188b7) by h1283867.stratoserver.net with ESMTPS (DHE-RSA-AES256-SHA encrypted) (cert private); 14 Mar 2008 17:08:16 -0000 Received: (qmail 24190 invoked by uid 527); 14 Mar 2008 17:13:45 -0000 Date: Fri, 14 Mar 2008 17:09:00 -0000 From: Lasse Kliemann To: gcc-help@gcc.gnu.org Subject: Re: 4.3.0 strange problem with computation and optimization Message-ID: <20080314171345.GD2696@lasse.mail.plastictre.net> References: <20080312173125.GE2471@lasse.mail.plastictre.net> <47D813F5.2060301@redhat.com> <47D8143F.30607@redhat.com> <8bc817ee0803130330o2f0f03c3q75fd535f640fc1c1@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a2FkP9tdjPU2nyhF" Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00136.txt.bz2 --a2FkP9tdjPU2nyhF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 889 * Message by -Dario Saccavino- from Thu 2008-03-13: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D323 > > > > > > Did all lose interest? Or is there a plan to do some kind of fix? > > >=20 > I haven't found any comment on the effect of sse/sse2 on this "bug". >=20 > Anybody knows if using -msse2 -mfpmath=3Dsse can help obtain a better > conformant assembly? The sse regs should have the correct precision > (32 for float, 64 for double), so maybe part of the undesired > behaviour can be avoided. All I can tell you is that after a study of several comments, I chose to us= e=20 that. So far, I have no complaints about it. In fact, I am using -mssse3,=20 which seems to be the "highest" such extension on the Xeon 5310, according = to=20 /proc/cpuid. I could not measure any performance gain compared to -msse2,=20 however. Next step will be to install a 64 bit system. Lasse --a2FkP9tdjPU2nyhF Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 835 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) iQIcBAEBAgAGBQJH2rJJAAoJEFYll6N4nhdvygEQANXq6nTyt7XIkDTVowS0OML5 GV125B1EgSPnigjib68watwa1LcPaadEsuBTdcUkb6LJRlHX/7+eZ+MRrdAef2o+ 1KrSBXG11QpPwxL/9cNgZcvmEsGVgc99+1mPTrkaz4s9DKhoTbZtL2+3um8VdQiP xbXHSFswgkYycIY4zQ7zfDjJNsuKbCmJfB7Pg4LQ/wsn8uJw/O5YwZwgpMpFY9nB Kg/y5a6l/YyMNIs9vYFUa6tGw9sq5gS+upOTGK4l3LeEoHgFyx4zc0324A+4MPMf vvkalrhlurVcAks/eqKVJ+1YyfexwCuXsiuXMiY0dKLFjPtYsj6kOIWns8WVw0XK HVQDm3XEvi3uJuawKDLYr+y0rxzFSCyAS/yObWcQHC6u65jr9WqKoStJ++DBe3Bl cuMkJhRijOXpcuDW4WNDFFgNrhamHn/RhaGjju5IGSOQTwgCdMpQbzYgdJ2nOj69 c1Qhd4+A+byxrkzZ/MO6PtGkjmVNgv7NGnQ3Hqae2gB058dVxTDmaajx1EHD1l5f iPD/mLv7tef172akF6Mc63JHbIzNPO3wc1EVlkhweVJgZy6sw7rkQRzNACXct4so lgElSSHwajlUWBedkx1a3n5EqyhD7W/w2yCSRVAJHMt9GFOnWSBPSYH+d7tjjyYb xlCYos+8WxKqTzp9ZJZT =0BRJ -----END PGP SIGNATURE----- --a2FkP9tdjPU2nyhF--