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