crosstool-0.40 released: gcc-4.1 rc1 support

Marius Groeger mgroeger@sysgo.com
Wed Feb 22 14:15:00 GMT 2006


On Tue, 21 Feb 2006, Robert Schwebel wrote:

> It's all a question of having control over the processes. We are being
> able to do regression tests for all releases, so new constellations can
> be qualified quickly. And for projects which are frozen to old versions
> there is no reason _not_ to stay with the crosstool which successfully
> built it. You changed anything, new patches, new host system? Well, then
> you'll have to re-qualify anyway, so there is no difference to using
> current versions.

Sorry to prolong this thread, but I'm not so sure about that.

Your regressions might not catch a new type (class?) of bug which is
introduced by using newer tools. Any new gcc version scares the hell out of
me -- I just have no control over what kind of nifty optimization it brings,
that just breaks my embedded device. Want an example? Take an application's
stack usage: on Unices, stack memory is infinite by definitionem: go buy
some more RAM, and let the page do its bit. On my emedded device, perhaps in
the boot loader, the stack is not at all infinite and violations sometimes
even go unnoticed for quite some time. If I have a working configuration to
compile boot loader code, I'll be damned to throw in a new gcc just because
it's there.

There is no inherently bad thing with using old software unless you are in
need for newer features or just the fun playing with new software.

Regards,
Marius

-- 
Marius Groeger <mgroeger@sysgo.com>
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.org



More information about the crossgcc mailing list