[build] Move unwinder to toplevel libgcc
Rainer Orth
ro@CeBiTec.Uni-Bielefeld.DE
Mon Jun 20 15:47:00 GMT 2011
[Dropping the target maintainers from the Cc: since this isn't relevant
to the patch at hand.]
"Joseph S. Myers" <joseph@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
More information about the Gcc-patches
mailing list