[Dropping the target maintainers from the Cc: since this isn't relevant to the patch at hand.]
"Joseph S. Myers" <jos...@codesourcery.com> writes: > On Mon, 20 Jun 2011, Rainer Orth wrote: > >> Certainly: your wiki entry gives a good overview. For the moment, I'll >> probably concentrate on the build side of things, though. I may attack >> gthr* stuff and fp-bit.[ch] next, both of which I can at least partially >> test on my targets. > > fp-bit.[ch] has the interesting issue of FLOAT_BIT_ORDER_MISMATCH and > FLOAT_WORD_ORDER_MISMATCH being defined by makefile rules when it ought to > be possible to deduce that information from macros predefined by the > compiler. (See what I said in > <http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02262.html> about the > meanings of those macros.) Thanks for the pointer. Those makefile rules are messy indeed, and what prompted me to consider looking into this stuff: I just had a mips-sgi-irix6.5 bootstrap break for me because the generated tp-bit.c was corrupted, most likely because both multilibs created the file quasi-simultaneously, mangling it in the process. > dfp-bit.* and fixed-bit.* can probably move along with fp-bit.* (or > before, or after), and I don't think there are any complicated issues > around those files. I'll have a look. I may move them together if I have to touch many of the same t-* files for that anyway. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University
