[ECOS] eCos arm-eabi GNU tools - test release 4.6.2-20120125

[ECOS] eCos arm-eabi GNU tools - test release 4.6.2-20120125

[John Dallaway]

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:

Cygwin-hosted:
gnutools/cygwin/test/ecos-gnutools-arm-eabi-20120125.cygwin.tar.bz2

Linux-hosted:
gnutools/i386linux/test/ecos-gnutools-arm-eabi-20120125.i386linux.tar.bz2

Please use a mirror site in your own geographical region to access these
files. Sites which mirror the eCos ftp area are listed at:

  http://ecos.sourceware.org/mirror.html

The tools may be extracted into the current working directory from the
downloaded archive files by using one of the following commands at a
bash prompt:

  tar jxvf ecos-gnutools-arm-eabi-20120125.cygwin.tar.bz2
  tar jxvf ecos-gnutools-arm-eabi-20120125.i386linux.tar.bz2

The Linux-hosted tools should work on most Linux distributions. The
Cygwin-hosted tools require a recent Cygwin installation including the
"libexpat1" and "libmpc1" packages.

Your feedback is welcome. Please report any issues at:

  http://bugs.ecos.sourceware.org

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Grant Edwards]

On 2012-02-13, John Dallaway <john@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.

Doing the same build with my old 3.2.x toolchain generates 6 warnings
that I've never gotten around to fixing -- but I'm familiar with them
and know they're harmless.

-- 
Grant Edwards               grant.b.edwards        Yow! A can of ASPARAGUS,
                                  at               73 pigeons, some LIVE ammo,
                              gmail.com            and a FROZEN DAQUIRI!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Ilija Kocho]

On 24.02.2012 18:10, Grant Edwards wrote:
> On 2012-02-13, John Dallaway <john@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.

Ilija


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Grant Edwards]

On 2012-02-24, Ilija Kocho <ilijak@siva.com.mk> wrote:
> On 24.02.2012 18:10, Grant Edwards wrote:
>> On 2012-02-13, John Dallaway <john@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

Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Sergei Gavrikov]

On Fri, 24 Feb 2012, Grant Edwards wrote:

> 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.
 
Hm. My score is something 1/4 from yours. For the same eCos template
and *arm-eabi* eCos target (one from officially supported *arm-eabi*
targets from eCos AnonCVS):

  % make 2>&1 | tee log && make IGNORE_LINK_ERRORS=y tests 2>&1 | tee -a log
  % grep warning: log | wc -l
  49
  % grep warning: log | grep -v -- unused-but-set | wc -l
  3

So, the most (46) are:

  warning: variable "foo" set but not used [-Wunused-but-set-variable]

And that is new warning from -Wall set
http://gcc.gnu.org/gcc-4.6/porting_to.html

IMHO, those warnings is not big issue. I hope that we will be able to
rid all of them. Also there were a few *notes* that mangling of va_list
has changed in GCC 4.4.

Grant, did you try *arm-eabi* toolchain for your target before?  Of
course, if this is possible. I mean stable arm-eabi (4.3.2) toolchain
from eCosCentric? May be you missed that CFLAGS clean-up step on 4.3.2
migration?

BTW, I have the very few warnings when I use stable arm-eabi (4.3.2)
toolchain from eCosCentric with CFLAGS updated since eCos 3.0.

> Doing the same build with my old 3.2.x toolchain generates 6 warnings
> that I've never gotten around to fixing -- but I'm familiar with them
> and know they're harmless.
 
Ah! So, you used old 'arm-elf' toolchain before.  As far I remember
CFLAGS for all *arm-eabi* targets in eCos AnonCVS were fixed in those
days (pre eCos 3.0 days). Well, there are a few *arm-elf* targets in
eCos AnonCVS.  As I could see *arm-elf* based are sa11x0, pid, aeb, and
ebsa285.

Well, I believe that we will rid all warnings at the end :-) More
warnings means that the newest compiler is more pedantic and IMHO, that
is good for programmers, but not for their elder code :-)

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

Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Ilija Kocho]

On 24.02.2012 20:37, Grant Edwards wrote:

[snip]

> [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.]

I haven't compared against 3.2.

Regarding speed, for Cortex-M3 target the Coremark test shows 12% speed
up of 4.6.2 against 4.3.2. But Cortex-M runs Thumb2 instruction set, the
picture may be different for ARM code.

Ilija

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Sergei Gavrikov]

On Fri, 24 Feb 2012, Ilija Kocho wrote:

