On Mon, Sep 21, 2009 at 11:23:11AM -0700, Cary Coutant wrote: > >> So aren't we now likely to lose the first few days of what little > >> remains of > >> stage 1 waiting for trunk to start working again, then have a mad rush of > >> people falling all over each other to get their new features in in the last > >> couple of days? One of which will inevitably break trunk again and block > >> all > >> the others and then stage 1 will be over and it'll all be too late? > > > > I am not aware of any big patches that are still pending. Coming up > > with new yet unknown things now wouldn't be a good timing anyway. > > I was hoping to get the dwarf4 branch merged into trunk during stage > 1. While it's not a small patch, it's also not really that intrusive > in that it consists mostly of new code that runs only with the > -gdwarf-4 option. I've been testing it on a lot of big code bases for > the last few months, and haven't found any new bugs for a more than a > month now, so I think it's ready. > > I'll work on merging top-of-trunk into the branch early this week and > then send a patch to merge back into the trunk. > > -cary >
Cary, Are you saying that current gcc trunk should require -gdwarf-4 to issue dwarf4 commands? I ask because r151815... http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html causes dwarf4 by default. Is there a consistent policy on this? Currently in PR41405, there is a proposal for a -gstrict-dwarf option which I guess should be expanded to cover your patch if gcc 4.5 will be defaulting to -gdwarf-4 being enabled. Jack
