GCC var-tracking-assignments: testing and bug reports appreciated

[Josh Boyer]

On Thu, Sep 10, 2009 at 01:43:26PM +0200, Jakub Jelinek wrote:
>On Thu, Sep 10, 2009 at 07:32:07AM -0400, Josh Boyer wrote:
>> >Why are you backporting something like this from a non-released compiler
>> >into F12 _after_ Alpha and particularly _after_ the mass rebuild?
>> 
>> No response?  None?
>> 
>> I mean, I'm not asking for much.  All I want is an explanation as to why
>> this _has_ to be in F12 and can't be rolled into F13 instead.  At first
>> glance, it would make more sense to let the feature get some testing in
>> GCC mainline before we just backport it to Fedora users, so putting it
>> in F13 seems better to me.
>
>Because we really want it in F12, to make e.g. systemtap usable. It got
>quite a lot of testing already and has been in development for 2 years.
>Originally it was expected to be merged early in the summer, testing
>rawhide gccs have been prepared already in early August.

So systemtap wasn't considered usable before this?  I am not a GCC
expert, but I can see how this feature would help it.  But it was surely
usable before this, right?

>There were so far 3 bugreports related to this, 2 of them are already fixed,
>LLVM build is just needing too much memory on completely insane source
>(people calling functions with 1375 arguments, 685 out of it are classes
>with non-trivial ctors passed by value, deserve some punishment) and Alex
>will look at it today.

I have every confidence that you and Alex will fix all the bugs reported.
I also think the code itself is likely fairly stable, and may very well
provide some usability wins overall.  Your competence as a developer is
not, nor ever was, in question so please don't misunderstand my
questioning.

The largest problem I have with all this is the fact that the release
guidelines that everyone else has to follow don't appear to be followed
at all in this case.  You're introducing a backported feature into a
critical path package after Feature freeze, and after a mass-rebuild
which would have arguably helped test the hell out of this.  Any other
maintainer would have to get an exception from rel-eng and/or FESCo in
order to do something like this.  I don't see why the same requirements
don't apply here.

josh