> On 24.02.2012 20:37, Grant Edwards wrote:
> 
> [snip]
> 
> > [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.]
> 
> I haven't compared against 3.2.
> 
> Regarding speed, for Cortex-M3 target the Coremark test shows 12%
> speed up of 4.6.2 against 4.3.2. But Cortex-M runs Thumb2 instruction
> set, the picture may be different for ARM code.

I call that I had got more dry & whet mips on my arm7tdmi target when I
s/3.2.1/4.3.2/

Fortunately, I found my old ask (and results for 3.2.1) on the list :-)
http://sourceware.org/ml/ecos-discuss/2006-12/msg00000.html

Just now I tried 'dhrystone' test for 4.6.2. Well, I know issues with
this test, but ...

I got

  22 VAX MIPS (GCC 4.6.2) vs 13 VAX MIPS (GCC 3.2.1) for RAM startup

and

  34 VAX MIPS (GCC 4.6.2) vs 22 VAX MIPS (GCC 3.2.1) for ROM startup
  (on-chip flash).

IMHO, it is nice delta. Of course, it is true for my arm7tdmi target and
may be you will get more modest results for your one.

Sergei

> 
> Ilija
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Grant Edwards]

On 2012-02-24, Sergei Gavrikov <sg@scanex.ru> wrote:

> Grant, did you try *arm-eabi* toolchain for your target before?  Of
> course, if this is possible. I mean stable arm-eabi (4.3.2) toolchain
> from eCosCentric? May be you missed that CFLAGS clean-up step on 4.3.2
> migration?

No I hadn't tried the older arm-eabi toolchain and wasn't aware of any
manual CFLGAGS changes that needed to be made.  I assumed that the CDL
from CVS HEAD would use the right CFLAGS.

> Ah! So, you used old 'arm-elf' toolchain before.

Yes.

> As far I remember CFLAGS for all *arm-eabi* targets in eCos AnonCVS
> were fixed in those days (pre eCos 3.0 days). Well, there are a few
> *arm-elf* targets in eCos AnonCVS.  As I could see *arm-elf* based
> are sa11x0, pid, aeb, and ebsa285.

I don't understand.  If the FreeBSD code requires
-fno-strict-aliasing, shouldn't the CDL for the FreeBSD package take
care of that?

> Well, I believe that we will rid all warnings at the end :-) More
> warnings means that the newest compiler is more pedantic and IMHO, that
> is good for programmers, but not for their elder code :-)

Indeed.  All of my code, including my HAL, compiles cleanly with
either compiler -- it's the standard code I just grabbed from CVS that
I was talking about.

-- 
Grant Edwards               grant.b.edwards        Yow! I joined scientology
                                  at               at a garage sale!!
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Sergei Gavrikov]

On Fri, 24 Feb 2012, Grant Edwards wrote:

> On 2012-02-24, Sergei Gavrikov wrote:
> 
> > Grant, did you try *arm-eabi* toolchain for your target before?  Of
> > course, if this is possible. I mean stable arm-eabi (4.3.2)
> > toolchain from eCosCentric? May be you missed that CFLAGS clean-up
> > step on 4.3.2 migration?
> 
> No I hadn't tried the older arm-eabi toolchain and wasn't aware of any
> manual CFLGAGS changes that needed to be made.  I assumed that the CDL
> from CVS HEAD would use the right CFLAGS.

Is there CYGBLD_GLOBAL_WARNFLAGS in yours? I mean this commit
http://hg-pub.ecoscentric.com/ecos/rev/00813b25dec2
and the next Bart's commits from 2009/02/03 to 2009/02/03. 

Is there -Wno-write-strings in your CFLAGS? Well, what is your target?

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

[ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Grant Edwards]

On 2012-02-24, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> On Fri, 24 Feb 2012, Grant Edwards wrote:
>
>> On 2012-02-24, Sergei Gavrikov wrote:
>> 
>> > Grant, did you try *arm-eabi* toolchain for your target before?  Of
>> > course, if this is possible. I mean stable arm-eabi (4.3.2)
>> > toolchain from eCosCentric? May be you missed that CFLAGS clean-up
>> > step on 4.3.2 migration?
>> 
>> No I hadn't tried the older arm-eabi toolchain and wasn't aware of any
>> manual CFLGAGS changes that needed to be made.  I assumed that the CDL
>> from CVS HEAD would use the right CFLAGS.
>
> Is there CYGBLD_GLOBAL_WARNFLAGS in yours?

