From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32720 invoked by alias); 29 Apr 2013 20:11:14 -0000 Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org Received: (qmail 32710 invoked by uid 89); 29 Apr 2013 20:11:14 -0000 X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from oarmail.oarcorp.com (HELO OARmail.OARCORP.com) (67.63.146.244) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 29 Apr 2013 20:11:08 +0000 Received: from [192.168.1.157] (192.168.1.157) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 29 Apr 2013 15:11:07 -0500 Message-ID: <517ED3DA.2020501@oarcorp.com> Date: Mon, 29 Apr 2013 20:11:00 -0000 From: Joel Sherrill User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Guy CC: Crossgcc list Subject: Re: AVR32 support in crosstool-ng References: <517EBC1B.5050007@oarcorp.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00029.txt.bz2 On 4/29/2013 2:49 PM, Martin Guy wrote: > On 29 April 2013 20:29, Joel Sherrill wrote: >> Why doesn't Atmel submit their patches upstream? > They would never be accepted as long as they make modifications to > cpu-agnostic portions of GCC. Yep. But it speaks poorly of the port if they did that and didn't try to find a way to address it. :) >> As an embedded FOSS community, we need to be encouraging >> vendors.. prodding them.. to submit their tools upstream. > Absolutely. After all, chip vendors make their money by selling > silicon, not compilers. Agreed. > But it's not only a technical issue. The GCC maintainers also need to > believe that the port will continue to be maintained, tested, the code > updated to new versions of GCC, that bugs found will be fixed and so > on, i.e. a commitment from the vendor to help with to the ongoing work > of software maintenance. I understand completely. I am the GCC RTEMS maintainer. OTOH I wonder why a chip vendor would be opposed to this. Wouldn't they want an improving rather than dead end compiler?[1] And yes sometimes they pay someone to do the port and not to update it. So they don't have in-house expertise and there is no long plan to support it except maybe to pay the consultant again per bug. As a community, we just aren't doing a good job of selling the idea that merging and maintaining benefits both sides. It has to be cheaper to keep it up to date and tested versus jumping 4 or 5 major gcc versions. But it is cheaper to do the port, throw it to users and walk away. Sorry for the rant. I have managed to prod behind the scenes and get a couple of ports merged into the FSF. One was easy. One has been taken over two years and is just now getting merged. I just get frustrated when I see other targets out in the cold. [1] Both the msp430 and avr32 are based on gcc versions which are in the 4.3/4.4 version range. Those are dead. 4.6 was just closed. > M -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 -- For unsubscribe information see http://sourceware.org/lists.html#faq