[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gcc-4.1 status in unstable



Steve Langasek writes:
> Hi Matthias,
> 
> On Sun, Oct 29, 2006 at 02:20:39PM +0100, Matthias Klose wrote:
> > gcc-4.1 4.1.1-19 in unstable now looks like not showing build time
> > regressions compared to 4.1.1-13 in testing, validated on amd64.
> > Lucas Nussbaum volunteered to build testing from 2006-10-24 with -13
> > and -17, the results can be found at [1].  The failures are detailed
> > below and supposed to be fixed in either -19 by reverting three
> > upstream changes, or in new packages uploaded to unstable. I would
> > like to ask porters to do a rebuild with -19 on their architecture,
> > where that seems to be possible within a recent time.
> 
> Reviewing the changelog, I note the following:
> 
>  4.1.1ds2-17 is listed as closing PR c++/29408, and 4.1.1ds2-18 is listed as
>  reverting this patch.  Does that mean 392327 and 393010 should be reopened? 
>  If so, have we just traded one bug marked "serious" for another?

no, reverting both PR c++/29138, PR c++/29408 lets all three test
cases as reported in the bugs pass.

>  Bug #387989 is listed as "addressed" by another revert in 4.1.1ds2-18.
>  Should this bug also be downgraded?

yes, done.

> In addition, several of the "m68k" patches touch shared files:
> m68k-java.dpatch touches java/boehm.c, m68k-dwarf2.dpatch touches
> gcc/dwarf2out.c, and m68k-peephole-note.dpatch and m68k-prevent-swap.dpatch
> both touch gcc/recog.c.  How certain is it that these patches don't cause
> regressions for other architectures?

applied for the m68k build only.

> > In summary the -19 package did see improvement with about 100
> > regressions fixed upstream compared to the -13 in testing.  I'm not
> > (yet) proposing inclusion of -19 in testing, but calling for testing
> > on other architectures than amd64.
> 
> Other than my uncertainty that reverting the PR 29408 change will actually
> be a net win, -19 looks good to me, and I'm ok with pushing it into testing
> whenever it's ready (which seems to first require manual removal of libssp0
> from unstable for those archs where you've dropped it).

a bug report is filed for ftp.debian.org

there maybe will a -20 to fix more arch specific bugs on m68k and
alpha, I'll stay away from touching any C++ code at this stage.

  Matthias



Reply to: