gcc: Internal error compiling lilypond on hppa

[Debian Bug Importer]

Automatically imported from Debian bug report #335286 http://bugs.debian.org/335286

[Thomas Bushnell BSG (tb-becket)]

block 335287 by 335286
thanks

[Thomas Bushnell BSG (tb-becket)]

retitle 335286 gcc: Internal error compiling lilypond on hppa,arm
thanks

http://buildd.debian.org/fetch.php?&pkg=lilypond&ver=2.6.3-7&arch=arm&stamp=1130041300&file=log&as=raw

reports the same problem on arm.

It can be confirmed *not* to happen on powerpc and alpha.

Thomas

[Steve Langasek (vorlon)]

reassign 335286 lilypond
thanks

On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:

> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.

> See:
> http:://buildd.debian.org/fetch.php?&pkg=lilypond&ver=2.6.3-7&arch=hppa&stamp=1130038470&file=log&as=raw

> Severity serious because this creates an FTBFS situation for lilypond.

Sorry, this is a known bug in gcc that isn't going to be fixed upstream
until 4.1, and that's still a ways out. As a workaround, please update
lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
doesn't suffer from this particular bug.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Thomas Bushnell BSG (tb-becket)]

reassign 335286 gcc-4.0
thanks

Steve Langasek <email address hidden> writes:

> reassign 335286 lilypond
> thanks
>
> On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:
>
>> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
>
>> See:
>> http:://buildd.debian.org/fetch.php?&pkg=lilypond&ver=2.6.3-7&arch=hppa&stamp=1130038470&file=log&as=raw
>
>> Severity serious because this creates an FTBFS situation for lilypond.
>
> Sorry, this is a known bug in gcc that isn't going to be fixed upstream
> until 4.1, and that's still a ways out. As a workaround, please update
> lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
> doesn't suffer from this particular bug.

How do you know that this is a known bug without knowing what the bug
is? It does not match the other hppa compilation bug reported, which
manifests itself in incorrect code instead of compilation errors, and
which is hppa-specific, while this one appears on arm too.

Can you give me a pointer to your reasons for leaping to the
conclusion that a bug you haven't examined must be a known bug?

Moreover, this bug should remain filed against gcc-4.0, because it is,
in fact, a bug in gcc 4.0. There is a *separate* bug filed against
lilypond referring to this one. This bug should remain open and filed
against gcc-4.0 until a fix is uploaded for Debian.

Thomas

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #335286 http://bugs.debian.org/335286

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 20:49:17 -0700
From: Thomas Bushnell BSG <email address hidden>
To: <email address hidden>
Subject: gcc: Internal error compiling lilypond on hppa

Package: gcc-4.0
Version: 4.0.2-2
Severity: serious

Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.

See:
http:://buildd.debian.org/fetch.php?&pkg=lilypond&ver=2.6.3-7&arch=hppa&stamp=1130038470&file=log&as=raw

Severity serious because this creates an FTBFS situation for lilypond.

Thomas

[Steve Langasek (vorlon)]

severity 335286 important
merge 335286 323133
thanks

On Sat, Oct 22, 2005 at 09:59:30PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:
> > reassign 335286 lilypond
> > thanks

> > On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:

> >> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.

> >> See:
> >> http:://buildd.debian.org/fetch.php?&pkg=lilypond&ver=2.6.3-7&arch=hppa&stamp=1130038470&file=log&as=raw

> >> Severity serious because this creates an FTBFS situation for lilypond.

> > Sorry, this is a known bug in gcc that isn't going to be fixed upstream
> > until 4.1, and that's still a ways out. As a workaround, please update
> > lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
> > doesn't suffer from this particular bug.

> How do you know that this is a known bug without knowing what the bug
> is? It does not match the other hppa compilation bug reported, which
> manifests itself in incorrect code instead of compilation errors, and
> which is hppa-specific, while this one appears on arm too.

> Can you give me a pointer to your reasons for leaping to the
> conclusion that a bug you haven't examined must be a known bug?

Can you give me a pointer to your reasons for leaping to the conclusion that
I haven't examined the bug?

global-context.cc: In member function 'Moment Global_context::_ZTv0_n24_NK14Global_context7now_momEv() const':
global-context.cc:209: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.0/README.Bugs>.

This is the single most common build failure on arm, hppa, and m68k right
now, and has affected literally dozens or hundreds of other packages. I
do kinda know it on sight by this point.

> Moreover, this bug should remain filed against gcc-4.0, because it is,
> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
> lilypond referring to this one. This bug should remain open and filed
> against gcc-4.0 until a fix is uploaded for Debian.

That's fine; I had reassigned it to lilypond before I received the mail that
you had filed a separate bug there. But this is a duplicate of 323133, so
merging. It also is not a release-critical bug because there is a valid
workaround for all affected packages, and in spite of the sizeable impact
it's non-trivial to fix and has been triaged out of necessity.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 21:38:50 -0700
From: Thomas Bushnell BSG <email address hidden>
To: <email address hidden>
Subject: arm too

retitle 335286 gcc: Internal error compiling lilypond on hppa,arm
thanks

http://buildd.debian.org/fetch.php?&pkg=lilypond&ver=2.6.3-7&arch=arm&stamp=1130041300&file=log&as=raw

reports the same problem on arm.

It can be confirmed *not* to happen on powerpc and alpha.

Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 21:37:15 -0700
From: Thomas Bushnell BSG <email address hidden>
To: <email address hidden>
Subject: block it!

block 335287 by 335286
thanks

[Thomas Bushnell BSG (tb-becket)]

Steve Langasek <email address hidden> writes:

> This is the single most common build failure on arm, hppa, and m68k right
> now, and has affected literally dozens or hundreds of other packages. I
> do kinda know it on sight by this point.
>
>> Moreover, this bug should remain filed against gcc-4.0, because it is,
>> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
>> lilypond referring to this one. This bug should remain open and filed
>> against gcc-4.0 until a fix is uploaded for Debian.
>
> That's fine; I had reassigned it to lilypond before I received the mail that
> you had filed a separate bug there. But this is a duplicate of 323133, so
> merging. It also is not a release-critical bug because there is a valid
> workaround for all affected packages, and in spite of the sizeable impact
> it's non-trivial to fix and has been triaged out of necessity.

I find it ludicrous to think that the best solution here is to force a
jillion maintainers to workaround the bug and recompile.

I recall not too recently that you thought hacking version numbers was
an acceptible solution, but I guess that's when your package was the
one that was being asked to have a workaround.

