The easiest way to deal with the use of LIBGCC2_FLOAT_WORDS_BIG_ENDIAN
in libgcc is to define a preprocessor macro __FLOAT_WORD_ORDER__ similar
to how WORDS_BIG_ENDIAN was converted. That is, cppbuiltin.c will do:
cpp_define_formatted (FOO, "__FLOAT_WORD_ORDER__=%s",
(FLOAT_WORDS_BIG_ENDIAN
? "__ORDER_BIG_ENDIAN__"
: "__ORDER_LITTLE_ENDIAN__"));
and change any uses of LIBGCC2_FLOAT_WORDS_BIG_ENDIAN to consult
__FLOAT_WORD_ORDER__ instead.
A grep reveals that there are no target definitions of
LIBGCC2_FLOAT_WORDS_BIG_ENDIAN, so we should be OK with the
straightforward conversion, right?
This runs into a curious case in the arm backend, though, which has:
#define FLOAT_WORDS_BIG_ENDIAN (arm_float_words_big_endian ())
with no corresponding LIBGCC2_FLOAT_WORDS_BIG_ENDIAN. I think what this
means is that the places that care about the order of float words
(currently libdecnumber, libbid, and dfp-bit.h) will always use the
order indicated by __BYTE_ORDER__/WORDS_BIG_ENDIAN, even when the
backend is secretly using a different order.
ARM has probably gotten lucky wrt dfp-bit.h because it has its own
assembler fp routines that presumbly DTRT for unusual float word
orderings. (dfp-bit.h also does not *use* the setting of
LIBGCC2_FLOAT_WORDS_BIG_ENDIAN, so that helps.) But IIUC, using
__FLOAT_WORD_ORDER__ in the relevant libraries will break pre-existing
code that used libdecnumber and/or libbid. I am not conversant enough
with ARM ABIs and/or targets to know which ones would break.
The saving grace here is that decimal float is not enabled by default
for arm platforms, so there are likely very few, if any, users of
decimal float on ARM; it might be worthwhile to go ahead and fix things,
ignoring the fallout from earlier versions.
What do the ARM maintainers think? Should I prepare a patch for getting
rid of LIBGCC2_FLOAT_WORDS_BIG_ENDIAN and we'll declare decimal float
horribly broken pre-4.6? Or is there a better way forward?
-Nathan
