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
[EMAIL PROTECTED]
