From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQeQE-0007SK-3M for qemu-devel@nongnu.org; Sun, 29 May 2011 07:44:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QQeQC-0002tu-Sn for qemu-devel@nongnu.org; Sun, 29 May 2011 07:44:42 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:50751) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQeQC-0002tq-GY for qemu-devel@nongnu.org; Sun, 29 May 2011 07:44:40 -0400 Message-ID: <4DE2317B.7050701@web.de> Date: Sun, 29 May 2011 13:43:55 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1305468801-6015-1-git-send-email-aurelien@aurel32.net> <1305468801-6015-7-git-send-email-aurelien@aurel32.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: andreas.faerber@web.de Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 06/11] target-i386: use floatx80 constants in helper_fld*_ST0() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Aurelien Jarno Cc: qemu-devel@nongnu.org Am 21.05.11 11:35, schrieb Andreas F=E4rber: > Am 20.05.2011 um 12:32 schrieb Peter Maydell: > >> On 15 May 2011 15:13, Aurelien Jarno wrote: >>> Instead of using a table which doesn't correspond to anything from >>> physical in the CPU, use directly the constants in helper_fld*_ST0(). >> >> Actually I rather suspect there is effectively a table in the CPU >> indexed by the last 3 bits of the FLD* opcode... It would be >> possible to implement this group of insns in QEMU with a single >> helper function that took the index into the array, but since the >> array seems to be causing weird compilation problems we might >> as well stick with the lots-of-helpers approach, at which point >> this is a sensible cleanup. > > In OpenBIOS we once ran into a similar error on ppc64 where a cast=20 > would've resulted in the truncation of a static pointer ... could this=20 > be an alignment issue here, that it's being truncated by the floatx80=20 > cast? I tried using __attribute__((packed)) on the floatx80 type=20 > without luck. > Or maybe the constant width is being handled weird, with LL being 128=20 > bits rather than the expected 64 bits? ;) Some more info: The issue only pops up with -std=3Dc99 or -std=3Dgnu99, with both gcc 3.4= .3=20 and 4.3.2. That's reproducible on Darwin gcc 4.0.1 and 4.2 as well. The following trivial sample program triggers it, there's no magic=20 Solaris headers involved: #include // on OpenSolaris: // typedef unsigned short uint16_t; // typedef unsigned long long uint64_t; typedef struct { uint64_t low; uint16_t high; } floatx80; #define make_floatx80(exp, mant) ((floatx80) { mant, exp }) #define floatx80_l2t make_floatx80( 0x4000, 0xd49a784bcd1b8afeLL ) static const floatx80 mine[1] =3D { floatx80_l2t, }; int main(void) { } Any thoughts? Andreas