https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joseph at codesourcery dot com
--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
It seems this is a problem of byte/bit ordering and the way bitfields are
packed/unpacked in fp-bit.
The above cases use little endian on RX, so in fp-bit.h the following
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
#define FLOAT_BIT_ORDER_MISMATCH
#endif
will define FLOAT_BIT_ORDER_MISMATCH.
Removing that for 64-bit-double/libgcc fixes the test case.
In fp-bit.c/unpack_d, there is a comment:
/* We previously used bitfields to store the number, but this doesn't
handle little/big endian systems conveniently, so use shifts and
masks */
But then it goes on like
#ifdef FLOAT_BIT_ORDER_MISMATCH
fraction = src->bits.fraction;
exp = src->bits.exp;
sign = src->bits.sign;
#else
# if defined TFLOAT && defined HALFFRACBITS
so for its definition of little endian, it still uses bitfields.
This looks a bit odd and like some unfinished work.
It seems it's not the bitfield order as used in
#ifdef FLOAT_BIT_ORDER_MISMATCH
struct
{
unsigned int sign:1 __attribute__ ((packed));
unsigned int exp:EXPBITS __attribute__ ((packed));
fractype fraction:FRACBITS __attribute__ ((packed));
}
bits;
#endif
Trying to reverse the 3 fields doesn't help.
But for some reason, on RX sizeof (bits) is 12, not 8, when fp-bit is built for
DF. However, when built for SF, sizeof (bits) is 4, which is correct.
So that's where the problem comes from.
There might be some bitfield issue with the RX backend, but this aside, why
can't fp-bit just use the same shift-and-mask approach also for little endian?
Adding Joseph in CC because he's listed as soft-fp maintainer.
