This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125
- From: Sergei Gavrikov <sergei dot gavrikov at gmail dot com>
- To: Grant Edwards <grant dot b dot edwards at gmail dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 1 Mar 2012 10:25:27 +0300 (FET)
- Subject: Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125
- Authentication-results: mr.google.com; spf=pass (google.com: domain of sergei.gavrikov@gmail.com designates 10.213.9.73 as permitted sender) smtp.mail=sergei.gavrikov@gmail.com; dkim=pass header.i=sergei.gavrikov@gmail.com
- References: <4F39875A.6080105@dallaway.org.uk> <ji8gae$63g$1@dough.gmane.org> <alpine.DEB.2.00.1202242206030.2294@vostro> <ji8ub4$d6o$1@dough.gmane.org> <alpine.DEB.2.00.1202250019030.19838@vostro> <ji91im$953$1@dough.gmane.org> <alpine.DEB.2.00.1202251116550.1875@vostro> <jim2p6$t1o$1@dough.gmane.org>
On Wed, 29 Feb 2012, Grant Edwards wrote:
> Now I've got -Wno-write-strings (as seen above), but I still get 139
> warnings, and 88 of them are because of dereferencing type-punned
> pointers by bsd_tcpip files.
>
> It still looks to me like the bsd_tcpip cdl needs to add
> -fno-strict-aliasing to CFLAGS.
>
> After doing that, I'm down to 51 warnings.
>
> 39 are variables that are set but not used -- almost all in bsd_tcpip
> files.
>
> Most of the rest are signed/unsigned mismatches for pointer arguments.
> Again, almost all are in bsd_tcpip code.
Grant, I found what opens Pandora's box thanking your questions on ipv6
stack :-) That is ipv6 code! As I could understand you include it and I
used only ipv4 stack when I tested new toolchain. With the option
cdl_option CYGPKG_NET_INET6 {
user_value 1
};
I got the same results on warnings as you have.
BTW, current and stable GCC-4.3.2 does produce something about 10
warnings for the same build.
Thanks for your reports and testing. It seems to me we have to check all
changes on warnings policy since GCC-4.3. I mean
http://gcc.gnu.org/gcc-4.4/changes.html
http://gcc.gnu.org/gcc-4.5/changes.html
http://gcc.gnu.org/gcc-4.6/changes.html
At the least for 4.5 I saw
* The infrastructure for optimizing based on restrict qualified
pointers has been rewritten and should result in code generation
improvements. Optimizations based on restrict qualified pointers
are now also available when using -fno-strict-aliasing.
As I could see we forced using '-fno-strict-aliasing' option only for
libm eCos package for some toolchains.
Sergei
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss