AVR32 support in crosstool-ng

[Martin Guy <martinwguy at gmail dot com>]

Hi!
  I'm writing because I've updated the AVR32 support in crosstool-ng
to gcc-4.2.4, gcc-4.3.{3,6}, gcc-4.4.{3,7}, binutils-2.22 and all
versions of newlib, giving smaller code size at every step (which was
the whole point).
   However I don't feel that it's appropriate to include these patches
in mainline crosstool-ng for two reasons:
1) They're enormous: about a megabyte of patches for each version of
gcc, binutils and newlib version, and that's *after* trimming them to
the bare minimum, increasing the patches/ directory from 10MB to 15MB.
2) They need to modify toolchain components outside the avr32 files.
These changes are most likely harmless in binutils but in gcc they
introduce extra mysterious transformations in cpu-agnostic parts of
gcc, sometimes claiming in commentary that these changes should be OK
for other processors.

   Is there a way in GCC to say, in generic code, "#if building a
compiler targetting AVR32"? It sems unlikely as it foes against the
whole philosophy of keeing architecture-specific code in their own
subdirectories, but would make it possible to produce AVR32 patches
that don't change the behaviour of the tools when they are compiling
for other CPU architectures.

In the light of this, I've been hacking a copy of crosstool-ng at
http://spaces.atmel.com/gf/project/ct-ng
  The only changes are the addition of patch files, all of which have
"avr32" in the name and the addition of a default .config file.

  Can you let me know how this affects mainline crosstool-ng? Whether
wholesale support for new architectures is welcome or whether maybe a
tarball in the contrib/ directory would be more suitable?

Thanks again

    M

--
For unsubscribe information see http://sourceware.org/lists.html#faq