GCC 4.3 target deprecation proposals

[Joel Sherrill <joel.sherrill@OARcorp.com>]

Joseph S. Myers wrote:
> On Thu, 24 Jan 2008, DJ Delorie wrote:
>
>   
>> At the moment, I'm working on getting sh, h8300, and m32c in shape for
>> 4.3 (or future).  I can easily get the test results under 400k by
>> removing some of the multilibs, but I don't think that's a good idea.
>> My sh-elf test tests 38 multilibs, if I only test one that would be a
>> 12k email, which would easily fit past the filters.  Are we
>> artificially penalizing targets with many multilibs?
>>     
>
> If results are being rejected without indicating the target is in terrible
> shape, you could ask overseers to increase the size limit on
> gcc-testresults.
>
> I'm not actually convinced these long default multilib lists are a good
> idea; if a user doesn't just want a single multilib for their processor,
> the long generic list is likely to be wrong for them as well.  

Depends on the user.  For *-rtems*, we build the OS proper
multilib and produce libraries.  The user links that against
a Board Support Package and their application.   We are
careful to justify each multilib variant in the RTEMS targets
since it does lead to longer compile times and longer tool
download times when our users install. 

Here is a count of the multilib variants for the targets we
have pre-compiled RTEMS for.  Note that all are using gcc
4.2.2 except AVR (4.0.4) and tic4x (3.4.6).

arm-rtems4.9 3
avr-rtems4.9 4
bfin-rtems4.9 1
h8300-rtems4.9 7
i386-rtems4.9 6
m68k-rtems4.9 15
mips-rtems4.9 6
powerpc-rtems4.9 15
sh-rtems4.9 11
sparc-rtems4.9 4
tic4x-rtems4.9 4

So you can see that even though we haven't figured out
how to run the GCC testsuite when linked against RTEMS,
we do have "good news" on a number of targets.

With some help from a gcc tester, we should be able to
start reporting results on many of the above using
simulators.

> sh has a
> mechanism for selecting multilibs at configure time, and a more general
> such mechanism would be good as well (for some targets such as GNU/Linux,
> it would need to deal with SYSROOT_SUFFIX_SPEC and
> SYSROOT_HEADERS_SUFFIX_SPEC as well as the usual multilib variables; note
> some targets already generate SYSROOT_SUFFIX_SPEC automatically).
>
>   
>> Also, while I'm not suggesting I be a maintainer for sh and h8300, if
>> I'm working on them and producing test results, should I send them in
>> anyway?  I can always stop sending them when I stop working on them
>> (for whatever reason), but meanwhile, does that count against
>> deprecation?
>>     
>
> Anyone sending results for a target counts against deprecation.  I didn't
> even look at what version the results are for (although maybe in the 4.4
> cycle we should only look at results for 4.3 or later).
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>