Yes:

  $ grep -A 4 CYGBLD_GLOBAL_WARNFLAGS */ecos.ecc
  ecos-build-eabi/ecos.ecc:cdl_option CYGBLD_GLOBAL_WARNFLAGS {
  ecos-build-eabi/ecos.ecc-    # Calculated value:  "-Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings " 
  ecos-build-eabi/ecos.ecc-    # Flavor: data
  ecos-build-eabi/ecos.ecc-    # Current_value: -Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings 
  ecos-build-eabi/ecos.ecc-};
  --
  ecos-build/ecos.ecc:cdl_option CYGBLD_GLOBAL_WARNFLAGS {
  ecos-build/ecos.ecc-    # Calculated value:  "-Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings " 
  ecos-build/ecos.ecc-    # Flavor: data
  ecos-build/ecos.ecc-    # Current_value: -Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings 
  ecos-build/ecos.ecc-};

The latter of the two is the ecos-ecc when building with 3.2.1 arm-elf
toolchain.

> I mean this commit
> http://hg-pub.ecoscentric.com/ecos/rev/00813b25dec2 and the next
> Bart's commits from 2009/02/03 to 2009/02/03. 

Yes.  I'm using eCos source code I fetched from CVS HEAD a couple
weeks ago.

> Is there -Wno-write-strings in your CFLAGS?

No.

> Well, what is your target?

Various custom boards that have a Sammsung ARM7TDMI.

-- 
Grant Edwards               grant.b.edwards        Yow! I appoint you
                                  at               ambassador to Fantasy
                              gmail.com            Island!!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Sergei Gavrikov]

On Fri, 24 Feb 2012, Grant Edwards wrote:

> On 2012-02-24, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> > On Fri, 24 Feb 2012, Grant Edwards wrote:
> >
> >> On 2012-02-24, Sergei Gavrikov wrote:
> >> 
> >> > Grant, did you try *arm-eabi* toolchain for your target before?
> >> > Of course, if this is possible. I mean stable arm-eabi (4.3.2)
> >> > toolchain from eCosCentric? May be you missed that CFLAGS
> >> > clean-up step on 4.3.2 migration?
> >> 
> >> No I hadn't tried the older arm-eabi toolchain and wasn't aware of
> >> any manual CFLGAGS changes that needed to be made.  I assumed that
> >> the CDL from CVS HEAD would use the right CFLAGS.
> >
> > Is there CYGBLD_GLOBAL_WARNFLAGS in yours?
> 
> Yes:
> 
>   $ grep -A 4 CYGBLD_GLOBAL_WARNFLAGS */ecos.ecc
>   ecos-build-eabi/ecos.ecc:cdl_option CYGBLD_GLOBAL_WARNFLAGS {
>   ecos-build-eabi/ecos.ecc-    # Calculated value:  "-Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings " 
>   ecos-build-eabi/ecos.ecc-    # Flavor: data
>   ecos-build-eabi/ecos.ecc-    # Current_value: -Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings 
>   ecos-build-eabi/ecos.ecc-};
>   --
>   ecos-build/ecos.ecc:cdl_option CYGBLD_GLOBAL_WARNFLAGS {
>   ecos-build/ecos.ecc-    # Calculated value:  "-Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings " 
>   ecos-build/ecos.ecc-    # Flavor: data
>   ecos-build/ecos.ecc-    # Current_value: -Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings 
>   ecos-build/ecos.ecc-};
> 
> The latter of the two is the ecos-ecc when building with 3.2.1 arm-elf
> toolchain.

The output does not mean that eCos global CFLGAGS for your *arm-elf*
target contain CYGBLD_GLOBAL_WARNFLAGS as a part of CFLAGS, mine

  cdl_option CYGBLD_GLOBAL_CFLAGS {
      ...
      # Default value:  CYGBLD_GLOBAL_WARNFLAGS . CYGBLD_ARCH_CFLAGS .
                                        ...
 
the output does mean that CYGBLD_GLOBAL_WARNFLAGS option in your CDL
(and I know there is it in ecos.ecc :-) I think your CFLAGS has not such
a concatenation.

> > I mean this commit
> > http://hg-pub.ecoscentric.com/ecos/rev/00813b25dec2 and the next
> > Bart's commits from 2009/02/03 to 2009/02/03. 
> 
> Yes.  I'm using eCos source code I fetched from CVS HEAD a couple
> weeks ago.
> 
> > Is there -Wno-write-strings in your CFLAGS?
> 
> No.

Bad news for old sources are processed by newest compilers. Could you
please show your ecos.mak?  To comparison mine (NXP ARM7TDMI)

  % grep CFLAGS /tmp/t/install/include/pkgconf/ecos.mak
  ECOS_GLOBAL_CFLAGS = -Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings -mno-thumb-interwork -mcpu=arm7tdmi -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions

I think that -Wno-write-strings from CYGBLD_GLOBAL_WARNFLAGS (it is a
really part of CYGBLD_GLOBAL_CFLAGS for *arm-eabi* targets in eCos CVS)
does fulfill  main "clean-up" job for any old sources and for BSD
sources as well.

> > Well, what is your target?
> 
> Various custom boards that have a Sammsung ARM7TDMI.

I will look on the same targets.

Sergei

> -- 
> Grant Edwards               grant.b.edwards        Yow! I appoint you
>                                   at               ambassador to Fantasy
>                               gmail.com            Island!!!
> 
> 
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Grant Edwards]

