GCC 3.4.x + RTEMS 4.6.2 release.

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Thu, 2005-01-13 at 11:56 +0100, Karel Gardas wrote:
> 

>>Thanks for this note. I would also like to ask you in which state is RTEMS
>>trunk. 
> 
> IMO (but of cause I am biased), current RTEMS-CVS is pretty stable in
> general, but there exist several target-specific toolchain issues and
> issues with some BSPs.

I also agree that RTEMS CVS is in pretty good shape.

> ATM, the main issue is GCC and newlib. AFAICT,
> 
> - The RTEMS-4.2.x gcc-3.2.x-toolchains should be applicable to with
> rtems-CVS "out of the box"

gcc 3.2.x was the last version we managed to get cross-Ada for
RTEMS out of.

> - GCC-3.3.x and GCC-3.4.x should be sufficently usable for most targets,
> however RTEMS is known to trigger bugs in GCC for some targets,
> comprising some major targets (eg. arm, m68k; Check GCC's bugzilla for
> target "rtems" for details). 

Agreed ...gcc 3.3.x seems pretty OK.  All gcc versions have bugs, it
is just a matter of if it one you care about. :)

RTEMS exposes bugs in GCC 3.4.x.  I think we have reported the
ones we trigger building the toolset and RTEMS.  However, it is
late in the gcc 3.4 lifecycle and effort expended pushing on it
gets better results pushing at 4.0.  Often the fix gets backported
anyway.

Also gcc 3.4.x is no better for cross-Ada so our effort won't
get that resolved.

> - GCC-4.0 is slowly reaching a usable stage. IMO, gcc-4.0 (C-only)
> already is superior to gcc-3.x for many targets. At least several of the
> bugs RTEMS had exposed in gcc-3.3.x/gcc-3.4.x don't seem to be present
> in gcc-4.0, anymore. However, until yesterday, g++-4.0 did not even
> build at all for any rtems target. Joel and I are just about to fix
> these roadblocks.

Right.  GCC added a need for "recursive mutexes".  One of us should
be able to commit that code today or tomorrow.  THen you are at
target specific issues.

   + i386-rtems has a soft-float compiler error.  We have a
     PR and the information for a solution.  Richard Henderson
     made a suggestion yesterday on a better fix, we need to
     decipher and implement.
   + sparc-rtems did not build.  I think I have this fixed but
     suspect the sparc reorg in gcc and my update changed the
     C++ ctor method for RTEMS.
   + Ralf reported a m68k-rtems compiler error with paranoia.

   + No work on cross Ada yet but I remain hopeful.

The idea is that gcc developers pay more attention to the
development head -- which right now is close to becoming gcc
4.0.  Let's work on making it right for RTEMS.

>> i.e. it don't need to be rock-solid for my experiments, I just
>>need pc386 BSP and tool-chain with the latest/greatest C++ support which
>>is possible to get for it.
>>
>>As I'm looking into ftp now, there are several versions of binutils,
>>newlib, gdb and their patches available. Could you be so kind and
>>recommend me some combination which you would consider the most stable for
>>pc386 BSP (stable in a means of C++/libstdc++ development)?
> 
> For development, I am currently using 
> * binutils-2.15 w/o any patches.
> * GCC-3.4-branch and GCC-HEAD (aka. GCC-4.0) without any patches rsp.
> with local patches I am planning to commit to GCC in near future
> applied.
> * newlib-CVS + the newlib-patch I sent to this list a couple of days ago
> applied.
> 
> Ralf
> 
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985