This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.3 target deprecation proposals
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. 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