GCC 4.7.0 Status Report (2011-09-09)

GCC 4.7.0 Status Report (2011-09-09)

[Jakub Jelinek]

Status
======

The trunk is in Stage 1, which, if we follow roughly the 4.6
release schedule, should end around end of October.
At this point I'd like to gather the status of the various
development branches that haven't been merged into trunk yet
and whether it is possible to merge them with such a schedule
or whether e.g. a two weeks delay would help them.
In particular, is transactional-memory branch mergeable within
a month and half, at least some parts of cxx-mem-model branch,
bitfield lowering?  What is the status of lra, reload-2a, pph,
cilkplus, gupc (I assume at least some of these are 4.8+ material)?


Quality Data
============

Priority          #   Change from Last Report
--------        ---   -----------------------
P1                6   +  6
P2               95   + 10
P3               59   + 56
--------        ---   -----------------------
Total           160   + 72


Previous Report
===============

http://gcc.gnu.org/ml/gcc/2011-03/msg00178.html

The next status report will be sent by Joseph.

Re: GCC 4.7.0 Status Report (2011-09-09)

[Richard Guenther]

On Fri, Sep 9, 2011 at 9:09 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> Status
> ======
>
> The trunk is in Stage 1, which, if we follow roughly the 4.6
> release schedule, should end around end of October.
> At this point I'd like to gather the status of the various
> development branches that haven't been merged into trunk yet
> and whether it is possible to merge them with such a schedule
> or whether e.g. a two weeks delay would help them.
> In particular, is transactional-memory branch mergeable within
> a month and half, at least some parts of cxx-mem-model branch,
> bitfield lowering?  What is the status of lra, reload-2a, pph,
> cilkplus, gupc (I assume at least some of these are 4.8+ material)?

Bitfield lowering is not going to happen (well, completely at least) unless
I can find some more time to work on it.  Instead I want to finally
make no-longer-sign-extending sizetypes happen for 4.7, which currently
only waits on Ada frontend issues.

Btw, end of October will then be 7 1/2 month worth of stage1 already.

Richard.

Re: GCC 4.7.0 Status Report (2011-09-09)

[Andrew MacLeod]

On 09/09/2011 03:09 AM, Jakub Jelinek wrote:
>
> In particular, is transactional-memory branch mergeable within
> a month and half, at least some parts of cxx-mem-model branch,

There will certainly be some parts of the branch which would be 
appropriate for merging with mainline in october.  We ought to at least 
have the new __sync_mem builtins available to replace the old ones, and 
the testing infrastructure.  Im not sure we will have *all* the 
infrastructure in place, but it should be pretty close if not.  Its also 
fairly low risk.

Andrew

Re: GCC 4.7.0 Status Report (2011-09-09)

[Vladimir Makarov]

On 09/09/2011 03:09 AM, Jakub Jelinek wrote:
> Status
> ======
>
> The trunk is in Stage 1, which, if we follow roughly the 4.6
> release schedule, should end around end of October.
> At this point I'd like to gather the status of the various
> development branches that haven't been merged into trunk yet
> and whether it is possible to merge them with such a schedule
> or whether e.g. a two weeks delay would help them.
> In particular, is transactional-memory branch mergeable within
> a month and half, at least some parts of cxx-mem-model branch,
> bitfield lowering?  What is the status of lra, reload-2a, pph,
> cilkplus, gupc (I assume at least some of these are 4.8+ material)?
>
LRA is a long project.  At the best case it will be ready for 4.8 but 
most probably for 4.9.

Re: GCC 4.7.0 Status Report (2011-09-09)

[Aldy Hernandez]

Jakub Jelinek <jakub@redhat.com> writes:

> In particular, is transactional-memory branch mergeable within
> a month and half, at least some parts of cxx-mem-model branch,
> bitfield lowering?  What is the status of lra, reload-2a, pph,

Torvald and I are looking into getting things merge read, but...

The main problem seems to be that the TM community still hasn't formally
submitted the C++ changes to the standards committee, and are still
swinging between two alternate syntax implementations.  So unless, this
gets resolved in the next month, transactional memory will have to sit
this one out.

Torvald, is this a fair assessment?

Re: GCC 4.7.0 Status Report (2011-09-09)