On 2012-02-24, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> [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.]

I've since run a benchmark that involves loopback throughput on 4
simultaneous TCP/SSL connections and saw throughput increase 65%
compared to the same code built with 3.2.1.  

Wow.

-- 
Grant Edwards               grant.b.edwards        Yow! Youth of today!
                                  at               Join me in a mass rally
                              gmail.com            for traditional mental
                                                   attitudes!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Grant Edwards]

On 2012-02-25, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:

> The output does not mean that eCos global CFLGAGS for your *arm-elf*
> target contain CYGBLD_GLOBAL_WARNFLAGS as a part of CFLAGS, mine
>
>   cdl_option CYGBLD_GLOBAL_CFLAGS {
>       ...
>       # Default value:  CYGBLD_GLOBAL_WARNFLAGS . CYGBLD_ARCH_CFLAGS .
>                                         ...
>  
> the output does mean that CYGBLD_GLOBAL_WARNFLAGS option in your CDL
> (and I know there is it in ecos.ecc :-) I think your CFLAGS has not such
> a concatenation.

You're right.  I've changed my default value to look like this:

default_value { CYGBLD_GLOBAL_WARNFLAGS . CYGBLD_ARCH_CFLAGS . 
 "-mcpu=arm7tdmi -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions " }

[...]
>> > Is there -Wno-write-strings in your CFLAGS?
>> 
>> No.
>
> Bad news for old sources are processed by newest compilers. Could you
> please show your ecos.mak?  To comparison mine (NXP ARM7TDMI)
>
>   % grep CFLAGS /tmp/t/install/include/pkgconf/ecos.mak
>   ECOS_GLOBAL_CFLAGS = -Wall -Wpointer-arith -Wstrict-prototypes -Wundef -Woverloaded-virtual -Wno-write-strings -mno-thumb-interwork -mcpu=arm7tdmi -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions

ECOS_GLOBAL_CFLAGS = -Wall -Wpointer-arith -Wstrict-prototypes -Wundef
-Woverloaded-virtual -Wno-write-strings -mno-thumb-interwork
-mcpu=arm7tdmi -mbig-endian -g -O2 -ffunction-sections
-fdata-sections -fno-rtti -fno-exception

> I think that -Wno-write-strings from CYGBLD_GLOBAL_WARNFLAGS (it is a
> really part of CYGBLD_GLOBAL_CFLAGS for *arm-eabi* targets in eCos CVS)
> does fulfill  main "clean-up" job for any old sources and for BSD
> sources as well.

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 Edwards               grant.b.edwards        Yow! I'm imagining a surfer
                                  at               van filled with soy sauce!
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Sergei Gavrikov]

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

[ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Grant Edwards]

On 2012-03-01, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> 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.

Ah!  That's good to know.  I was starting to wonder what I was doing
wrong. :)

For now, I've added -fno-strict-aliasing to CFLAGS for the bsd_tcpip
package.  That fixes the "type-punned pointer" warnings (which _might_
indicate real problems).  The rest of warnings look pretty harmless,
but I'm working on fixing them.   I've fixed a few "variable set-but-not
used" warnings, but there are a lot more to go.  Once I have things
cleaned up a bit, I'll work on submitting patches.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having a
                                  at               quadrophonic sensation
                              gmail.com            of two winos alone in a
                                                   steel mill!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

[Grant Edwards]

On 2012-02-24, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> 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.

The schedule has changed, and I'm going to be needing to use a newer
toolchain sooner than later, so I'm starting to submit patches to fix
compiler warnings when using 4.6.

-- 
Grant Edwards               grant.b.edwards        Yow! Do you think the
                                  at               "Monkees" should get gas on
                              gmail.com            odd or even days?


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss