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

[Peter Jones]

On 09/10/2009 06:27 PM, Tom Lane wrote:
> Mark Wielaard <mjw at redhat.com> writes:
>> Jesse Keating <jkeating <at> redhat.com> writes:
>>> 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.
> 
>> Although it obviously would have been far nicer to have had this all in before
>> the mass rebuild, there were multiple test builds against rawhide
>> packages.
> 
> ISTM the major argument in favor of letting this in now, namely better
> debuginfo data, is essentially moot because it missed the mass rebuild.
> The majority of packages are going to go out with old debuginfo.

I'm not sure that's entirely true.  Right now, a frequent debugging workflow
for me is something like:

1) discover the problem I'm seeing is in $PACKAGE
2) check out $PACKAGE from cvs and make a test-srpm
3) build it without optimizations
4) wedge it into my test environment
5) debug!

With better debuginfo generation in gcc, this workflow remains the same,
but it's possible that a) I may not have to turn of optimizations in
step #3, which can be a nontrivial difference depending on the package,
and b) I may get better results with step #5 .

So there is some advantage to doing this now, though it's not as great
as it could be had it been done within Fedora's unrealistic schedule.

-- 
        Peter

When in doubt, debug-on-entry the function you least suspect has
anything to do with something.