This is the mail archive of the
mailing list for the GCC project.
Re: Revised release criteria for GCC 4.0
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: mark at codesourcery dot com, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Mon, 13 Dec 2004 17:12:23 +0100
- Subject: Re: Revised release criteria for GCC 4.0
- References: <BDE3141D.835Ffirstname.lastname@example.org>
Paul Schlie wrote:
Working with the SC, I have prepared revised release criteria for GCC 4.0,
which are available here:
These revisions include changes to the set of primary and secondary platforms
to more accurately reflect the platforms currently thought to be important,
and also include more realistic goals for validation.
Comments are welcome, and we might make changes if there is sufficient
momentum in a particular direction. However, I would suggest that you not
spend too much energy picking nits; our release criteria are guidelines, not
Although not a primary or secondary platform (which are all relatively
larger 32/64 bit targets), might it make sense to try to at least include
one small 8-bit secondary target representative of smaller simpler RISC
machines (such as AVR); with the objective that the target should at least
build (and ideally generate reasonably correct, albeit possibly not optimal
code), in an effort to try to maintain a more reasonably target size neutral
code base, rather than let unintended large target biases unnecessarily
manifest themselves into GCC?
I second this proposal. AVR is frequently broken by middle-end
patches, mostly because it's one of the few targets where int
is 16bit and bigger than a CPU register (8bit).
Besides, given the amount of material and development tools you can find
on the Internet for the AVR, this CPU appears to be *very* widely used.
We also have a GDB simulator for the AVR, but I'm afraid nobody ever
tried running the Dejagnu testsuite with it.
From my past experience with the m68k-elf target, I've learned that many
tests assume a full-blown libc and an underlying OS.
// Bernardo Innocenti - Develer S.r.l., R&D dept.