[Jeff Law]

On 09/09/2011 01:09 AM, Jakub Jelinek wrote:
> bitfield lowering?  What is the status of lra, reload-2a, pph,
> cilkplus, gupc (I assume at least some of these are 4.8+ material)?
The bits on reload-v2a provide range splitting and a second chance at 
assigning a hard reg for unallocated allocnos.  The code has been very 
stable and shows a small improvement on x86/x86_64.  The biggest concern 
I have with the code is the compile-time performance, which I know is 
bad, but I haven't done any serious measurements.

jeff

Re: GCC 4.7.0 Status Report (2011-09-09)

[Jan Hubicka]

> On 09/09/2011 03:09 AM, Jakub Jelinek wrote:
>> Status
>> ======
>>
>> The trunk is in Stage 1, which, if we follow roughly the 4.6
>> release schedule, should end around end of October.
>> At this point I'd like to gather the status of the various
>> development branches that haven't been merged into trunk yet
>> and whether it is possible to merge them with such a schedule
>> or whether e.g. a two weeks delay would help them.
>> In particular, is transactional-memory branch mergeable within
>> a month and half, at least some parts of cxx-mem-model branch,
>> bitfield lowering?  What is the status of lra, reload-2a, pph,
>> cilkplus, gupc (I assume at least some of these are 4.8+ material)?
>>
> LRA is a long project.  At the best case it will be ready for 4.8 but  
> most probably for 4.9.

There are some LTO bits I would still like to be done for 4.7, so we
get it ready for production at least for some packages.  We discusse
dthis briefly with Richard/Michael/Martin and generally most improtant
seems to be:

1) Making -g not ICE and hopefuly produce useable debug info
   (-g works relatively well for C, so it would make LTO useful to build
    i.e. command line tools/binutils etc. that might by itself bring
    interesting speedups given that binnaries shrink.)
2) Adding sane method for handling command line options
3) Slim LTO
4) Solving the COMDAT problems with plugin API
5) There are still some bugs in symbol table handling

We plan to work on those, but any help is apprechiated.
2-5 are obviously all doable before end of october.

Honza

Re: GCC 4.7.0 Status Report (2011-09-09)

[Gary Funck]

On 09/09/11 09:09:30, Jakub Jelinek wrote:
> [...] What is the status of lra, reload-2a, pph,
> cilkplus, gupc (I assume at least some of these are 4.8+ material)?

For GUPC, we are targeting GCC 4.8.

thanks,
- Gary

Re: GCC 4.7.0 Status Report (2011-09-09)

[Torvald Riegel]

On Mon, 2011-09-12 at 08:51 -0500, Aldy Hernandez wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > In particular, is transactional-memory branch mergeable within
> > a month and half, at least some parts of cxx-mem-model branch,
> > bitfield lowering?  What is the status of lra, reload-2a, pph,
> 
> Torvald and I are looking into getting things merge read, but...
> 
> The main problem seems to be that the TM community still hasn't formally
> submitted the C++ changes to the standards committee, and are still
> swinging between two alternate syntax implementations.  So unless, this
> gets resolved in the next month, transactional memory will have to sit
> this one out.
> 
> Torvald, is this a fair assessment?

The group working on the C++ TM specification has made progress, and I
think we now have something that is basically okay for most people that
are involved.
Thus, I think that it would be good to include TM.

Torvald

RE: GCC 4.7.0 Status Report (2011-09-09)

[Iyer, Balaji V]

-----Original Message-----
From: Gary Funck [mailto:gary@intrepid.com] 
Sent: Thursday, September 22, 2011 5:00 PM
To: Jakub Jelinek
Cc: gcc@gcc.gnu.org; Joseph S. Myers
Subject: Re: GCC 4.7.0 Status Report (2011-09-09)

On 09/09/11 09:09:30, Jakub Jelinek wrote:
> [...] What is the status of lra, reload-2a, pph, cilkplus, gupc (I 

I apologize for the late response, my radar didn't catch this message. Cilkplus is not currently feature-complete. We definitely hope to have it completed as soon as we can.

> assume at least some of these are 4.8+ material)?

For GUPC, we are targeting GCC 4.8.

thanks,
- Gary