Am 21.05.11 11:35, schrieb Andreas Färber:
Am 20.05.2011 um 12:32 schrieb Peter Maydell:
On 15 May 2011 15:13, Aurelien Jarno <aurel...@aurel32.net> 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
would've resulted in the truncation of a static pointer ... could this
be an alignment issue here, that it's being truncated by the floatx80
cast? I tried using __attribute__((packed)) on the floatx80 type
without luck.
Or maybe the constant width is being handled weird, with LL being 128
bits rather than the expected 64 bits? ;)
Some more info:
The issue only pops up with -std=c99 or -std=gnu99, with both gcc 3.4.3
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
Solaris headers involved:
#include <inttypes.h>
// 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] = {
floatx80_l2t,
};
int main(void)
{
}
Any thoughts?
Andreas
