Re: GCC 3.3, GCC 3.4

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Devang Patel wrote:
> 
> On Friday, January 31, 2003, at 12:59 PM, Joel Sherrill wrote:
> 
> > The large number of host and target combinations means that it is
> > probably just a fact of life that what is an improvement to one
> > target has a probability to break something else.
> 
> Exactly. That's the point.
> Can we change this fact of life? Is it possible to test improvements
> before they go into cvs ? Is it possible to change current situation?
> (I do not have answer for all these questions).

It would take quite a compile farm to begin to do this perfectly.
For example, I build cross compilers and do about 38 targets
that are PURELY embedded systems on a Linux host.  I try to
provide binaries for Linux, Cygwin, and Solaris.  That's 3 x 38
or 114 combinations.  And I would be willing to bet that I don't
include a single target you care about. :)

Throw in all the normal hosts (UNICes, *BSD, *Linux, Windows, 
MacOS X, etc) that those 38 cross targets can be built from and it 
explodes.  This isn't even throwing in cross targets like VxWorks,
LynxOS, QNX, or a variety of others.

That ignores that many of the embedded targets are hard to test.
If they don't have simulators, you have to download, boot, 
reset, rinse, repeat to real hardware.

The best we can really have is automated testing on popular host
platforms and cross targets on simulators.  That can cover a 
lot of the cases.   It will never be perfect.  For example, the
m68k/coldfire still has a lot of embedded users but there are
few test reports on it any more.  A regression can stay in there
for a while before it gets tripped across.

> -Devang

--joel