Re: GCC var-tracking-assignments: testing and bug reports appreciated
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