On 2012-02-24, Ilija Kocho <ili...@siva.com.mk> wrote:
> On 24.02.2012 18:10, Grant Edwards wrote:
>> On 2012-02-13, John Dallaway <j...@dallaway.org.uk> wrote:
>>
>>> Ilija Kocho has been working with a new set of GNU tools for ARM targets
>>> based on GCC 4.6.2. The new tools incorporate support for Cortex-M4 SIMD
>>> and FPU instructions. Ref:
>>>
>>> http://ecos.sourceware.org/ml/ecos-devel/2012-01/msg00003.html
>>>
>>> I have generated builds of these tools intended for wider testing within
>>> the eCos community. The test builds can be downloaded from the eCos ftp
>>> site and are located under the "gnutools" directory:
>>
>> FWIW, I just tried the new tools building a fairly simple eCos kernel
>> (based on CVS HEAD from a couple weeks ago) with FreeBSD stack
>> enabled. The kernel build generated 172 compiler warnings. About
>> half of those (89) are aliasing violations in the bsd stack source
>> code, so it looks like '-fno-strict-aliasing' needs to be added to
>> the compiler flags for the FreeBSD stack to safely use the new
>> toolchain.
>>
>> Of the remaining warnings, about half (45) are variables that are set
>> but never used. Most of them are in the FreeBSD stack, but there are
>> a smattering of them in other places as well.
>>
>> The remaining warnings a variety things like printf format/arg
>> mismatches, failed inlines, signed/unsigned mismatches, and so on.
>>
>> Personally, I'm not comfortable shipping anything that builds with
>> that many warnings. For my code, the requirement is zero warnings.
>> For eCos code, the number of warnings has to be small enough that I
>> can anlyze them once and thereafter tell at a glance whether any new
>> ones have popped up.
>
> Yeah, every new release is trying to be more prudent than previous.
> There are two ways, suppressing warnings and/or fixing code. We need
> to consider it and decide how to approach on case by case basis. Zero
> warnings should be our goal.
I always try to fix the code if at all possible. In the case of the
aliasing violations, I'm happy with -fno-strict-aliasing, since that
isn't really supressing the warning -- it's telling the the compiler
to generate code in a way such that there is no condition about which
to be warned (if that makes sense). IIRC, there is a flag that just
supresses the strict-aliasing warning, but that seems like a bad idea.
There won't be any actual need for me to use a the newer toolchain for
many months, so it'll probably be a while before I start working on
fixing eCos code, but eventually I will start working on that.
[I was hoping the 3.2->4.6 change might produce noticably smaller or
faster code. The size reduction is about 0.8%, and though I haven't
done any extensive benchmarking, I haven't noticed any speed
improvement yet.]
--
Grant Edwards grant.b.edwards Yow! Mr and Mrs PED, can I
at borrow 26.7% of the RAYON
gmail.com TEXTILE production of the
INDONESIAN archipelago?
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
