From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3890 invoked by alias); 14 Jan 2012 16:02:03 -0000 Received: (qmail 3721 invoked by uid 22791); 14 Jan 2012 16:02:00 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bk0-f49.google.com (HELO mail-bk0-f49.google.com) (209.85.214.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Jan 2012 16:01:46 +0000 Received: by bkty8 with SMTP id y8so4748309bkt.36 for ; Sat, 14 Jan 2012 08:01:45 -0800 (PST) Received: by 10.204.10.72 with SMTP id o8mr2147003bko.92.1326556905175; Sat, 14 Jan 2012 08:01:45 -0800 (PST) Received: from vostro ([178.123.249.118]) by mx.google.com with ESMTPS id n9sm25957744bkg.8.2012.01.14.08.01.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jan 2012 08:01:44 -0800 (PST) Date: Sat, 14 Jan 2012 16:02:00 -0000 From: Sergei Gavrikov To: John Dallaway cc: Ilija Kocho , eCos developers Subject: Re: Gnutools: consideration for upgrade to GCC 4.6 In-Reply-To: <4F11574D.9070002@dallaway.org.uk> Message-ID: References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/msg00010.txt.bz2 Hi all, 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? > > 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. Certainly we would need to adjust the multi-libbing for some > target architectures. Also we would take a look at the RTEMS (CVS -> 4.11) patches for their latest toolchain sources as they does use GCC 4.6.1 & binutils 2.21 for RTEMS (CVS) builds http://www.rtems.org/ftp/pub/rtems/SOURCES/4.11/ By the way I like their built-in __rtems__ definition for own GCC builds and I guess in the end we would propagate __ecos__ for own ones on the occasion of renewal. What do you think? IMHO, we also would start to use own labels in the prefixes for eCos toolchains (http://gcc.gnu.org/install/specific.html). What do you think about 'ecos' label in the prefixes as an OS-label? In ideal world the prefixes would be *-*-ecos2.0, *-*-ecos3.0, *-*-ecos4.0 for toolchains for eCos major releases to prevent the PATH collisions, and, perhaps, *-*-ecos., for eCos middle time (not full tested) releases, e.g. i386-elf-ecos3.12-gcc for 2012. And may be to have *-*-ecos as the prefixes is quite enough for us. (Excuse, if above looks like OFF-TOPIC). > 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. 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? IMHO, if we won't see volunteers for non arm-eabi targets also we should test new toolchain for Linux synthetic target at least (it would help us in the efforts on warning clean-ups for new toolchain). Sergei > It would be important to retain eCos source compatibility with the > current toolchains based on GCC 4.3.2. > > John Dallaway > eCos maintainer > http://www.dallaway.org.uk/john >