This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: deadline extension for debug info project into GCC 4.3 stage3?
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Alexandre Oliva" <aoliva at redhat dot com>
- Cc: "Mark Mitchell" <mark at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 1 Oct 2007 16:25:29 +0200
- Subject: Re: deadline extension for debug info project into GCC 4.3 stage3?
- References: <200708100019.l7A0JDf1019939@sparrowhawk.codesourcery.com> <or4pi2xuv1.fsf@free.oliva.athome.lsd.ic.unicamp.br> <46E61149.3060508@codesourcery.com> <orlkattg8i.fsf@oliva.athome.lsd.ic.unicamp.br>
On 9/26/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Sep 11, 2007, Mark Mitchell <mark@codesourcery.com> wrote:
>
> > That's a possibility, but I don't want to commit at this point. We can
> > have a look at it when you submit it and decide. However, in general,
> > introducing churn for the sake of a feature that will be off by default
> > isn't something that I would want to do. The more compartmentalized you
> > make it, the better your chances are.
>
> It's nearly impossible to make the patch compartmentalized, but pretty
> much all of the changes would be clearly disabled and no-ops unless
> the flag was given in the command line.
>
> That said, I found out there's still a long way to go before this is
> actually a no-op in terms of generated code (other than debug info,
> that is), as far as testsuite results, target libraries and other
> ports are concerned, so I'm thinking this is very unlikely to make 4.3
> :-(
Can you develop this more in the open to allow contribution, facititate further
review and make merging it to 4.4 less pain? It looks like that if the patch
is not easy to compartmentalize then a branch would be appropriate, though
also patches would be fine. I find myself in a situation where I would need to
start doing the same work as you (possibly).
Thanks,
Richard.