Re: 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

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

[Jesse Keating]

On Thu, 2009-09-10 at 08:27 -0400, Josh Boyer wrote:
> 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.

This is my issue too.  There is claim that it was tested, yet it wasn't
tested in the same place we require every other feature to be tested,
that being rawhide.

If GCC is going to get special treatment, we should discuss, agree upon,
and document that special treatment to avoid GCC being used as an excuse
for others to ignore our policy and procedure.