GCC Status Report (2009-08-23)

GCC Status Report (2009-08-23)

[Mark Mitchell]

Status
======

The trunk is in Stage 1.  As previously stated, we expect that Stage 1
will last through at least the end of August.

In my opinion, the single hardest issue we face with respect to 4.5 is
how to handle the VTA branch.  I've consulted with various people who
have a lot of experience with GCC and the opinions on this work seem
to be quite mixed.  I've looked at the branch myself and can't seem to
form a firm opinion.  The problem it's setting out to solve is
definitely important, but the scope of this particular solution
frightens me.  On the other hand, I can't see a viable better
solution.  So, I'd be very interested in further comments on this
topic.  Feel free to send those to me privately, if you would like to
provide a confidential opinion.

On the quality front, the level of P1 issues has been holding steady
for some time.  Most of the P1 issues are issues around core
optimization technology.  The number of P2 bugs seems to be increasing
slightly.

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

Priority	  #	Change from Last Report
--------	---	-----------------------
P1		 16       0
P2		104 	+ 7
P3		  0	- 4
--------	---	-----------------------
Total		120	+ 3

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

http://gcc.gnu.org/ml/gcc/2009-07/msg00607.html

The next report for 4.5.0 will be sent by Richard.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: GCC Status Report (2009-08-23)

[Toon Moene]

Mark Mitchell wrote:

> Status
> ======
> 
> The trunk is in Stage 1.  As previously stated, we expect that Stage 1
> will last through at least the end of August.

Perhaps it is a good idea to list here what new features we expect to be 
*in* 4.5 (e.g., which branches we expect to be merged into mainline 
before we branch) ?

Unfortunately, I cannot help you with the decision on the VTA branch - 
as you said, it is important work, but the changes seem pretty invasive.

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Re: GCC Status Report (2009-08-23)

[Mark Mitchell]

Toon Moene wrote:

> Perhaps it is a good idea to list here what new features we expect to be
> *in* 4.5 (e.g., which branches we expect to be merged into mainline
> before we branch) ?

I think that LTO and Graphite are the two major features certain for
4.5.  VTA is the possible third major feature, if we can reach consensus
that it's a good solution to the problem it's set out to solve.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: GCC Status Report (2009-08-23)

[George T. Talbot]

Mark Mitchell <mitchell <at> codesourcery.com> writes:

> 
> 
> Status
> ======
> 
> The trunk is in Stage 1.  As previously stated, we expect that Stage 1
> will last through at least the end of August.
> 
> In my opinion, the single hardest issue we face with respect to 4.5 is
> how to handle the VTA branch.
>
> ...[deletia]...
>
> On the other hand, I can't see a viable better
> solution.  So, I'd be very interested in further comments on this
> topic.

As an end user...

I had to read up on VTA (I'm a user, not compiler developer).  If VTA works even
half as well as claimed on optimized code, and GDB supports the debug
information it emits, then this feature alone would make me switch relatively
instantly.

If there's one feature I've wanted out of the GDB/GCC combination over the last
ten years, this would be it.  I've banged my head against the wall many a time
trying to figure out a bug that occurs differently at -O[n>0] vs. -O0, and at
this time, GDB+GCC+O3 is often less than useful when debugging production code.

Just my $0.02.

--
George T. Talbot
<gtalbot@locuspharma.com>

Re: GCC Status Report (2009-08-23)

[Frank Ch. Eigler]

mitchell@codesourcery.com (Mark Mitchell) writes:

> [...]  In my opinion, the single hardest issue we face with respect
> to 4.5 is how to handle the VTA branch.  [...]  The problem it's
> setting out to solve is definitely important, but the scope of this
> particular solution frightens me.  [...]

I can only address the "benefits" side of this.

I think VTA (and control-flow-related followup technologies) would
mark the beginning of the end of the entrenched idea that "if you want
to debug your code, you have to compile with -O0", which have lead to
a proliferation of asserts, ad-hoc conditional printfs, compiled-in
debugging-only functions.

With the extra dwarf metadata, already existing consumer programs will
be able to trace/debug final deployed binaries.  Developers will be
able to better see into what's going on in released, running programs,
not just ones built differently in one's own sandbox.  It should
enable new whole new development tools.

This is the grand promise, anyway.  I think it's a big step forward.

- FChE