gcc 4.x status for RTEMS

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Thu, 2005-01-27 at 09:59 -0600, Joel Sherrill  wrote:
> 
>>Hi,
>>
>>I woudl like to get everyone to review the gcc 4.x tool status
>>notes on the Wiki and make sure their favorite GCC PR is covered.
>>
>>http://www.rtems.com/phpwiki/index.php/ToolStatus#x34.x2e.0_Per_Target_Status_Notes
>>
>>I have been trying to track the issues but have a feeling I am
>>missing something.
>>
>>AFAIK The worst problems left are:
>>
>>+ various m68k internal compiler errors building RTEMS.  I am unsure
>>   if all of these are listed on the Wiki.

These are the ones I want to get identified ASAP and work with
Peter Barada on.  The m68k and Coldfire are important RTEMS platforms.

> + ditto for the avr.

Unfortunately, I don't see this port getting much better before 4.0.

>>+ Cross gnat tools do not build.  There is a Makefile issue.
> 
> 
> Even if you should manage to solve this issue, then there remains the
> GNAT not supporting multilibs. IMO, this basically leaves GNAT the same
> shape as it has been with gcc-3.x: pretty much useless.

Yes in the general sense but the default multilib build addressed
the bulk of RTEMS users.  PPC603e and SPARC V7 with FPU.

If it isn't right, the application can always force it to be recompiled.

Wrong long term but at least it puts us on equal footing with
gcc 3.2.x and better than gnat 3.15p+gcc 2.8.x since the latter
did not support C++ in a meaningful manner.

>>+ tic4x doesn't build.

I think the odds that this gets better are even worse than with
the avr. :(

>>
>>Peter Barada has offered to look into our m68k issues so let's make
>>sure all of them are reported with testcases he can try to reproduce
>>on m68k-elf or m68k-linux.  Doing so increases the likelihood of them
>>being fixed in a timely manner.
>>
>>My current gcc CVS source tree has modifications to the following files:
>>
>>M gcc/hard-reg-set.h
> 
> This patch is obsolete. Joern checked in a replacement a couple of days
> ago (cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528)

I suspected that.  Thanks for confirming it.

>>M gcc/config/arm/rtems-elf.h
>>M gcc/config/c4x/rtems.h
>>M gcc/config/i386/t-rtems-i386
> 
> 
> + The sparc/t-rtems (LINK_GCC_C_SEQUENCE_SPEC) patch is missing.
> Bernardo's recent patch did not fix this issue. I have a local patch
> pending, but have not yet tested it with current GCC-4.0.

Commit this also.

> + I still need to resolve the sh-multilib issue.
>  
> 
>>Ralf.. I think it is safe to commit the bottom 3 and I am unsure if this
>>patch still applies.
> 
> No problem - I have these, rsp. my current versions, in a local CVS.

Wonderful.

I am also using your newlib-rtems-20041214.diff and the h8300/h8sim
is still giving conflicting types for int32_t errors.

> 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