From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7716 invoked by alias); 14 Jan 2012 16:25:16 -0000 Received: (qmail 7679 invoked by uid 22791); 14 Jan 2012 16:25:12 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from tirion.supremecenter202.com (HELO tirion.supremecenter202.com) (209.25.195.243) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Jan 2012 16:24:59 +0000 Received: from c-32d8e155.355-1-64736c10.cust.bredbandsbolaget.se ([85.225.216.50]:34407 helo=[192.168.0.120]) by tirion.supremecenter202.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rm6PZ-0006FM-PZ; Sat, 14 Jan 2012 16:24:58 +0000 Message-ID: <4F11AC54.7000902@siva.com.mk> Date: Sat, 14 Jan 2012 16:25:00 -0000 From: Ilija Kocho User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: John Dallaway CC: eCos developers Subject: Re: Gnutools: consideration for upgrade to GCC 4.6 References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> In-Reply-To: <4F11574D.9070002@dallaway.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00011.txt.bz2 On 14.01.2012 11:22, John Dallaway wrote: > Hi Ilija and all > > Ilija Kocho wrote: > >> Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade. >> My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and >> FPU instructions, but I think that other architectures shall gain from >> newer compiler too. I have made some signal processing tests with GCC >> 4.6.2 against current eCos compiler and they show performance gain even >> with Cortex-M3 setting, though moderate. Performance is considerable >> when Cortex-M4 setting is selected and is tremendous, as expected, when >> SIMD are used. Recently introduced Cortex-M products with FPU (Kinetis >> K70, K61, STM32F4) will further emphasise the benefit. >> >> Another reason, maybe not so important, is that GCC 4.3 is not >> officially supported any more. >> >> Regarding this, I state my wish that we move to the latest stable GCC >> release, that is at present rel. 4.6.2, accompanied with respective >> binutils. I have tested binutils 2.21 but in meantime 2.22 has been >> released. Of course, the list wouldn't be complete without the latest GDB. > Moving to a more recent GCC makes sense to me. > > There are sure to be some new compiler warnings to deal with in the eCos > sources. Are you aware of the scale of this issue with eCos CVS and GCC > 4.6.2? If it could be some measure, the compilation of eCos library for the /default/ template (target K60N512) raises 11 warnings, all seem to be the same type: warning: variable ‘’ set but not used [-Wunused-but-set-variable] Some cases are unused variables indeed, but of some the usage is "hidden" (within asm() or macro). > > There are a few patches that were applied to current toolchain sources: > > ftp://ecos.sourceware.org/pub/ecos/gnutools/src/ > > It would be useful to review these and determine which are still > relevant. I have implemented them in my build (for ARM only). They seem to fit with the new code but regarding relevancy it probably requires more analysis and better knowledge of GCC intrinsics than mine. > Certainly we would need to adjust the multi-libbing for some > target architectures. > > It would also be useful to test eCos with the new toolchain in an > automated manner. I wonder if one of the maintainers at eCosCentric > could set up testing in their test farm? In any case, I would advocate a > cautious approach to roll out, creating an initial "test release" for > use mostly by those interested in the new features. This is a good approach. During the "test period" we can fix the warnings, etc. > We could also > consider building the toolchain for arm-eabi targets only in the first > instance to reduce overall effort. Does anyone on this list have a > particular interest in building eCos with recent GCC for another target > architecture? > > It would be important to retain eCos source compatibility with the > current toolchains based on GCC 4.3.2. This probably shall not be a (big) problem. GCC 4.6 (be it minor 0, 1 or 2) doesn't seem to require any changes other than elimination of warnings. From my experience, everything that works with GCC 4.3.2 also works with GCC 4.6. Of course some backward compatibility break is inevitable. The build options for new architectures are not supported by older versions (example -mcpu=cortex-m4). But that's why we're looking for the upgrade in the first place :) . Ilija Kocho