GCC 4.1/4.2 Status Report (2005-11-18)

GCC 4.1/4.2 Status Report (2005-11-18)

[Mark Mitchell]

The number of open serious regressions against 4.1 is a respectable 87,
quite a few of which are P3s, waiting for me to categorize them.  We
still have some work to do before the release, but we will branch on
2005-11-18, as previously announced, at some point late Friday evening.
 Thank you for being patient through the long Stage 3.

I am still reviewing the 4.2 projects, but I will post some ideas about
staging those in before I create the branch tomorrow.  There looks to be
some exciting stuff in the pipeline!

I would like to better understand the status of GOMP; is it going to be
ready for 4.2 within a couple of months?

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: GCC 4.1/4.2 Status Report (2005-11-18)

[Diego Novillo]

On Friday 18 November 2005 03:48, Mark Mitchell wrote:

> I would like to better understand the status of GOMP; is it going to be
> ready for 4.2 within a couple of months?
>
Most definitely.  We have been essentially waiting for 4.1 to branch.  
There are 5 modules to merge: library, C, C++, Fortran, middle-end.
The FEs can be merged in more or less independently from library and 
middle-end.

Re: GCC 4.1/4.2 Status Report (2005-11-18)

[Mark Mitchell]

Diego Novillo wrote:
> On Friday 18 November 2005 03:48, Mark Mitchell wrote:
> 
> 
>>I would like to better understand the status of GOMP; is it going to be
>>ready for 4.2 within a couple of months?
>>
> Most definitely.  We have been essentially waiting for 4.1 to branch.  
> There are 5 modules to merge: library, C, C++, Fortran, middle-end.
> The FEs can be merged in more or less independently from library and 
> middle-end.

Great news.  (The GOMP entry on the projects list was just a link to the
project page; it didn't have this data.)

It seems like it makes sense to do the library and middle-end first, and
then the various front-ends in serial?  Do you agree?

I'd like to have a look at the C++ bits before they go in, but I'll not
be looking to make life difficult. :-)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: GCC 4.1/4.2 Status Report (2005-11-18)

[Diego Novillo]

On Friday 18 November 2005 11:24, Mark Mitchell wrote:

> Great news.  (The GOMP entry on the projects list was just a link to the
> project page; it didn't have this data.)
>
Yeah, we hadn't updated the status section yet.  I added a paragraph 
earlier today.

> It seems like it makes sense to do the library and middle-end first, and
> then the various front-ends in serial?  Do you agree?
>
Yes.  The mental model is something like this:

1- Thread safety changes for libgfortran.  These are relatively independent 
from gomp and Jakub will submit them the minute we branch 4.1.

2- Library and middle end.  This can probably go in on its own, but I would 
prefer to commit it together with the C front end.  Otherwise, there won't 
be anything to play with.

3- C front end.  This may need a bit of review, though Richard has not 
expressed any reservations about it.

4- C++ and Fortran will need a fair bit of in-depth review by FE 
maintainers.  I expect these two to take the longest to merge.


> I'd like to have a look at the C++ bits before they go in, but I'll not
> be looking to make life difficult. :-)

:)  Yes, we will probably request quite a bit of help from you folks.

Re: GCC 4.1/4.2 Status Report (2005-11-18)

[Mark Mitchell]

Diego Novillo wrote:

> Yes.  The mental model is something like this:

Makes sense.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: GCC 4.1/4.2 Status Report (2005-11-18)

[Mike Stump]

On Nov 18, 2005, at 8:24 AM, Mark Mitchell wrote:
> I'd like to have a look at the C++ bits before they go in, but I'll  
> not
> be looking to make life difficult. :-)

There was one thing I saw that was bad, as I recall, but I didn't  
mention it as I thought it'd be cleaned up on the branch.  And now, I  
can't recall what it was.  I'll see about doing a once over of the C+ 
+ bits and see if I can spot it.

RTEMS GCC Status Report

[Joel Sherrill <joel@OARcorp.com>]

Mark Mitchell wrote:
> The number of open serious regressions against 4.1 is a respectable 87,
> quite a few of which are P3s, waiting for me to categorize them.  We
> still have some work to do before the release, but we will branch on
> 2005-11-18, as previously announced, at some point late Friday evening.
>  Thank you for being patient through the long Stage 3.

Mark we are trying to test furiously and I know that neither Ada nor 
RTEMS is a primary target but I wanted to pass along a few issues that
are being worked by various people.  I am sure that this is not a 
complete list but covers the important issues impacting RTEMS GCC.

+ PR24912 - m68k build failure: ICE: in reload_cse_simplify_operands
   This is a recent regression and a patch has just been proposed.

+ No PR - The Ada tools mangle target names like arm-rtems4.7.
   Apparently they don't like the version part.  Laurent is working on
   this.

+ No PR - The Ada tools end up invoking a cross compiler which is
   hard coded to be in /usr/bin.  This may be a side-effect of the
   name mangling problem and just a default that is being tripped.
   We don't know yet.

Ralf if I missed something really critical, speak up.  I was focusing 
more on "doesn't work at all" issues.  I don't see any ICEs while 
building RTEMS right now.

The targets we try to build are:

avr-rtems4.7		- C
i386-rtems4.7		- C, C++, Ada
powerpc-rtems4.7	- C, C++, Ada
sparc-rtems4.7		- C, C++, Ada
mips64-rtems4.7		- C, C++, Ada
m68k-rtems4.7		- C, C++, Ada
i686-pc-linux-gnu 	- C, C++, Ada (to bootstrap the others with)
mips-rtems4.7		- C, C++, Ada
arm-rtems4.7		- C, C++, Ada
sh-rtems4.7		- C, C++, Ada
h8300-rtems4.7		- C, C++

For each target, we have been building RTEMS and a handful of other 
libraries including ncurses, readline, and libtecla.

We are pushing at the avr and it won't build right now and we have filed 
a PR.

I need to check if the Ada multilib support is ready for us to turn on 
and push.  Right now, I am more concerned that the target name issue
is preventing us from even getting a hello world to link.

--joel

Re: RTEMS GCC Status Report

[Laurent GUERBY]

On Fri, 2005-11-18 at 15:14 -0600, Joel Sherrill  wrote:
> + No PR - The Ada tools mangle target names like arm-rtems4.7.
>    Apparently they don't like the version part.  Laurent is working on
>    this.

To be accurate I promised to work on this once Paolo configure
patch is in, because I'm currently unable to apply it cleanly to my
tree :).

Laurent

Re: RTEMS GCC Status Report

[Joel Sherrill <joel@OARcorp.com>]

Laurent GUERBY wrote:
> On Fri, 2005-11-18 at 15:14 -0600, Joel Sherrill  wrote:
> 
>>+ No PR - The Ada tools mangle target names like arm-rtems4.7.
>>   Apparently they don't like the version part.  Laurent is working on
>>   this.
> 
> 
> To be accurate I promised to work on this once Paolo configure
> patch is in, because I'm currently unable to apply it cleanly to my
> tree :).

Yes.  I should have included Paolo's patch as a MAJOR requirement.
Otherwise you can't build a newlib cross target as best I can tell.

Please, pretty please get that merged.

--joel