Gnutools: consideration for upgrade to GCC 4.6

classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Gnutools: consideration for upgrade to GCC 4.6

Ilija Kocho [Илија Кочо]
Hi colleagues

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.

Looking forward for your comments.
Ilija
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Bernard Fouché

Le 13/01/2012 18:00, Ilija Kocho a écrit :

>
> 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.
>
That sounds good! Did you try link time optimization ? I'm curious what
kind of gain it could bring with a real world app. eCos seems to fit
perfectly for such an optimization, there is no shared lib and at link
time everythink is visible to the linker.
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Frank Pagliughi
In reply to this post by Ilija Kocho [Илија Кочо]
On 01/13/2012 12:00 PM, Ilija Kocho wrote:

> Hi colleagues
>
> 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.
>
> Looking forward for your comments.
> Ilija
>
I'm all for it. I've been using 4.6.2 for the last few months for ARM
(EABI, of course) and i386. The 4.3 compilers wouldn't compile some of
the libraries that I use and I didn't want to back port them to an old
compiler. I used binutils 2.21.1.

So far I've been very happy, but I was mostly concerned with language
features. The additional Cortex support sells it, though. I'm just
starting to start shopping around for a Cortex-M3 for my next project.

Frank
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Ilija Kocho [Илија Кочо]
In reply to this post by Bernard Fouché
On 13.01.2012 19:54, Bernard Fouché wrote:

>
> Le 13/01/2012 18:00, Ilija Kocho a écrit :
>>
>> 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.
>>
> That sounds good! Did you try link time optimization ?

I haven't changed any option except -mcpu=cortex-m4. My objective were
SIMD instructions (now with K70 FPU).

> I'm curious what kind of gain it could bring with a real world app.
> eCos seems to fit perfectly for such an optimization, there is no
> shared lib and at link time everythink is visible to the linker.

Worth to try.

Ilija
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Ilija Kocho [Илија Кочо]
In reply to this post by Frank Pagliughi
On 13.01.2012 20:09, Frank Pagliughi wrote:

> On 01/13/2012 12:00 PM, Ilija Kocho wrote:
>> Hi colleagues
>>
>> 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.
>>
>> Looking forward for your comments.
>> Ilija
>>
> I'm all for it. I've been using 4.6.2 for the last few months for ARM
> (EABI, of course) and i386. The 4.3 compilers wouldn't compile some of
> the libraries that I use and I didn't want to back port them to an old
> compiler. I used binutils 2.21.1.

I was using 2.21.1, but toady I tried 2.22. It works out of box, no
patching.

>
> So far I've been very happy, but I was mostly concerned with language
> features. The additional Cortex support sells it, though. I'm just
> starting to start shopping around for a Cortex-M3 for my next project.

If you are happy with ARM7TDMI you'll be happier with Cortex-M

Ilija
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

John Dallaway-2
In reply to this post by Ilija Kocho [Илија Кочо]
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.

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?

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
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Sergei Gavrikov-4
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<major>.<year>, 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Ilija Kocho [Илија Кочо]
In reply to this post by John Dallaway-2
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 ‘<varname>’ 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

Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Grant Edwards-6
In reply to this post by Sergei Gavrikov-4
On 2012-01-14, Sergei Gavrikov <[hidden email]> wrote:

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

Why?

Are the eCos sources going to start requiring use of specific
toolchain binaries?

I've been using eCos for a long time, and have always used my own
toolchains.  I'd be pretty unhappy if that was no longer possible.

--
Grant




Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Sergei Gavrikov-4
On Sun, 15 Jan 2012, Grant Edwards wrote:

> On 2012-01-14, Sergei Gavrikov <[hidden email]> wrote:
>
> > 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.
>
> Why?

Simply to distinguish the official releases of toolchains (I hope well
tested) and any home-cooked toolchains. I meant such predefined things
for GCC (CPP)

  % i386-rtems4.11-gcc -dM -E - </dev/null | grep __rtems__
  #define __rtems__ 1

and the same we could have for officially supported releases for ecos,
e.g.

  % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
  #define __ecos__ 1

Secondly, it lets anyone to use such checks in sources, e.g.

  #if __linux__
  # include <endian.h>
  #elif __ecos__
  # include <machine/endian.h>
  #else
  ...
  #endif

For now we usually add '-D__ECOS__' to CFLAGS for some packages.

The third, Why we should avoid to say that eCos is also well known,
widely used OS?

> Are the eCos sources going to start requiring use of specific
> toolchain binaries?

Nope. Anyone can use own binaries if he/she wants.
 