Hrm, seriously though, why not backport the fix (though the upstream
bug record doesn't seem to show one yet, while the Debian bug record
says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
arm, hppa, and m68k?

I see no necessity for "triaging" the bug; this is an excellent reason
simply not to have gcc-4.0 in the archive on the affect archs.
Certainly it should not be in testing!

Surely this is a canonical example of a release-critical toolchain
bug?

Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 21:53:22 -0700
From: Steve Langasek <email address hidden>
To: Thomas Bushnell BSG <email address hidden>, <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

reassign 335286 lilypond
thanks

On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:

> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.

> See:
> http:://buildd.debian.org/fetch.php?&pkg=3Dlilypond&ver=3D2.6.3-7&arch=3D=
hppa&stamp=3D1130038470&file=3Dlog&as=3Draw

> Severity serious because this creates an FTBFS situation for lilypond.

Sorry, this is a known bug in gcc that isn't going to be fixed upstream
until 4.1, and that's still a ways out. As a workaround, please update
lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
doesn't suffer from this particular bug.

Thanks,
--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--LQksG6bCIzRHxTLp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDWxdCKN6ufymYLloRAgwyAJ9oRTZZiJbN608Ti1l3AQ2zgBNqfQCfSG7h
qziqeCXlhZLZ0fUnFWTnq5o=
=JV6q
-----END PGP SIGNATURE-----

--LQksG6bCIzRHxTLp--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 21:59:30 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

reassign 335286 gcc-4.0
thanks

Steve Langasek <email address hidden> writes:

> reassign 335286 lilypond
> thanks
>
> On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:
>
>> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.
>
>> See:
>> http:://buildd.debian.org/fetch.php?&pkg=lilypond&ver=2.6.3-7&arch=hppa&stamp=1130038470&file=log&as=raw
>
>> Severity serious because this creates an FTBFS situation for lilypond.
>
> Sorry, this is a known bug in gcc that isn't going to be fixed upstream
> until 4.1, and that's still a ways out. As a workaround, please update
> lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
> doesn't suffer from this particular bug.

How do you know that this is a known bug without knowing what the bug
is? It does not match the other hppa compilation bug reported, which
manifests itself in incorrect code instead of compilation errors, and
which is hppa-specific, while this one appears on arm too.

Can you give me a pointer to your reasons for leaping to the
conclusion that a bug you haven't examined must be a known bug?

Moreover, this bug should remain filed against gcc-4.0, because it is,
in fact, a bug in gcc 4.0. There is a *separate* bug filed against
lilypond referring to this one. This bug should remain open and filed
against gcc-4.0 until a fix is uploaded for Debian.

Thomas

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.8
reassign 335286 g++-4.0
forwarded 335287 http://gcc.gnu.org/PR21123
block 326224 with 355286
block 335287 with 323133
merge 323133 355286

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.8
block 326224 with 335286
merge 323133 335286

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.8
forwarded 335286 http://gcc.gnu.org/PR21123
notforwarded 335287
merge 323133 335286

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 23:08:52 -0700
From: Steve Langasek <email address hidden>
To: Thomas Bushnell BSG <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

--BwCQnh7xodEAoBMC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

severity 335286 important
merge 335286 323133
thanks

On Sat, Oct 22, 2005 at 09:59:30PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:
> > reassign 335286 lilypond
> > thanks

> > On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell BSG wrote:

> >> Compiling lilypond 2.6.3-7 on hppa, gcc reports an internal error.

> >> See:
> >> http:://buildd.debian.org/fetch.php?&pkg=3Dlilypond&ver=3D2.6.3-7&arch=
=3Dhppa&stamp=3D1130038470&file=3Dlog&as=3Draw

> >> Severity serious because this creates an FTBFS situation for lilypond.

> > Sorry, this is a known bug in gcc that isn't going to be fixed upstream
> > until 4.1, and that's still a ways out. As a workaround, please update
> > lilypond to use g++-3.4 when building on arm, hppa, and m68k, as g++-3.4
> > doesn't suffer from this particular bug.

> How do you know that this is a known bug without knowing what the bug
> is? It does not match the other hppa compilation bug reported, which
> manifests itself in incorrect code instead of compilation errors, and
> which is hppa-specific, while this one appears on arm too.

> Can you give me a pointer to your reasons for leaping to the
> conclusion that a bug you haven't examined must be a known bug?

Can you give me a pointer to your reasons for leaping to the conclusion that
I haven't examined the bug?

global-context.cc: In member function 'Moment Global_context::_ZTv0_n24_NK1=
4Global_context7now_momEv() const':
global-context.cc:209: internal compiler error: in cp_expr_size, at cp/cp-o=
bjcp-common.c:101
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.0/README.Bugs>.

This is the single most common build failure on arm, hppa, and m68k right
now, and has affected literally dozens or hundreds of other packages. I
do kinda know it on sight by this point.

> Moreover, this bug should remain filed against gcc-4.0, because it is,
> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
> lilypond referring to this one. This bug should remain open and filed
> against gcc-4.0 until a fix is uploaded for Debian.

That's fine; I had reassigned it to lilypond before I received the mail that
you had filed a separate bug there. But this is a duplicate of 323133, so
merging. It also is not a release-critical bug because there is a valid
workaround for all affected packages, and in spite of the sizeable impact
it's non-trivial to fix and has been triaged out of necessity.

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 22 Oct 2005 23:18:00 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

Steve Langasek <email address hidden> writes:

> This is the single most common build failure on arm, hppa, and m68k right
> now, and has affected literally dozens or hundreds of other packages. I
> do kinda know it on sight by this point.
>
>> Moreover, this bug should remain filed against gcc-4.0, because it is,
>> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
>> lilypond referring to this one. This bug should remain open and filed
>> against gcc-4.0 until a fix is uploaded for Debian.
>
> That's fine; I had reassigned it to lilypond before I received the mail that
> you had filed a separate bug there. But this is a duplicate of 323133, so
> merging. It also is not a release-critical bug because there is a valid
> workaround for all affected packages, and in spite of the sizeable impact
> it's non-trivial to fix and has been triaged out of necessity.

I find it ludicrous to think that the best solution here is to force a
jillion maintainers to workaround the bug and recompile.

I recall not too recently that you thought hacking version numbers was
an acceptible solution, but I guess that's when your package was the
one that was being asked to have a workaround.

Hrm, seriously though, why not backport the fix (though the upstream
bug record doesn't seem to show one yet, while the Debian bug record
says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
arm, hppa, and m68k?

I see no necessity for "triaging" the bug; this is an excellent reason
simply not to have gcc-4.0 in the archive on the affect archs.
Certainly it should not be in testing!

Surely this is a canonical example of a release-critical toolchain
bug?

Thomas

[Matt Zimmerman (mdz)]

hppa-specific, closing

[Steve Langasek (vorlon)]

On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:

> > This is the single most common build failure on arm, hppa, and m68k right
> > now, and has affected literally dozens or hundreds of other packages. I
> > do kinda know it on sight by this point.

> >> Moreover, this bug should remain filed against gcc-4.0, because it is,
> >> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
> >> lilypond referring to this one. This bug should remain open and filed
> >> against gcc-4.0 until a fix is uploaded for Debian.

> > That's fine; I had reassigned it to lilypond before I received the mail that
> > you had filed a separate bug there. But this is a duplicate of 323133, so
> > merging. It also is not a release-critical bug because there is a valid
> > workaround for all affected packages, and in spite of the sizeable impact
> > it's non-trivial to fix and has been triaged out of necessity.

> I find it ludicrous to think that the best solution here is to force a
> jillion maintainers to workaround the bug and recompile.

I would be happy to see a patch submitted for g++-4.0 that makes it work
correctly on arm/hppa/m68k so that we can stop having maintainers do
busywork. But the busywork can be distributed across the affected
maintainers, and backporting a gcc patch cannot. If you feel up to the task
of providing a backport to fix this bug, I would certainly be grateful. At
any rate, when the decision was made to start building packages with g++-3.4
on these archs, there was no fix yet upstream for the problem.

> I recall not too recently that you thought hacking version numbers was
> an acceptible solution, but I guess that's when your package was the
> one that was being asked to have a workaround.

I'm sorry, but there's a big difference between have a library package
change its name in a critical transition period for reasons that don't match
today's best practices, and having to make a decision between a number of
unpleasant options in order to keep three of our ports in the game building
packages. I don't consider the solution arrived at for gdk-imlib a
"workaround", I consider it the only viable mode for maintaining the large
number of interconnected library packages we have today.

> Hrm, seriously though, why not backport the fix (though the upstream
> bug record doesn't seem to show one yet, while the Debian bug record
> says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
> arm, hppa, and m68k?

If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
the best option, I'm game. One disadvantage is that it wouldn't let us get
feedback about what else might be wrong with g++-4.0 on those architectures,
but we probably already have all the information we're going to get about
the current round of toolchain packages.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 23 Oct 2005 00:20:24 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: reassign 335286 to g++-4.0,
 bug 335287 is forwarded to http://gcc.gnu.org/PR21123 ... ... ...

# Automatically generated email from bts, devscripts version 2.9.8
reassign 335286 g++-4.0
forwarded 335287 http://gcc.gnu.org/PR21123
block 326224 with 355286
block 335287 with 323133
merge 323133 355286

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 23 Oct 2005 00:41:39 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: block 326224 with 335286, merging 323133 335286

# Automatically generated email from bts, devscripts version 2.9.8
block 326224 with 335286
merge 323133 335286

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 23 Oct 2005 00:42:13 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: bug 335286 is forwarded to http://gcc.gnu.org/PR21123, bug 335287 is not forwarded ...

# Automatically generated email from bts, devscripts version 2.9.8
forwarded 335286 http://gcc.gnu.org/PR21123
notforwarded 335287
merge 323133 335286

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 01:39:00 -0700
From: Steve Langasek <email address hidden>
To: Thomas Bushnell BSG <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

--X0cz4bGbQuRbxrVl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:

> > This is the single most common build failure on arm, hppa, and m68k rig=
ht
> > now, and has affected literally dozens or hundreds of other packages. I
> > do kinda know it on sight by this point.

> >> Moreover, this bug should remain filed against gcc-4.0, because it is,
> >> in fact, a bug in gcc 4.0. There is a *separate* bug filed against
> >> lilypond referring to this one. This bug should remain open and filed
> >> against gcc-4.0 until a fix is uploaded for Debian.

> > That's fine; I had reassigned it to lilypond before I received the mail=
 that
> > you had filed a separate bug there. But this is a duplicate of 323133,=
 so
> > merging. It also is not a release-critical bug because there is a valid
> > workaround for all affected packages, and in spite of the sizeable impa=
ct
> > it's non-trivial to fix and has been triaged out of necessity.

> I find it ludicrous to think that the best solution here is to force a
> jillion maintainers to workaround the bug and recompile.

I would be happy to see a patch submitted for g++-4.0 that makes it work
correctly on arm/hppa/m68k so that we can stop having maintainers do
busywork. But the busywork can be distributed across the affected
maintainers, and backporting a gcc patch cannot. If you feel up to the task
of providing a backport to fix this bug, I would certainly be grateful. At
any rate, when the decision was made to start building packages with g++-3.4
on these archs, there was no fix yet upstream for the problem.

> I recall not too recently that you thought hacking version numbers was
> an acceptible solution, but I guess that's when your package was the
> one that was being asked to have a workaround. =20

I'm sorry, but there's a big difference between have a library package
change its name in a critical transition period for reasons that don't match
today's best practices, and having to make a decision between a number of
unpleasant options in order to keep three of our ports in the game building
packages. I don't consider the solution arrived at for gdk-imlib a
"workaround", I consider it the only viable mode for maintaining the large
number of interconnected library packages we have today.

> Hrm, seriously though, why not backport the fix (though the upstream
> bug record doesn't seem to show one yet, while the Debian bug record
> says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
> arm, hppa, and m68k?

If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
the best option, I'm game. One disadvantage is that it wouldn't let us get
feedback about what else might be wrong with g++-4.0 on those architectures,
bu...

[Matthias Klose (doko-cs)]

tags 335286 - fixed-upstream
tags 335286 + help
thanks

Steve Langasek writes:
> On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> > I find it ludicrous to think that the best solution here is to force a
> > jillion maintainers to workaround the bug and recompile.
>
> I would be happy to see a patch submitted for g++-4.0 that makes it work
> correctly on arm/hppa/m68k so that we can stop having maintainers do
> busywork. But the busywork can be distributed across the affected
> maintainers, and backporting a gcc patch cannot. If you feel up to the task
> of providing a backport to fix this bug, I would certainly be grateful. At
> any rate, when the decision was made to start building packages with g++-3.4
> on these archs, there was no fix yet upstream for the problem.

unfortunately this one turned out not to be fixed upstream (or it
reappeared).

> > Hrm, seriously though, why not backport the fix (though the upstream
> > bug record doesn't seem to show one yet, while the Debian bug record
> > says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
> > arm, hppa, and m68k?
>
> If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> the best option, I'm game. One disadvantage is that it wouldn't let us get
> feedback about what else might be wrong with g++-4.0 on those architectures,
> but we probably already have all the information we're going to get about
> the current round of toolchain packages.

And we will see other things turning up, which are fixed in 4.0, but
not in 3.4. 3.4 was never really used on any of our
architectures. For the switch to 4.0, all port maintainers were asked
about the new default, so let at least ask them again, if they agree
going back to 3.4 (or forward to 4.1).

  Matthias

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 12:24:08 +0200
From: Matthias Klose <email address hidden>
To: Steve Langasek <email address hidden>, <email address hidden>
Cc: Thomas Bushnell BSG <email address hidden>, <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

tags 335286 - fixed-upstream
tags 335286 + help
thanks

Steve Langasek writes:
> On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> > I find it ludicrous to think that the best solution here is to force a
> > jillion maintainers to workaround the bug and recompile.
>
> I would be happy to see a patch submitted for g++-4.0 that makes it work
> correctly on arm/hppa/m68k so that we can stop having maintainers do
> busywork. But the busywork can be distributed across the affected
> maintainers, and backporting a gcc patch cannot. If you feel up to the task
> of providing a backport to fix this bug, I would certainly be grateful. At
> any rate, when the decision was made to start building packages with g++-3.4
> on these archs, there was no fix yet upstream for the problem.

unfortunately this one turned out not to be fixed upstream (or it
reappeared).

> > Hrm, seriously though, why not backport the fix (though the upstream
> > bug record doesn't seem to show one yet, while the Debian bug record
> > says fixed-upstream)? Or, failing that, take gcc-4.0 out of use on
> > arm, hppa, and m68k?
>
> If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> the best option, I'm game. One disadvantage is that it wouldn't let us get
> feedback about what else might be wrong with g++-4.0 on those architectures,
> but we probably already have all the information we're going to get about
> the current round of toolchain packages.

And we will see other things turning up, which are fixed in 4.0, but
not in 3.4. 3.4 was never really used on any of our
architectures. For the switch to 4.0, all port maintainers were asked
about the new default, so let at least ask them again, if they agree
going back to 3.4 (or forward to 4.1).

  Matthias

[Thomas Bushnell BSG (tb-becket)]

Steve Langasek <email address hidden> writes:

> If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> the best option, I'm game. One disadvantage is that it wouldn't let us get
> feedback about what else might be wrong with g++-4.0 on those architectures,
> but we probably already have all the information we're going to get about
> the current round of toolchain packages.

The point I'm making is that it's a *release critical* bug. The
relevant gcc should not be in testing on those archs.

[Matthias Klose (doko-cs)]

Thomas Bushnell BSG writes:
> Steve Langasek <email address hidden> writes:
>
> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> > feedback about what else might be wrong with g++-4.0 on those architectures,
> > but we probably already have all the information we're going to get about
> > the current round of toolchain packages.
>
> The point I'm making is that it's a *release critical* bug. The
> relevant gcc should not be in testing on those archs.

ahh, ok. so you did check that defaulting to g++-3.4 on these archs
doesn't reveal another RC bug and we should remove g++-3.4 on these
archs as well?

  Matthias

[Thomas Bushnell BSG (tb-becket)]

Matthias Klose <email address hidden> writes:

> Thomas Bushnell BSG writes:
>> Steve Langasek <email address hidden> writes:
>>
>> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
>> > the best option, I'm game. One disadvantage is that it wouldn't let us get
>> > feedback about what else might be wrong with g++-4.0 on those architectures,
>> > but we probably already have all the information we're going to get about
>> > the current round of toolchain packages.
>>
>> The point I'm making is that it's a *release critical* bug. The
>> relevant gcc should not be in testing on those archs.
>
> ahh, ok. so you did check that defaulting to g++-3.4 on these archs
> doesn't reveal another RC bug and we should remove g++-3.4 on these
> archs as well?

Nope, did you when you told me to downgrade my package to use g++-3.4?

I mean, you can't simultaneously tell all the developers to use
g++-3.4, and then insist that it's not well enough tested to use.

Thomas

[Matthias Klose (doko-cs)]

Thomas Bushnell BSG writes:
> Matthias Klose <email address hidden> writes:
>
> > Thomas Bushnell BSG writes:
> >> Steve Langasek <email address hidden> writes:
> >>
> >> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> >> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> >> > feedback about what else might be wrong with g++-4.0 on those architectures,
> >> > but we probably already have all the information we're going to get about
> >> > the current round of toolchain packages.
> >>
> >> The point I'm making is that it's a *release critical* bug. The
> >> relevant gcc should not be in testing on those archs.
> >
> > ahh, ok. so you did check that defaulting to g++-3.4 on these archs
> > doesn't reveal another RC bug and we should remove g++-3.4 on these
> > archs as well?
>
> Nope, did you when you told me to downgrade my package to use g++-3.4?
>
> I mean, you can't simultaneously tell all the developers to use
> g++-3.4, and then insist that it's not well enough tested to use.

I didn't say that. packages which are affected by this bug should
selectively use g++-3.4.

  Matthias

[Thomas Bushnell BSG (tb-becket)]

Matthias Klose <email address hidden> writes:

>> > ahh, ok. so you did check that defaulting to g++-3.4 on these archs
>> > doesn't reveal another RC bug and we should remove g++-3.4 on these
>> > archs as well?
>>
>> Nope, did you when you told me to downgrade my package to use g++-3.4?
>>
>> I mean, you can't simultaneously tell all the developers to use
>> g++-3.4, and then insist that it's not well enough tested to use.
>
> I didn't say that. packages which are affected by this bug should
> selectively use g++-3.4.

It would suck if both g++-3.4 and g++-4.0 had deal-breaker bugs,
wouldn't it? But if that were so, surely it would be true that both
were, in fact, release critical bugs.

I mean, the bug doesn't stop being release critical against g++-4.0
just because we don't know if some other bugs exist in g++-3.4.

Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 12:41:18 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

Steve Langasek <email address hidden> writes:

> If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> the best option, I'm game. One disadvantage is that it wouldn't let us get
> feedback about what else might be wrong with g++-4.0 on those architectures,
> but we probably already have all the information we're going to get about
> the current round of toolchain packages.

The point I'm making is that it's a *release critical* bug. The
relevant gcc should not be in testing on those archs.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 21:57:37 +0200
From: Matthias Klose <email address hidden>
To: Thomas Bushnell BSG <email address hidden>, <email address hidden>
Cc: Steve Langasek <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

Thomas Bushnell BSG writes:
> Steve Langasek <email address hidden> writes:
>
> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> > feedback about what else might be wrong with g++-4.0 on those architectures,
> > but we probably already have all the information we're going to get about
> > the current round of toolchain packages.
>
> The point I'm making is that it's a *release critical* bug. The
> relevant gcc should not be in testing on those archs.

ahh, ok. so you did check that defaulting to g++-3.4 on these archs
doesn't reveal another RC bug and we should remove g++-3.4 on these
archs as well?

  Matthias

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 13:09:57 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, Steve Langasek <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

Matthias Klose <email address hidden> writes:

> Thomas Bushnell BSG writes:
>> Steve Langasek <email address hidden> writes:
>>
>> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
>> > the best option, I'm game. One disadvantage is that it wouldn't let us get
>> > feedback about what else might be wrong with g++-4.0 on those architectures,
>> > but we probably already have all the information we're going to get about
>> > the current round of toolchain packages.
>>
>> The point I'm making is that it's a *release critical* bug. The
>> relevant gcc should not be in testing on those archs.
>
> ahh, ok. so you did check that defaulting to g++-3.4 on these archs
> doesn't reveal another RC bug and we should remove g++-3.4 on these
> archs as well?

Nope, did you when you told me to downgrade my package to use g++-3.4?

I mean, you can't simultaneously tell all the developers to use
g++-3.4, and then insist that it's not well enough tested to use.

Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 22:13:03 +0200
From: Matthias Klose <email address hidden>
To: Thomas Bushnell BSG <email address hidden>
Cc: <email address hidden>, Steve Langasek <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

Thomas Bushnell BSG writes:
> Matthias Klose <email address hidden> writes:
>
> > Thomas Bushnell BSG writes:
> >> Steve Langasek <email address hidden> writes:
> >>
> >> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> >> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> >> > feedback about what else might be wrong with g++-4.0 on those architectures,
> >> > but we probably already have all the information we're going to get about
> >> > the current round of toolchain packages.
> >>
> >> The point I'm making is that it's a *release critical* bug. The
> >> relevant gcc should not be in testing on those archs.
> >
> > ahh, ok. so you did check that defaulting to g++-3.4 on these archs
> > doesn't reveal another RC bug and we should remove g++-3.4 on these
> > archs as well?
>
> Nope, did you when you told me to downgrade my package to use g++-3.4?
>
> I mean, you can't simultaneously tell all the developers to use
> g++-3.4, and then insist that it's not well enough tested to use.

I didn't say that. packages which are affected by this bug should
selectively use g++-3.4.

  Matthias

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 13:32:05 -0700
From: Thomas Bushnell BSG <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, Steve Langasek <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

Matthias Klose <email address hidden> writes:

>> > ahh, ok. so you did check that defaulting to g++-3.4 on these archs
>> > doesn't reveal another RC bug and we should remove g++-3.4 on these
>> > archs as well?
>>
>> Nope, did you when you told me to downgrade my package to use g++-3.4?
>>
>> I mean, you can't simultaneously tell all the developers to use
>> g++-3.4, and then insist that it's not well enough tested to use.
>
> I didn't say that. packages which are affected by this bug should
> selectively use g++-3.4.

It would suck if both g++-3.4 and g++-4.0 had deal-breaker bugs,
wouldn't it? But if that were so, surely it would be true that both
were, in fact, release critical bugs.

I mean, the bug doesn't stop being release critical against g++-4.0
just because we don't know if some other bugs exist in g++-3.4.

Thomas

[Steve Langasek (vorlon)]

On Sun, Oct 23, 2005 at 12:41:18PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:

> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> > the best option, I'm game. One disadvantage is that it wouldn't let us get
> > feedback about what else might be wrong with g++-4.0 on those architectures,
> > but we probably already have all the information we're going to get about
> > the current round of toolchain packages.

> The point I'm making is that it's a *release critical* bug. The
> relevant gcc should not be in testing on those archs.

It's not. The bug doesn't cause data loss; it's not a security bug; it
doesn't render the package unuseable or mostly so. It renders the package
unuseable for a particular set of affected software, but it is not *mostly*
unuseable because *most* C++ packages still build fine g++-4.0 in spite of
this error. I also doubt that we've ever shipped a toolchain that had *no*
ICEs, and dropping back to g++-3.4 certainly doesn't buy us that either.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Oct 2005 17:05:18 -0700
From: Steve Langasek <email address hidden>
To: Thomas Bushnell BSG <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#335286: gcc: Internal error compiling lilypond on hppa

--Q68bSM7Ycu6FN28Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 23, 2005 at 12:41:18PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <email address hidden> writes:

> > If the gcc maintainers think that pointing g++ at g++-3.4 on these arch=
s is
> > the best option, I'm game. One disadvantage is that it wouldn't let us=
 get
> > feedback about what else might be wrong with g++-4.0 on those architect=
ures,
> > but we probably already have all the information we're going to get abo=
ut
> > the current round of toolchain packages.

> The point I'm making is that it's a *release critical* bug. The
> relevant gcc should not be in testing on those archs. =20

It's not. The bug doesn't cause data loss; it's not a security bug; it
doesn't render the package unuseable or mostly so. It renders the package
unuseable for a particular set of affected software, but it is not *mostly*
unuseable because *most* C++ packages still build fine g++-4.0 in spite of
this error. I also doubt that we've ever shipped a toolchain that had *no*
ICEs, and dropping back to g++-3.4 certainly doesn't buy us that either.

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--Q68bSM7Ycu6FN28Q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDXCU+KN6ufymYLloRAjwwAJ9ri0v+L+zHmxc56WjtZcnOGeh5wACfe0BO
A+mWNXgQ4R400D2el80R4l8=
=9xp5
-----END PGP SIGNATURE-----

--Q68bSM7Ycu6FN28Q--

[Matthias Klose (doko-cs)]

tags 323133 + fixed-upstream
tags 323133 - help
tags 323133 + pending
thanks

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 8 Nov 2005 15:34:53 +0100
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: tag gcc report

tags 323133 + fixed-upstream
tags 323133 - help
tags 323133 + pending
thanks

[Matthias Klose (doko)]

Source: gcc-4.0
Source-Version: 4.0.2-4

We believe that the bug you reported is fixed in the latest version of
gcc-4.0, which is due to be installed in the Debian FTP archive:

cpp-4.0-doc_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/cpp-4.0-doc_4.0.2-4_all.deb
cpp-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/cpp-4.0_4.0.2-4_i386.deb
fastjar_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/fastjar_4.0.2-4_i386.deb
fixincludes_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/fixincludes_4.0.2-4_i386.deb
g++-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/g++-4.0_4.0.2-4_i386.deb
gcc-4.0-base_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gcc-4.0-base_4.0.2-4_i386.deb
gcc-4.0-doc_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/gcc-4.0-doc_4.0.2-4_all.deb
gcc-4.0-locales_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/gcc-4.0-locales_4.0.2-4_all.deb
gcc-4.0_4.0.2-4.diff.gz
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-4.diff.gz
gcc-4.0_4.0.2-4.dsc
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-4.dsc
gcc-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-4_i386.deb
gcj-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gcj-4.0_4.0.2-4_i386.deb
gfortran-4.0-doc_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/gfortran-4.0-doc_4.0.2-4_all.deb
gfortran-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gfortran-4.0_4.0.2-4_i386.deb
gij-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gij-4.0_4.0.2-4_i386.deb
gnat-4.0-doc_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/gnat-4.0-doc_4.0.2-4_all.deb
gnat-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gnat-4.0_4.0.2-4_i386.deb
gobjc-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gobjc-4.0_4.0.2-4_i386.deb
lib64gcc1_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64gcc1_4.0.2-4_i386.deb
lib64gfortran0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64gfortran0_4.0.2-4_i386.deb
lib64objc1_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64objc1_4.0.2-4_i386.deb
lib64stdc++6-4.0-dbg_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64stdc++6-4.0-dbg_4.0.2-4_i386.deb
lib64stdc++6_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64stdc++6_4.0.2-4_i386.deb
libffi4-dev_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libffi4-dev_4.0.2-4_i386.deb
libffi4_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libffi4_4.0.2-4_i386.deb
libgcc1_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcc1_4.0.2-4_i386.deb
libgcj-common_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/libgcj-common_4.0.2-4_all.deb
libgcj6-awt_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcj6-awt_4.0.2-4_i386.deb
libgcj6-common_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/libgcj6-common_4.0.2-4_all.deb
libgcj6-dbg_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcj6-dbg_4.0.2-4_i386.deb
libgcj6-dev_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcj6-dev_4.0.2-4_i386.deb
libgcj6-src_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/libgcj6-src_4.0.2-4_all.deb
libgcj6_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcj6_4.0.2-4_i386.deb
libgfortran0-dev_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgfortran0-dev_4.0.2-4_i386.deb
libgfortran0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgfortran0_4.0.2-4_i386.deb
libgnat-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgnat-4.0_4.0.2-4_i386.deb
libmudflap0-dev_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libmudflap0-dev_4.0.2-4_i386.deb
lib...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 16 Nov 2005 10:32:18 -0800
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: Bug#323133: fixed in gcc-4.0 4.0.2-4

Source: gcc-4.0
Source-Version: 4.0.2-4

We believe that the bug you reported is fixed in the latest version of
gcc-4.0, which is due to be installed in the Debian FTP archive:

cpp-4.0-doc_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/cpp-4.0-doc_4.0.2-4_all.deb
cpp-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/cpp-4.0_4.0.2-4_i386.deb
fastjar_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/fastjar_4.0.2-4_i386.deb
fixincludes_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/fixincludes_4.0.2-4_i386.deb
g++-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/g++-4.0_4.0.2-4_i386.deb
gcc-4.0-base_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gcc-4.0-base_4.0.2-4_i386.deb
gcc-4.0-doc_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/gcc-4.0-doc_4.0.2-4_all.deb
gcc-4.0-locales_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/gcc-4.0-locales_4.0.2-4_all.deb
gcc-4.0_4.0.2-4.diff.gz
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-4.diff.gz
gcc-4.0_4.0.2-4.dsc
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-4.dsc
gcc-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-4_i386.deb
gcj-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gcj-4.0_4.0.2-4_i386.deb
gfortran-4.0-doc_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/gfortran-4.0-doc_4.0.2-4_all.deb
gfortran-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gfortran-4.0_4.0.2-4_i386.deb
gij-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gij-4.0_4.0.2-4_i386.deb
gnat-4.0-doc_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/gnat-4.0-doc_4.0.2-4_all.deb
gnat-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gnat-4.0_4.0.2-4_i386.deb
gobjc-4.0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/gobjc-4.0_4.0.2-4_i386.deb
lib64gcc1_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64gcc1_4.0.2-4_i386.deb
lib64gfortran0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64gfortran0_4.0.2-4_i386.deb
lib64objc1_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64objc1_4.0.2-4_i386.deb
lib64stdc++6-4.0-dbg_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64stdc++6-4.0-dbg_4.0.2-4_i386.deb
lib64stdc++6_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/lib64stdc++6_4.0.2-4_i386.deb
libffi4-dev_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libffi4-dev_4.0.2-4_i386.deb
libffi4_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libffi4_4.0.2-4_i386.deb
libgcc1_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcc1_4.0.2-4_i386.deb
libgcj-common_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/libgcj-common_4.0.2-4_all.deb
libgcj6-awt_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcj6-awt_4.0.2-4_i386.deb
libgcj6-common_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/libgcj6-common_4.0.2-4_all.deb
libgcj6-dbg_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcj6-dbg_4.0.2-4_i386.deb
libgcj6-dev_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcj6-dev_4.0.2-4_i386.deb
libgcj6-src_4.0.2-4_all.deb
  to pool/main/g/gcc-4.0/libgcj6-src_4.0.2-4_all.deb
libgcj6_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgcj6_4.0.2-4_i386.deb
libgfortran0-dev_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/libgfortran0-dev_4.0.2-4_i386.deb
libgfortran0_4.0.2-4_i386.deb
  to pool/main/g/gcc-4.0/l...

[Dato Simó (dato)]

# CCed to -release and -qt-kde for informational purpose

found 323133 4.0.2-4
thanks

Hello,

  This is about Bug#323133, "ICE on arm & m68k when compiling arts (in
  cp_expr_size, at cp/cp-objcp-common.c:101)".

  g++ 4.0.2-4 does indeed successfully compile (tested on paer) the
  sample tests posted in comments 1, 4, and 5 of upstream's PR#21123
  [1], but sadly it still fails to compile the sample file included in
  the original Debian bug report [2], causing the latest upload of arts,
  which uses g++-4.0 in all arches as suggested in Matthias' latest
  d-d-a post [3], fail to build in hppa [4].

    [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
    [2] http://people.debian.org/~adeodato/tmp/2005-08-15/libmcop_la.all_cc.ii.gz
    [3] http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html
    [4] http://buildd.debian.org/fetch.php?&pkg=arts&ver=1.4.3-2&arch=hppa&stamp=1132691788&file=log&as=raw

  If possible, we (Qt/KDE Maintainers) would like to know whether it'd
  make sense to wait a bit and see if this bug can be promptly
  re-solved, or we're better off just re-introducing the use of g++-3.4
  in our packages.

  Thanks in advance,

--
Adeodato Simó dato at the-barrel.org
Debian Developer adeodato at debian.org

                                       Listening to: Dido - all you want

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 23 Nov 2005 02:26:13 +0100
From: Adeodato =?utf-8?B?U2ltw7M=?= <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Reopening the arm/m68k/hppa cp_expr_size ICE bug

# CCed to -release and -qt-kde for informational purpose

found 323133 4.0.2-4
thanks

Hello,

  This is about Bug#323133, "ICE on arm & m68k when compiling arts (in
  cp_expr_size, at cp/cp-objcp-common.c:101)".

  g++ 4.0.2-4 does indeed successfully compile (tested on paer) the
  sample tests posted in comments 1, 4, and 5 of upstream's PR#21123
  [1], but sadly it still fails to compile the sample file included in
  the original Debian bug report [2], causing the latest upload of arts,
  which uses g++-4.0 in all arches as suggested in Matthias' latest
  d-d-a post [3], fail to build in hppa [4].

    [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
    [2] http://people.debian.org/~adeodato/tmp/2005-08-15/libmcop_la.all_cc.ii.gz
    [3] http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html
    [4] http://buildd.debian.org/fetch.php?&pkg=arts&ver=1.4.3-2&arch=hppa&stamp=1132691788&file=log&as=raw

  If possible, we (Qt/KDE Maintainers) would like to know whether it'd
  make sense to wait a bit and see if this bug can be promptly
  re-solved, or we're better off just re-introducing the use of g++-3.4
  in our packages.

  Thanks in advance,

--
Adeodato Simó dato at the-barrel.org
Debian Developer adeodato at debian.org

                                       Listening to: Dido - all you want

[Dato Simó (dato)]

found 323133
thanks

02:21 <dato> so uhm, if we have Source A produce binaries A, and B, a bug gets reported against B,
             closed by an upload (version e.g., 1.1-1), and one then issues "found nnn 1.1-1", the
             bug stays closed.
02:22 <dato> 'cause it's "Found in versions B/1.0-1, B/1.1-1" and "Fixed in version A/1.1-1", see
             e.g. #323133
02:24 * dato just does "found 323133" for now: "the list of fixed versions for the bug is cleared"

--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org

The easy way is the wrong way, and the hard way is the stupid way. Pick one.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 25 Nov 2005 02:25:34 +0100
From: Adeodato =?utf-8?B?U2ltw7M=?= <email address hidden>
To: <email address hidden>
Subject: reopening for real

found 323133
thanks

02:21 <dato> so uhm, if we have Source A produce binaries A, and B, a bug gets reported against B,
             closed by an upload (version e.g., 1.1-1), and one then issues "found nnn 1.1-1", the
             bug stays closed.
02:22 <dato> 'cause it's "Found in versions B/1.0-1, B/1.1-1" and "Fixed in version A/1.1-1", see
             e.g. #323133
02:24 * dato just does "found 323133" for now: "the list of fixed versions for the bug is cleared"

--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org

The easy way is the wrong way, and the hard way is the stupid way. Pick one.

[Matthias Klose (doko)]

Source: gcj-4.0
Source-Version: 4.0.2-5j1

We believe that the bug you reported is fixed in the latest version of
gcj-4.0, which is due to be installed in the Debian FTP archive:

gcj-4.0_4.0.2-5j1.diff.gz
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1.diff.gz
gcj-4.0_4.0.2-5j1.dsc
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1.dsc
gcj-4.0_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1_hppa.deb
gcj-4.0_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1_i386.deb
gcj-4.0_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1_powerpc.deb
gcj-4.0_4.0.2.orig.tar.gz
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2.orig.tar.gz
gij-4.0_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/gij-4.0_4.0.2-5j1_hppa.deb
gij-4.0_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/gij-4.0_4.0.2-5j1_i386.deb
gij-4.0_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/gij-4.0_4.0.2-5j1_powerpc.deb
libgcj-common_4.0.2-5j1_all.deb
  to pool/main/g/gcj-4.0/libgcj-common_4.0.2-5j1_all.deb
libgcj6-awt_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/libgcj6-awt_4.0.2-5j1_hppa.deb
libgcj6-awt_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/libgcj6-awt_4.0.2-5j1_i386.deb
libgcj6-awt_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/libgcj6-awt_4.0.2-5j1_powerpc.deb
libgcj6-common_4.0.2-5j1_all.deb
  to pool/main/g/gcj-4.0/libgcj6-common_4.0.2-5j1_all.deb
libgcj6-dbg_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/libgcj6-dbg_4.0.2-5j1_hppa.deb
libgcj6-dbg_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/libgcj6-dbg_4.0.2-5j1_i386.deb
libgcj6-dbg_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/libgcj6-dbg_4.0.2-5j1_powerpc.deb
libgcj6-dev_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/libgcj6-dev_4.0.2-5j1_hppa.deb
libgcj6-dev_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/libgcj6-dev_4.0.2-5j1_i386.deb
libgcj6-dev_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/libgcj6-dev_4.0.2-5j1_powerpc.deb
libgcj6-src_4.0.2-5j1_all.deb
  to pool/main/g/gcj-4.0/libgcj6-src_4.0.2-5j1_all.deb
libgcj6_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/libgcj6_4.0.2-5j1_hppa.deb
libgcj6_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/libgcj6_4.0.2-5j1_i386.deb
libgcj6_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/libgcj6_4.0.2-5j1_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Matthias Klose <email address hidden> (supplier of updated gcj-4.0 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 1 Dec 2005 22:38:34 +0100
Source: gcj-4.0
Binary: lib64gcj6 gij-4.0 lib32gcj6-dev libgcj6 libgcj6-src libgcj6-awt libgcj6-dev lib32gcj6-dbg libgcj-common libgcj6-common gcj-4.0 libgcj6-dbg lib32gcj6
Architecture: all hppa i386 powerpc source
Version: 4.0.2-5j1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers <debian-gcc@li...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 02 Dec 2005 11:32:28 -0800
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: Bug#323133: fixed in gcj-4.0 4.0.2-5j1

Source: gcj-4.0
Source-Version: 4.0.2-5j1

We believe that the bug you reported is fixed in the latest version of
gcj-4.0, which is due to be installed in the Debian FTP archive:

gcj-4.0_4.0.2-5j1.diff.gz
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1.diff.gz
gcj-4.0_4.0.2-5j1.dsc
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1.dsc
gcj-4.0_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1_hppa.deb
gcj-4.0_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1_i386.deb
gcj-4.0_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2-5j1_powerpc.deb
gcj-4.0_4.0.2.orig.tar.gz
  to pool/main/g/gcj-4.0/gcj-4.0_4.0.2.orig.tar.gz
gij-4.0_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/gij-4.0_4.0.2-5j1_hppa.deb
gij-4.0_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/gij-4.0_4.0.2-5j1_i386.deb
gij-4.0_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/gij-4.0_4.0.2-5j1_powerpc.deb
libgcj-common_4.0.2-5j1_all.deb
  to pool/main/g/gcj-4.0/libgcj-common_4.0.2-5j1_all.deb
libgcj6-awt_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/libgcj6-awt_4.0.2-5j1_hppa.deb
libgcj6-awt_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/libgcj6-awt_4.0.2-5j1_i386.deb
libgcj6-awt_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/libgcj6-awt_4.0.2-5j1_powerpc.deb
libgcj6-common_4.0.2-5j1_all.deb
  to pool/main/g/gcj-4.0/libgcj6-common_4.0.2-5j1_all.deb
libgcj6-dbg_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/libgcj6-dbg_4.0.2-5j1_hppa.deb
libgcj6-dbg_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/libgcj6-dbg_4.0.2-5j1_i386.deb
libgcj6-dbg_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/libgcj6-dbg_4.0.2-5j1_powerpc.deb
libgcj6-dev_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/libgcj6-dev_4.0.2-5j1_hppa.deb
libgcj6-dev_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/libgcj6-dev_4.0.2-5j1_i386.deb
libgcj6-dev_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/libgcj6-dev_4.0.2-5j1_powerpc.deb
libgcj6-src_4.0.2-5j1_all.deb
  to pool/main/g/gcj-4.0/libgcj6-src_4.0.2-5j1_all.deb
libgcj6_4.0.2-5j1_hppa.deb
  to pool/main/g/gcj-4.0/libgcj6_4.0.2-5j1_hppa.deb
libgcj6_4.0.2-5j1_i386.deb
  to pool/main/g/gcj-4.0/libgcj6_4.0.2-5j1_i386.deb
libgcj6_4.0.2-5j1_powerpc.deb
  to pool/main/g/gcj-4.0/libgcj6_4.0.2-5j1_powerpc.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Matthias Klose <email address hidden> (supplier of updated gcj-4.0 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 1 Dec 2005 22:38:34 +0100
Source: gcj-4.0
Binary: lib64gcj6 gij-4.0 lib32gcj6-dev libgcj6 libgcj6-src libgcj6-awt libgcj6-dev lib32gcj6-dbg...

[Matthias Klose (doko)]

Source: gcc-4.0
Source-Version: 4.0.2-5

We believe that the bug you reported is fixed in the latest version of
gcc-4.0, which is due to be installed in the Debian FTP archive:

cpp-4.0-doc_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/cpp-4.0-doc_4.0.2-5_all.deb
cpp-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/cpp-4.0_4.0.2-5_i386.deb
cpp-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/cpp-4.0_4.0.2-5_powerpc.deb
fastjar_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/fastjar_4.0.2-5_i386.deb
fastjar_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/fastjar_4.0.2-5_powerpc.deb
fixincludes_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/fixincludes_4.0.2-5_i386.deb
fixincludes_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/fixincludes_4.0.2-5_powerpc.deb
g++-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/g++-4.0_4.0.2-5_i386.deb
g++-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/g++-4.0_4.0.2-5_powerpc.deb
gcc-4.0-base_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gcc-4.0-base_4.0.2-5_i386.deb
gcc-4.0-base_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gcc-4.0-base_4.0.2-5_powerpc.deb
gcc-4.0-doc_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/gcc-4.0-doc_4.0.2-5_all.deb
gcc-4.0-locales_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/gcc-4.0-locales_4.0.2-5_all.deb
gcc-4.0_4.0.2-5.diff.gz
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-5.diff.gz
gcc-4.0_4.0.2-5.dsc
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-5.dsc
gcc-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-5_i386.deb
gcc-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-5_powerpc.deb
gfortran-4.0-doc_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/gfortran-4.0-doc_4.0.2-5_all.deb
gfortran-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gfortran-4.0_4.0.2-5_i386.deb
gfortran-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gfortran-4.0_4.0.2-5_powerpc.deb
gnat-4.0-doc_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/gnat-4.0-doc_4.0.2-5_all.deb
gnat-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gnat-4.0_4.0.2-5_i386.deb
gnat-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gnat-4.0_4.0.2-5_powerpc.deb
gobjc-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gobjc-4.0_4.0.2-5_i386.deb
gobjc-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gobjc-4.0_4.0.2-5_powerpc.deb
lib64gcc1_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64gcc1_4.0.2-5_i386.deb
lib64gcc1_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64gcc1_4.0.2-5_powerpc.deb
lib64gfortran0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64gfortran0_4.0.2-5_i386.deb
lib64gfortran0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64gfortran0_4.0.2-5_powerpc.deb
lib64objc1_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64objc1_4.0.2-5_i386.deb
lib64objc1_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64objc1_4.0.2-5_powerpc.deb
lib64stdc++6-4.0-dbg_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64stdc++6-4.0-dbg_4.0.2-5_i386.deb
lib64stdc++6-4.0-dbg_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64stdc++6-4.0-dbg_4.0.2-5_powerpc.deb
lib64stdc++6_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64stdc++6_4.0.2-5_i386.deb
lib64stdc++6_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64stdc++6_4.0.2-5_powerpc.deb
libffi4-dev_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/libffi4-dev_4.0.2-5_i386.deb
libf...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 02 Dec 2005 16:32:28 -0800
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: Bug#323133: fixed in gcc-4.0 4.0.2-5

Source: gcc-4.0
Source-Version: 4.0.2-5

We believe that the bug you reported is fixed in the latest version of
gcc-4.0, which is due to be installed in the Debian FTP archive:

cpp-4.0-doc_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/cpp-4.0-doc_4.0.2-5_all.deb
cpp-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/cpp-4.0_4.0.2-5_i386.deb
cpp-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/cpp-4.0_4.0.2-5_powerpc.deb
fastjar_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/fastjar_4.0.2-5_i386.deb
fastjar_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/fastjar_4.0.2-5_powerpc.deb
fixincludes_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/fixincludes_4.0.2-5_i386.deb
fixincludes_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/fixincludes_4.0.2-5_powerpc.deb
g++-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/g++-4.0_4.0.2-5_i386.deb
g++-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/g++-4.0_4.0.2-5_powerpc.deb
gcc-4.0-base_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gcc-4.0-base_4.0.2-5_i386.deb
gcc-4.0-base_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gcc-4.0-base_4.0.2-5_powerpc.deb
gcc-4.0-doc_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/gcc-4.0-doc_4.0.2-5_all.deb
gcc-4.0-locales_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/gcc-4.0-locales_4.0.2-5_all.deb
gcc-4.0_4.0.2-5.diff.gz
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-5.diff.gz
gcc-4.0_4.0.2-5.dsc
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-5.dsc
gcc-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-5_i386.deb
gcc-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gcc-4.0_4.0.2-5_powerpc.deb
gfortran-4.0-doc_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/gfortran-4.0-doc_4.0.2-5_all.deb
gfortran-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gfortran-4.0_4.0.2-5_i386.deb
gfortran-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gfortran-4.0_4.0.2-5_powerpc.deb
gnat-4.0-doc_4.0.2-5_all.deb
  to pool/main/g/gcc-4.0/gnat-4.0-doc_4.0.2-5_all.deb
gnat-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gnat-4.0_4.0.2-5_i386.deb
gnat-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gnat-4.0_4.0.2-5_powerpc.deb
gobjc-4.0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/gobjc-4.0_4.0.2-5_i386.deb
gobjc-4.0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/gobjc-4.0_4.0.2-5_powerpc.deb
lib64gcc1_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64gcc1_4.0.2-5_i386.deb
lib64gcc1_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64gcc1_4.0.2-5_powerpc.deb
lib64gfortran0_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64gfortran0_4.0.2-5_i386.deb
lib64gfortran0_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64gfortran0_4.0.2-5_powerpc.deb
lib64objc1_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64objc1_4.0.2-5_i386.deb
lib64objc1_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64objc1_4.0.2-5_powerpc.deb
lib64stdc++6-4.0-dbg_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/lib64stdc++6-4.0-dbg_4.0.2-5_i386.deb
lib64stdc++6-4.0-dbg_4.0.2-5_powerpc.deb
  to pool/main/g/gcc-4.0/lib64stdc++6-4.0-dbg_4.0.2-5_powerpc.deb
lib64stdc++6_4.0.2-5_i386.deb
  to pool/main/g/gcc-4.0/li...