From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15918 invoked by alias); 13 Dec 2004 16:12:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 15021 invoked from network); 13 Dec 2004 16:12:33 -0000 Received: from unknown (HELO develer.com) (151.38.19.110) by sourceware.org with SMTP; 13 Dec 2004 16:12:33 -0000 Received: (qmail 18889 invoked from network); 13 Dec 2004 16:12:23 -0000 Received: from beetle.trilan (HELO ?10.3.3.189?) (?U2FsdGVkX18qTf9eT9pUs4xEBghXCXLReDyHi5rY36Q=?@10.3.3.189) by trinity.trilan with SMTP; 13 Dec 2004 16:12:23 -0000 Message-ID: <41BDBF67.9000707@develer.com> Date: Mon, 13 Dec 2004 16:12:00 -0000 From: Bernardo Innocenti User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) MIME-Version: 1.0 To: Paul Schlie CC: mark@codesourcery.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Revised release criteria for GCC 4.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00457.txt.bz2 Paul Schlie wrote: >>Working with the SC, I have prepared revised release criteria for GCC 4.0, >>which are available here: >> >>http://gcc.gnu.org/gcc-4.0/criteria.html >> >>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 >>absolutes. > > 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. \X/ http://www.develer.com/