> I've been using eCos for a long time, and have always used my own
> toolchains.  I'd be pretty unhappy if that was no longer possible.

Why it will be not possible? I did not understand. You can use own, but,
a bug reporter should/may use officially supported "labeled" toolchain
to check the roots of some issue on crashes. But, naturally, I do not
resists on built-in label __ecos__. Look on that as a promotion eCos OS.
If you think that my points are wrong, please, forget it.

Thanks for your comments.

Sergei

> Grant
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Stanislav Meduna
On 15.01.2012 19:42, Sergei Gavrikov wrote:

> Secondly, it lets anyone to use such checks in sources, e.g.
>
>   #if __linux__
>   # include <endian.h>
>   #elif __ecos__
>   # include <machine/endian.h>
>   #else
>   ...
>   #endif

Doing this would break compatibility with older toolchain -
easily fixable (just add another -D... to global CFLAGS),
but nevertheless something every user has to explicitely
address. I don't know what the eCos policy for this kind
of changes is.

I am not strictly against this move (although I am also using
self-compiled toolchains); the question is what does it bring
to the user.

> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?
> ...
> Look on that as a promotion eCos OS.

Does the specification of a target OS belong to a compiler at all?
Is there anything the compiler itself does differently for eCos
than for Linux or RTEMS (that is not covered by other flags)?
If yes, go ahead. If not, frankly, I think that 'promotion' or
'others do it' is a bogus reason for hardcoding something into
a compiler binary, so I'd only do this if there is a technical
reason for it (IMHO of course).

Regards
--
                                          Stano
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Ilija Kocho [Илија Кочо]
In reply to this post by Sergei Gavrikov-4
On 15.01.2012 19:42, Sergei Gavrikov wrote:

> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov<[hidden email]>  wrote:
>>
>>> 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.
>> Why?
> Simply to distinguish the official releases of toolchains (I hope well
> tested) and any home-cooked toolchains. I meant such predefined things
> for GCC (CPP)
>
>    % i386-rtems4.11-gcc -dM -E -</dev/null | grep __rtems__
>    #define __rtems__ 1
>
> and the same we could have for officially supported releases for ecos,
> e.g.
>
>    % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
>    #define __ecos__ 1
>
> Secondly, it lets anyone to use such checks in sources, e.g.
>
>    #if __linux__
>    # include<endian.h>
>    #elif __ecos__
>    # include<machine/endian.h>
>    #else
>    ...
>    #endif
>
> For now we usually add '-D__ECOS__' to CFLAGS for some packages.
>
> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?

It seems there have been some attempts before as there are some traces
left in gcc tree:
gcc/config/arm/ecos-elf.h

I'm not sure about former addition, But IMO that it would be good to add
t-ecos target description(s). The material is present in eCos patches
ftp://ecos.sourceware.org/pub/ecos/gnutools/src/ .

Speaking of branding, we shouldn't omit --version banner
(|--with-pkgversion|), let's say "eCos community edition [<ver>]"

>> Are the eCos sources going to start requiring use of specific
>> toolchain binaries?
> Nope. Anyone can use own binaries if he/she wants.

We must be sure of this. People will need, from various reasons, to use
different toolchains (commercial or self built).

Ilija

Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Ilija Kocho [Илија Кочо]
In reply to this post by Sergei Gavrikov-4
On 15.01.2012 19:42, Sergei Gavrikov wrote:

> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov<[hidden email]>  wrote:
>>
>>> 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.
>> Why?
> Simply to distinguish the official releases of toolchains (I hope well
> tested) and any home-cooked toolchains. I meant such predefined things
> for GCC (CPP)
>
>    % i386-rtems4.11-gcc -dM -E -</dev/null | grep __rtems__
>    #define __rtems__ 1
>
> and the same we could have for officially supported releases for ecos,
> e.g.
>
>    % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
>    #define __ecos__ 1
>
> Secondly, it lets anyone to use such checks in sources, e.g.
>
>    #if __linux__
>    # include<endian.h>
>    #elif __ecos__
>    # include<machine/endian.h>
>    #else
>    ...
>    #endif
>
> For now we usually add '-D__ECOS__' to CFLAGS for some packages.
>
> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?

It seems there have been some attempts before as there are some traces
left in gcc tree:
gcc/config/arm/ecos-elf.h

I'm not sure about former addition, But IMO that it would be good to add
t-ecos target description(s). The material is present in eCos patches
ftp://ecos.sourceware.org/pub/ecos/gnutools/src/ .

Speaking of branding, we shouldn't omit --version banner
(|--with-pkgversion|), let's say "eCos community edition [<ver>]"

>> Are the eCos sources going to start requiring use of specific
>> toolchain binaries?
> Nope. Anyone can use own binaries if he/she wants.

We must be sure of this. People will need, from various reasons, to use
different toolchains (commercial or self built).

Ilija

Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Grant Edwards-6
In reply to this post by Sergei Gavrikov-4
On 2012-01-15, Sergei Gavrikov <[hidden email]> wrote:

> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov <[hidden email]> wrote:
>>
>> > 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.
>>
>> Why?
>
> Simply to distinguish the official releases of toolchains (I hope well
> tested) and any home-cooked toolchains. I meant such predefined things
> for GCC (CPP)

I realize it would distinguish official toolchains from others.  What
I want to know is why that's useful.

>   % i386-rtems4.11-gcc -dM -E - </dev/null | grep __rtems__
>   #define __rtems__ 1
>
> and the same we could have for officially supported releases for ecos,
> e.g.
>
>   % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
>   #define __ecos__ 1
>
> Secondly, it lets anyone to use such checks in sources, e.g.
>
>   #if __linux__
>   # include <endian.h>
>   #elif __ecos__
>   # include <machine/endian.h>
>   #else
>   ...
>   #endif

That doesn't seem to be appropriate to me.  In eCos builds, the
include files are not part of the toolchain and their locations
shouldn't be determined based on the toolchain.  The eCos include
files are part of the eCos source tree and build system (which
provides __ECOS__).

> For now we usually add '-D__ECOS__' to CFLAGS for some packages.
>
> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?

For one thing, I use the same toolchain to build eCos stuff and
non-eCos stuff.  The __ECOS__ macro can be used to tell the
difference.

>> Are the eCos sources going to start requiring use of specific
>> toolchain binaries?
>
> Nope. Anyone can use own binaries if he/she wants.

Not if eCos code is going to contain checks for __ecos__ that cause a
build to fail without __ecos__.

>> I've been using eCos for a long time, and have always used my own
>> toolchains.  I'd be pretty unhappy if that was no longer possible.
>
> Why it will be not possible? I did not understand.

If the eCos code is going to be checking for __ecos__ then that code
won't build with my toolchains.

> You can use own, but, a bug reporter should/may use officially
> supported "labeled" toolchain to check the roots of some issue on
> crashes. But, naturally, I do not resists on built-in label __ecos__.
> Look on that as a promotion eCos OS. If you think that my points are
> wrong, please, forget it.

As long as nothing in the build process checks for or requires
__ecos__, then that's fine.

--
Grant Edwards               grant.b.edwards        Yow! Hey, wait
                                  at               a minute!!  I want a
                              gmail.com            divorce!! ... you're not
                                                   Clint Eastwood!!

Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Sergei Gavrikov-4
On Mon, 16 Jan 2012, Grant Edwards wrote:

> On 2012-01-15, Sergei Gavrikov <[hidden email]> wrote:
> > On Sun, 15 Jan 2012, Grant Edwards wrote:
> >
> >> On 2012-01-14, Sergei Gavrikov <[hidden email]> wrote:
> >>
> >> > 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.
> >>
> >> Why?
> >
> > Simply to distinguish the official releases of toolchains (I hope
> > well tested) and any home-cooked toolchains. I meant such predefined
> > things for GCC (CPP)
>
> I realize it would distinguish official toolchains from others.  What
> I want to know is why that's useful.
>
> >   % i386-rtems4.11-gcc -dM -E - </dev/null | grep __rtems__
> >   #define __rtems__ 1
> >
> > and the same we could have for officially supported releases for
> > ecos, e.g.
> >
> >   % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
> >   #define __ecos__ 1
> >
> > Secondly, it lets anyone to use such checks in sources, e.g.
> >
> >   #if __linux__
> >   # include <endian.h>
> >   #elif __ecos__
> >   # include <machine/endian.h>
> >   #else
> >   ...
> >   #endif
>
> That doesn't seem to be appropriate to me.  In eCos builds, the
> include files are not part of the toolchain and their locations
> shouldn't be determined based on the toolchain.  The eCos include
> files are part of the eCos source tree and build system (which
> provides __ECOS__).

I agree, snippet above does confuse most of you. I would defend it, but,
I do not want to do so as I do not desire to change the *Subject* of
this thread.  (I'm sorry Ilija)

> > For now we usually add '-D__ECOS__' to CFLAGS for some packages.

To be clear, I did not offer neither to remove nor replace -D__ECOS__
from CFLAGS in eCos config files. I'm sorry if you've seen this.

> > The third, Why we should avoid to say that eCos is also well known,
> > widely used OS?
>
> For one thing, I use the same toolchain to build eCos stuff and
> non-eCos stuff.  The __ECOS__ macro can be used to tell the
> difference.
>
> >> Are the eCos sources going to start requiring use of specific
> >> toolchain binaries?
> >
> > Nope. Anyone can use own binaries if he/she wants.
>
> Not if eCos code is going to contain checks for __ecos__ that cause a
> build to fail without __ecos__.

I ever did not think about. I did not plan to implant such checks in
*eCos sources*.  I did not say, we should  s/__ECOS__/__ecos__/g.  I
wrote:

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

> >> I've been using eCos for a long time, and have always used my own
> >> toolchains.  I'd be pretty unhappy if that was no longer possible.
> >
> > Why it will be not possible? I did not understand.
>
> If the eCos code is going to be checking for __ecos__ then that code
> won't build with my toolchains.

Once again that was not attempt of any revisionism for eCos sources.
IMHO, built-in CPP definition (__ecos__) can be useful a) for portable
userland applications (not eCos sources); b) for shell scripts which
would detect toolchain easier; c) to distinguish home cooked or third
party toolchains from eCos stable ones (that was my main idea). I risk
to paste yet another check

    /*
     * NOTE: I do not offer such a check for eCos sources itself.
     */
  #ifdef __ECOS__
  # if !defined(__ecos__)
  #  warn Used wrong toolchain for mission critical application.
  #  BUG()
  # endif
  #endif

But. Can such check exist in userland application? [Not need to answer]

> > You can use own, but, a bug reporter should/may use officially
> > supported "labeled" toolchain to check the roots of some issue on
> > crashes. But, naturally, I do not resists on built-in label
> > __ecos__.  Look on that as a promotion eCos OS. If you think that my
> > points are wrong, please, forget it.
>
> As long as nothing in the build process checks for or requires
> __ecos__, then that's fine.

I hope I have convinced you and Stano that I did not suggest to "close"
eCos sources by __ecos__ checks. More that to propagate that built-in
definition is only a few lines for GCC patch and if that is issue I am
ready to withdraw my "I like their built-in" :-)

Let's move on to the subject of the thread. It seemed for me that all of
us are interested in new toolchain(s) and if you are the experts here,
let's open Bugzilla entry for this, there we would accumulate a set of
patches for new toolchain base.

Sergei

> --
> Grant Edwards               grant.b.edwards        Yow! Hey, wait
>                                   at               a minute!!  I want a
>                               gmail.com            divorce!! ... you're not
>                                                    Clint Eastwood!!
>
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Sergei Gavrikov-4
On Mon, 16 Jan 2012, Sergei Gavrikov wrote:

> I hope I have convinced you and Stano that I did not suggest to "close"
> eCos sources by __ecos__ checks. More that to propagate that built-in
> definition is only a few lines for GCC patch and if that is issue I am
> ready to withdraw my "I like their built-in" :-)

Nobody (me too) said (thought) about:

  http://www.ecoscentric.com/trademark_usage.shtml

AIANL. So, I actually withdraw my "wish" as [eCos] is registered
trademark and anyone would use our patches and abuse the word.

Sergei
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Tomas Frydrych-6
In reply to this post by Ilija Kocho [Илија Кочо]
Hi Ilija,

On 13/01/12 17:00, Ilija Kocho wrote:
> 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.

Some of the more recent gccs were not producing usable binaries on some
platforms (including arm) with the -Os option. I do not know if this is
the case with 4.6.2, and I don't think ecos uses -Os by default, but it
is probably worth checking whether this works (and at least documenting
somewhere if it does not).

Tomas
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Bernard Fouché
In reply to this post by Sergei Gavrikov-4

Le 16/01/2012 22:11, Sergei Gavrikov a écrit :

> On Mon, 16 Jan 2012, Sergei Gavrikov wrote:
>
>> I hope I have convinced you and Stano that I did not suggest to "close"
>> eCos sources by __ecos__ checks. More that to propagate that built-in
>> definition is only a few lines for GCC patch and if that is issue I am
>> ready to withdraw my "I like their built-in" :-)
> Nobody (me too) said (thought) about:
>
>    http://www.ecoscentric.com/trademark_usage.shtml
>
> AIANL. So, I actually withdraw my "wish" as [eCos] is registered
> trademark and anyone would use our patches and abuse the word.
>
> Sergei

Being able to identify/check the toolchain used seems a very good idea.
Why not ask eCosCentric about the legal issue? They already make a
toolchain available for public eCos, that can be installed with the
installation tool (see http://ecos.sourceware.org/getstart.html) . IMHO
it is in the interest of eCos to avoid having its public image altered
because of bugs that are related to the toolchain and not eCos itself.

The message from Tomas is a perfect example of such a need:

Le 17/01/2012 10:36, Tomas Frydrych a écrit :
> Some of the more recent gccs were not producing usable binaries on some
> platforms (including arm) with the -Os option. I do not know if this is
> the case with 4.6.2, and I don't think ecos uses -Os by default, but it
> is probably worth checking whether this works (and at least documenting
> somewhere if it does not).
>
> Tomas

     Bernard
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Paul Beskeen
On 17/01/2012 09:57, Bernard Fouché wrote:

> Le 16/01/2012 22:11, Sergei Gavrikov a écrit :
>> On Mon, 16 Jan 2012, Sergei Gavrikov wrote:
>>
>>> I hope I have convinced you and Stano that I did not suggest to "close"
>>> eCos sources by __ecos__ checks. More that to propagate that built-in
>>> definition is only a few lines for GCC patch and if that is issue I am
>>> ready to withdraw my "I like their built-in" :-)
>> Nobody (me too) said (thought) about:
>>
>>    http://www.ecoscentric.com/trademark_usage.shtml
>>
>> AIANL. So, I actually withdraw my "wish" as [eCos] is registered
>> trademark and anyone would use our patches and abuse the word.
>>
>> Sergei
>
> Being able to identify/check the toolchain used seems a very good idea.
> Why not ask eCosCentric about the legal issue? They already make a
> toolchain available for public eCos, that can be installed with the
> installation tool (see http://ecos.sourceware.org/getstart.html) . IMHO
> it is in the interest of eCos to avoid having its public image altered
> because of bugs that are related to the toolchain and not eCos itself.

On the trademark front there is no issue with the public eCos release
using this as required (see 1.1.1/4 section in the above referenced URL).

On a personal note, I would however avoid the use of __ecos__ in the
toolchain for all the reasons that Grant has already pointed out.
Critically, you don't want to limit users to a specific set of toolchains.

Regards, Paul.
--
Paul Beskeen, Chairman & Director of Engineering
http://www.ecoscentric.com/
Reply | Threaded
Open this post in threaded view
|

Re: Gnutools: consideration for upgrade to GCC 4.6

Sergei Gavrikov-4
All

I changed my mind. I withdraw my request. All should know what (which
toolchain) they use. If I do not trust myself, no one denies to patch
GCC to get own built-in define, e.g. __home_cooked__ as a memory stick
to distinguish toolchains :-)

Thanks for your points and time!

Sergei

On Tue, 17 Jan 2012, Paul Beskeen wrote:

> On 17/01/2012 09:57, Bernard Fouché wrote:
> > Le 16/01/2012 22:11, Sergei Gavrikov a écrit :
> >> On Mon, 16 Jan 2012, Sergei Gavrikov wrote:
> >>
> >>> I hope I have convinced you and Stano that I did not suggest to
> >>> "close" eCos sources by __ecos__ checks. More that to propagate
> >>> that built-in definition is only a few lines for GCC patch and if
> >>> that is issue I am ready to withdraw my "I like their built-in"
> >>> :-)
> >> Nobody (me too) said (thought) about:
> >>
> >>    http://www.ecoscentric.com/trademark_usage.shtml
> >>
> >> AIANL. So, I actually withdraw my "wish" as [eCos] is registered
> >> trademark and anyone would use our patches and abuse the word.
> >>
> >> Sergei
> >
> > Being able to identify/check the toolchain used seems a very good
> > idea.  Why not ask eCosCentric about the legal issue? They already
> > make a toolchain available for public eCos, that can be installed
> > with the installation tool (see
> > http://ecos.sourceware.org/getstart.html) . IMHO it is in the
> > interest of eCos to avoid having its public image altered because of
> > bugs that are related to the toolchain and not eCos itself.
>
> On the trademark front there is no issue with the public eCos release
> using this as required (see 1.1.1/4 section in the above referenced
> URL).
>
> On a personal note, I would however avoid the use of __ecos__ in the
> toolchain for all the reasons that Grant has already pointed out.
> Critically, you don't want to limit users to a specific set of
> toolchains.
>
> Regards, Paul.
> --
> Paul Beskeen, Chairman & Director of Engineering
> http://www.ecoscentric.com/
>
1234