Adam Heath writes:
Package: libgcj2
Severity: serious
Library packages should not include binaries. Please see policy section 11.3.
...
If your package has some run-time support programs which use the shared
library you must not put them in the shared library package. If you do
Phil Edwards writes:
All the foo-3.0 packages don't depend, recommend or even suggest the
foo packages making it possible (especially on hppa where -3.0 is
the default compiler) to install just gcc-3.0 and not have a gcc
symlink which is probably not a good thing?
The 'gcc' package is
Back from vacation, suffering from the jetlag ... preparing a
gcc-3.0.3 upload for unstable. Currently scanning my mailbox for
patches. Anything else, which should be included? I'm asking, because
my unstable environment has been deleted during my absence, so I have
to restart from Chris' last
John R. Daily writes:
I sent this to the debian-ia64 list recently and received no
input. Given the apparent lack of concern about making such a
change, I'd like to inquire on this list whether such a change
would be technically and politically feasible pre-woody.
Matthias, I understand
J.H.M.Dassen writes:
Package: gcc-3.0
Version: 1:3.0.2-4
Severity: normal
When compiling 2.4.17-pre6:
gcc-3.0 -D__KERNEL__ -I/extra/localsrc/linux/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe
[EMAIL PROTECTED] writes:
Subject: gcc: Rebuild of gcc 1:2.95.2-13 from source with extra CFLAGS causes
Internal compiler error (gpc1 coredumps)
Package: gcc
Version: 1:2.95.2-13
please retry with the current gcc-2.95 from testing/unstable (2.95.4).
I should not patch libstdc++ myself :-( This is the offending patch,
introduced to resolve a severe performance problem compared to
gcc-2.95.2. See #92524 and #100571.
http://bugs.debian.org/92524
http://bugs.debian.org/100571
--- src-native/libstdc++/sstream~ Tue
all
Version: 1:3.0.3ds0-0pre011209
Distribution: unstable
Urgency: medium
Maintainer: Debian GCC maintainers debian-gcc@lists.debian.org
Changed-By: Matthias Klose [EMAIL PROTECTED]
Description:
cpp-3.0- The GNU C preprocessor.
cpp-3.0-doc - Documentation for the GNU C preprocessor (cpp
:3.0.3ds1-0pre011210
Distribution: unstable
Urgency: medium
Maintainer: Debian GCC maintainers debian-gcc@lists.debian.org
Changed-By: Matthias Klose [EMAIL PROTECTED]
Description:
cpp-3.0- The GNU C preprocessor.
cpp-3.0-doc - Documentation for the GNU C preprocessor (cpp).
fastjar- Jar
:3.0.3ds2-0pre011215
Distribution: unstable
Urgency: low
Maintainer: Debian GCC maintainers debian-gcc@lists.debian.org
Changed-By: Matthias Klose [EMAIL PROTECTED]
Description:
cpp-3.0- The GNU C preprocessor.
cpp-3.0-doc - Documentation for the GNU C preprocessor (cpp).
fastjar- Jar
Is this a problem, that you can work around using g++-3.0 on mips? I
see the menu package up to date for mips. just wanting to reduce the
severity of the report from `grave' to `important'.
On Wed, Nov 28, 2001 at 03:29:31AM +, Colin Watson wrote:
On Mon, 26 Nov 2001 at 19:01:21 +0100,
Guido Guenther writes:
On Thu, Dec 20, 2001 at 06:47:17PM +0100, Matthias Klose wrote:
Is this a problem, that you can work around using g++-3.0 on mips? I
see the menu package up to date for mips. just wanting to reduce the
severity of the report from `grave' to `important'.
Building
all
Version: 1:3.0.3ds3-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC maintainers debian-gcc@lists.debian.org
Changed-By: Matthias Klose [EMAIL PROTECTED]
Description:
cpp-3.0- The GNU C preprocessor.
cpp-3.0-doc - Documentation for the GNU C preprocessor (cpp).
fastjar
Package: binutils,gcc-3.0
Version: 2.11.92.0.12.3-3
Severity: grave
Tags: help
help needed ...
build log on vore:~doko/prot.3.0.1-1, build tree in gcc-3.0-3.0.3ds3.
two things:
- executables generated with the new compiler terminate with
bus errors. see the g++ testsuite:
===
Ben Collins writes:
On Sun, Dec 23, 2001 at 03:03:01AM +0100, Matthias Klose wrote:
That's the problem...let me remove that package and put this bug on
binutils-multiarch. Try the build again Matthias.
ok, the latter problem went away, however I still get the regressions
(bus
Chris Wedgwood writes:
There are reports on lk that gcc-2.95.4 (as found in Debian
sid/unstable) producing bogus kernels.
searching on http://www.uwsg.indiana.edu/hypermail/linux/kernel/
I found only the old 2.95.2 problems. Please could you point to some
messages (URLs)?
Alexander Schreiber writes:
Hi!
Looks like there are b0rken dependencies around the GNU Pascal Compiler
in Debian woody. The packages gpc and gpc-doc are mutually exclusive -
installing one will uninstall the other because they are marked as
conflicting in their control files.
install
Rainer Ellinger writes:
I had the same problem today, while recompiling a already running linux
kernel 2.4.16 setup. The only thing i changed was the processor
selection from 386 to Pentium-Classic (see configs below) and
Pentium-MMX in a second try. Both had the same error. With 386
merge 126675 112887
tags 126675 + wontfix
thanks
using dpkg-divert should work even when upgrading the package.
Joseph Carter writes:
Package: gcc
Version: 2:2.95.4-9
Severity: wishlist
I have changed the gcc symlink on my system to point to gcc-3.0 to help
work out the kinks with the
Joseph Carter writes:
On Fri, Dec 28, 2001 at 02:37:31PM +0100, Matthias Klose wrote:
using dpkg-divert should work even when upgrading the package.
That's a bit less hackish I suppose than futzing with the symlink
directly, but I still believe /etc/alternatives would be a good thing
here
Paul J. Keenan writes:
Package: libgcj2
Version: 1:3.0.3-1
Severity: normal
/usr/bin/gcj is a link to /usr/bin/gcj-3.0, so shouldn't there
be a link /usr/bin/gij, linked to /usr/bin/gij-3.0 ?
yes, it's in the gij package.
Martin v. Loewis writes:
I can't see a reason for libstdc++ requiring _GNU_SOURCE except for the
desire to re-export symbols in std::, for which I would propose a
different strategy.
It would help to know why this was done in the first place; there could be
other reasons.
Sure,
reopen 127263
thanks
Morten Brix Pedersen writes:
* Matthias Klose [EMAIL PROTECTED] [2002-01-01 17:21:43]:
They are. See /usr/doc/libstdc++3-doc/libstdc++/html_user/
I'm talking about shipping the man-pages with the package, so you can do
man something, HTML reference isn't the same.
[CC to [EMAIL PROTECTED]; the gpc version is the RC2, the gcc version 2.95.4
CVS]
Philip Blundell writes:
The version of gpc in the 2001-12-23 upload doesn't seem to work on arm,
sparc, m68k or s390; they all seem to segfault somewhere during the build.
../.././xgpc -B../.././ -c -I. -W
Phil Edwards writes:
Something that just came up last week: it might be nice to have a toolchain
targeting the win32 platform. The few times I've needed to build a .exe
from a linux box were memorable experiences due to the hoop-jumping required.
(I suspect it's much easier now.)
Users
David Schleef writes:
On Fri, Dec 21, 2001 at 10:09:45PM +0100, Andreas Krennmair wrote:
Package: gcc
Version: 2:2.95.4-8
Severity: wishlist
It would be nice to have more cross-compilers available,
so that it can become possible cross-compile programs for other
platforms.
Gordon Haverland writes:
Package: gij
Version: 2:3.0.3-1
Severity: normal
Some documentation on gij suggests that the -I/path
switch can be used to prepend directories to otherwise
provided/generated classpath. This includes current
information at the gnu site. The gij binary doesn't
Did somebody look at the test results before installing this for
sparc??? IMO it COMPLETELY breaks C++ on sparc!
Debian Installer writes:
Installing:
cpp-3.0_3.0.3-1_sparc.deb
to pool/main/g/gcc-3.0/cpp-3.0_3.0.3-1_sparc.deb
[...]
Goswin Brederlow writes:
Package: gcc-3.0
Version: 1:3.0.3-1
Severity: normal
The package doesn't pass its selftests and _should_fail_ to build.
It should fail when the first make fails and not continue with other
selftest, otherwise errors get overlocked.
huh? then we'll never have a
Christopher C. Chimelis writes:
Speaking of bugs, can you take back 126162? I've
fixed my part of it already and the ball's back in your court.
unsure, who gets the ball, but not me/gcc. I tried to build an old
gcc-3.0.2 debian package and an upstream 3.0.3 package on vore. All
show the same
Ben Collins writes:
On Sat, Jan 05, 2002 at 01:39:58AM +0100, Matthias Klose wrote:
Christopher C. Chimelis writes:
Speaking of bugs, can you take back 126162? I've
fixed my part of it already and the ball's back in your court.
unsure, who gets the ball, but not me/gcc. I tried
Phil Edwards writes:
On top of all the other reasons already mentioned, the memory expansion
code for basic_string in 3.0 wasn't as good as it could be (and it
wasn't strictly conforming in some cases). These problems have already
been fixed for 3.1; there are some spiffy benchmarks in the
Phil Edwards writes:
On Tue, Jan 08, 2002 at 06:27:20PM +0100, Matthias Klose wrote:
how stable is this compared to 3.0.3? Is the ABI upward compatible, so
that it could replace 3.0.3?
Good point. This is something a lot of people get confused by. Including
me, so get your grains
Hakan Ardo writes:
The process is documented in /usr/share/doc/toolchain-source/README,
but should probably be placed where people might look for it. Where
is that?
Maybe you want to provide an updated README.cross file for
gcc-{2.95,3.0}?
Just saw your upload for stable. Wouldn't it be better to upload a
gcc-2.95.3 to stable?
Note that this problem is fixed in gcc-3.0 but I think
gcc-2.95 is important because it is the main C compiler
for Woody.
How many translations are there available for gcc-2.95? Please send a
patch, if you think, it's important. IMO it would be better to
concentrate on translations for the
Looking at the number of open and forwarded reports, it looks like one
of the maintainers will soon orphan the package or fade away ...
No, but I ask for help. It would be nice to address the reports for
the woody release and more important for the next gcc release. It is
nice to see upstream
upstream report is bootstrap/5209, currently open.
accessible at http://gcc.gnu.org/cgi-bin/gnatsweb.pl
reassign 129573 scalapack
tags 129573 + moreinfo
thanks
a build log is not the way to report a compiler error.
- please mention the compiler version
- please include the source file in the report
- try to build at reduced optimization level (no inline, -O2)
- try to build with g77-3.0
after
Please could you recheck with gcc-3.0, and if this version doesn't fix
it, with the recently uploaded gcc-snapshot package?
Thanks, Matthias
Lukas Geyer writes:
Package: gcc
Version: 2:2.95.4-9
Severity: important
Compiling the current gnuchess source fails with this gcc (current woody)
Manoj Srivastava writes:
Package: fastjar
Version: 1:3.0.4-0pre020127
Severity: grave
Justification: renders package unusable
Hi,
My argument is that if one can't even install the package,
surely it is unusable?
sure, but I checked that it installs ...
Setting up fastjar
Even with setting the locale, I cannot reproduce this. Could you try
to install/upgrade another package, which uses alternatives?
Manoj Srivastava writes:
Matthias == Matthias Klose [EMAIL PROTECTED] writes:
Matthias Manoj Srivastava writes:
Package: fastjar
Version: 1:3.0.4-0pre020127
Santiago Vila writes:
Is there any particular reason why gcj does not set up a symlink
javac - gcj using the alternatives mechanism, as jikes used to do before
Bug #43730 was reported?
an alternative should only be provided, if a reasonable set of options
match. Unfortunately the options for
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN
HTML
HEAD
META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=iso-8859-1
META NAME=Generator CONTENT=MS Exchange Server version 5.5.2653.12
TITLEInstalling/TITLE
/HEAD
BODY
PFONT SIZE=2Dear Debian Developers,/FONT
/P
PFONT SIZE=2A
Submitter-Id: net
Originator:Falk Hueffner [EMAIL PROTECTED]
Organization: The Debian project
Confidential: no
Synopsis: [regression from 2.95.3] Initialization of flexible char array
member segfaults
Severity: non-critical
Priority: low
Category: c
Class:
Santiago Vila writes:
On 5 Feb 2002, Stephen Zander wrote:
Santiago == Santiago Vila [EMAIL PROTECTED] writes:
Santiago What about the other java compilers? It is true, for
Santiago example, that for each architecture that will be
Santiago released in woody there is at
Philip Blundell writes:
tags 130422 + patch
thanks
see http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00627.html
plus some earlier analysis at
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=viewdatabase=gccpr=4860
in incoming, no regressions at least for i386.
Matthias
Peter Koellner writes:
well, and then take the fact that dpkg gcc 2.95.4 is derived from
the original sources of gcc 2.95.2..
that's some kind of misinformation. 2.95.4 is derived from 2.95.3,
following the gcc-2_95-branch on CVS.
Documentation/Changes reads:
The recommended compiler for
I don't think this is related to libstdc++2.10-dev (a dev package not
containing any shared libs).
First significant bug is:
Preparing to replace libstdc++2.10-dev 1:2.95.2-13 (using
.../libstdc++2.10-dev_1%3a2.95.4-1_i386.deb) ...
perl: /lib/libc.so.6: version `GLIBC_2.2' not found
Debian Bug Tracking System writes:
Processing commands for [EMAIL PROTECTED]:
reassign 135943 gcc
Bug#135943: r-recommended_1.4.1-1 fails to autobuild on m68k
Bug reassigned from package `r-recommended' to `gcc'.
retitle 135943 gcc on m68k has internal error in coxfit2.c in survival in
Philip Blundell writes:
On Wed, 2002-02-27 at 17:04, Adam C Powell IV wrote:
3.0 fixes this problem, but then maintainers must hand-build using
g77-3.0, which is not a viable long-term solution. I know some arches
have 3.0 as their default compiler. So, what are the criteria, and
Philip Blundell writes:
On Wed, 2002-02-27 at 19:27, Matthias Klose wrote:
Philip Blundell writes:
On Wed, 2002-02-27 at 17:04, Adam C Powell IV wrote:
3.0 fixes this problem, but then maintainers must hand-build using
g77-3.0, which is not a viable long-term solution. I know some
Bernd Eckenfels writes:
I have the feeling we have a very big GCC Problem in unstable and testing.
Some -O2 optimizations of gcc cause SIGBUS on aligned architectures (SPARC),
and now even on intel I get regularly SIGSEGVs. I have a few packages which
received those reports, and it looks to me
Adam C Powell IV writes:
reopen 136359
thanks
Thank you for your patience in this, I'm sorry to be such a pain in the
neck. But it still doesn't work, I'm still getting a SIGFPE in
f__cabs() from cabs.c in libg2c...
Okay, I think I see what's going on. In the alpha build log, there's
A first shot at gcc-3.1 can be found at
http://ftp-master.debian.org/~doko/gcc, based on the latest gcc-3.0
packaging.
Feedback wanted on:
- sparc: do we really need this? maybe Ben wants to have a look after
yesterday ;-) It's annoying to try this without being able to
install anything.
-
Philip Blundell writes:
On Tue, 2002-04-02 at 11:04, Matthias Klose wrote:
- arm: missing(?) arm-patches
I sent the two patches we had in 3.0 to the gcc mailing lists. Maybe
there's still a chance that they might be included in the actual
release. If not, it's no big deal.
ok (btw, I
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Samuel Tardieu writes:
| - should we build gnat from the gcc-3.1 source at all?
Sure.
Then I add you to the maintainers list and you subscribe to
[EMAIL PROTECTED]
| - package names: I choose gnat-3.15 and libgnat3.15a. Is this ok, or
| should it be gnat-3.1?
Mmm, at least until we
David Starner writes:
Sorry, Matthias Klose seems to have taken down the GCC 3.1 packages.
Still, it's not that hard to compile from source.
??? http://ftp-master.debian.org/~doko/gcc/
beware, CVS snapshots of the 3.1 branch ...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
Jeff Bailey writes:
`hurd-i386' has just completed an ABI bump. We've been very careful
to keep back packages that depend on libstdc++, as I had heard that
there's some compatability problems.
Do you object if we declare gcc-3.1 to be our default compiler as soon
as you upload? I just
can be found at http://ftp-master.debian.org/~doko/gcc. For now, I
disabled building a shared gnat library. Any compilation with the
compiler built with the shared library fails due to an undefined
xstrdup symbol (at least on i386-linux and s390-linux). Upstream
cannot reproduce this, so I'll wait
While preparing gcc-3.1 packages I noticed many eh-related regressions
fixed in the trunk, when dwarf2 support was added. With Dave's
guidance I made a diff of the pa subdirectory from the trunk and
applied it to the branch. Although many FAILS are gone, there are some
new (diff below).
I would
John David Anglin writes:
While preparing gcc-3.1 packages I noticed many eh-related regressions
fixed in the trunk, when dwarf2 support was added. With Dave's
guidance I made a diff of the pa subdirectory from the trunk and
applied it to the branch. Although many FAILS are gone, there are
Jeff Bailey writes:
On Fri, Apr 26, 2002 at 12:44:45AM +0200, Matthias Klose wrote:
Considering the confusion of having gcc272 as default C compiler
and egcs as default C++ compiler in slink and the arch by arch
switch to new compiler versions, I would propose to switch all
John David Anglin writes:
Thanks. Could you try the following patch, please?
yes, allows the bootstrap.
--- 5ntaprop.adb.~1.3.~ Sun Mar 17 09:08:21 2002
+++ 5ntaprop.adb Sun Apr 28 22:42:59 2002
@@ -45,9 +45,6 @@
-- used for Ada_Task_Control_Block
-- Task_ID
the code generation on ix86 didn't change with gcc-3.1
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi,
3.1 fails to bootstrap on m68k-linux. When ignoring the comparision
failure and running the testsuite I get mixed results, compared to the
last reported build on gcc-testresults:
http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg01017.html
Ben, what's the state of the lib/64 - lib64 conversion? I have an 3.0
upload prepared, but we need an updated glibc and binutils for sparc
first. Should we go without this?
Yann Dirson writes:
Package: gij-3.0
Version: 1:3.0.4-8
Severity: serious
Justification: Policy 5.6
Tags: sid
[EMAIL
Jérôme Marant writes:
Florian Weimer [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Jérôme Marant) writes:
I've read in the gcc ML that versioning libgnat as 3.15a
is erroneous, according to Robert Dewar.
It's still in the GCC CVS...
And what's problematic with deciding
Jesse Hall writes:
Package: gcc-3.1
Version: 1:3.1-2
Severity: normal
The header file xmmintrin.h seems to be missing from the package. It
was introduced in gcc-3.1, and is needed to use the SSE intrinsic
functions. I believe it should be in
/usr/lib/gcc-lib/i386-linux/3.1/include.
I
retitle 141900 [fixed in gcj-3.1] compile breaks using temporary inner class
instance
reassign 141900 gcj-3.0
tags 141900 + fixed
thanks
Ben Burton writes:
Package: gcj
Version: 2:3.0.4-5
Severity: normal
Hi. I'm getting a gcj compile error when calling a member function of a
newly
retitle 141902 [fixed in gcj-3.1] default constructor for inner class causes
broken bytecode
severity 141902 + fixed
thanks
Ben Burton writes:
Package: gcj-3.0
Version: 1:3.0.4-6
Severity: normal
Hi. I have the following piece of code that compiles correctly but then
gives an error when
reassign 143138 kdelibs
thanks
please submit a complete bug report including the preprocessed
source. Even better, please try compiling with g++-3.1 and g++-3.0.
Thanks, Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
retitle 141899 [fixed in gcj-3.1] locks up during .java-.class compilation
severity 141899 + fixed
thanks
Ben Burton writes:
Package: gcj-3.0
Version: 1:3.0.4-6
Severity: normal
Hi. I have a java file that causes gcj to lock up when it tries to
compile it to java bytecode. The specific
tags 135727 + helpneeded
forwarded 135727 [EMAIL PROTECTED]
thanks
please recheck with gpc-2.95.4-9 (final gpc-2.1 release) on powerpc
(gpc-2.95 version in unstable).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reassign 142703 sword
tags 142703 + helpneeded
thanks
please recompile with g++-3.1 and/or g++-3.0 and report the results,
then reassign back.
Daniel Glassey writes:
Package: g++
sword 1.5.3-1 will not build on alpha.
the error is for compiling file src/mgr/swmgr.cpp which includes map
retitle 134315 [fixed in g++-3.1] iostream.h does not like -fPIC
tags 134315 + fixed
reassign 134315 g++-3.0
thanks
Arjen Hommersom writes:
Package: gcc
Version: 3.0.3-1
This script:
#!/bin/sh
cat /tmp/test.cc EOF
#include iostream.h
int main(void)
{
reassign 118781 g++-2.95
retitle 118781 [fixed in g++-3.0] internal compiler error using nested templates
tags 118781 + fixed
thanks
[EMAIL PROTECTED] writes:
Package: g++
Version: 2:2.95.4-8
Severity: normal
Hi,
In trying to compile the following C++ program fragment using the command
retitle 118670 [not a bug/fixed in libgcc1] libgcc.a symbols end up exported by
shared libraries
tags 118670 + fixed
reassign 118670 g++-2.95
thanks
Martin v. Loewis writes:
If this is okay, then libgcc.a might as well be in a libgcc.so,
and we can link that when linking with gcc
retitle 111613 [fixed in gcc-3.1] on hppa get a SEGV when compiling pari with
-O3
reassign 111613 gcc-3.0
tags 111613 + fixed
thanks
Bill Allombert writes:
From: Matthew Wilcox [EMAIL PROTECTED]
the example given no longer segfaults on paer.debian.org; i presume an
upload since has fixed
retitle 2910 [fixed in gcc-3.1] GCC accepts multi-line strings without \ or
c
tags 2910 + fixed
thanks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
retitle 85535 [fixed in gcc-3.1, PR optimization/3508]: builtin memcmp() could
be optimised
tags 85535 + fixed
thanks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
LAST_UPDATED: Tue Feb 16 13:25:49 UTC 2010 (revision 156802)
Target: i486-linux-gnu
gcc version 4.3.4 (Debian 4.3.4-8)
Native configuration is i486-pc-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
LAST_UPDATED: Tue Feb 16 13:25:49 UTC 2010 (revision 156802)
Target: powerpc-linux-gnu
gcc version 4.3.4 (Debian 4.3.4-8)
Native configuration is powerpc-unknown-linux-gnu
=== g++ tests ===
Running target unix
FAIL: g++.dg/torture/pr38565.C -O0 (test for excess errors)
FAIL:
LAST_UPDATED: Tue Feb 16 13:25:49 UTC 2010 (revision 156802)
Target: ia64-linux-gnu
gcc version 4.3.4 (Debian 4.3.4-8)
Native configuration is ia64-unknown-linux-gnu
=== g++ tests ===
Running target unix
FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump tree_profile
LAST_UPDATED: Tue Feb 16 13:25:49 UTC 2010 (revision 156802)
Target: s390-linux-gnu
gcc version 4.3.4 (Debian 4.3.4-8)
Native configuration is s390-ibm-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
LAST_UPDATED: Tue Feb 16 23:50:22 UTC 2010 (revision 156816)
Target: x86_64-linux-gnu
gcc version 4.5.0 20100216 (experimental) [trunk revision 156816] (Debian
20100216-1)
=== acats tests ===
=== acats Summary ===
# of expected passes2321
# of
Package: ppl
Version: 0.10.2-4
Severity: serious
the prolog tests fail at least on powerpc. Please either fix these that the
package is built again, or ignore the failures in the prolog testsuite. ppl is
used as a gcc build-dependency, and we shouldn't care that much about clean
prolog tests.
LAST_UPDATED: Tue Feb 16 13:25:49 UTC 2010 (revision 156802)
Target: x86_64-linux-gnu
gcc version 4.3.4 (Debian 4.3.4-8)
Native configuration is x86_64-pc-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
LAST_UPDATED: Tue Feb 16 13:25:49 UTC 2010 (revision 156802)
Target: hppa-linux-gnu
gcc version 4.3.4 (Debian 4.3.4-8)
Native configuration is hppa-unknown-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary ===
# of expected passes
LAST_UPDATED: Tue Feb 16 13:25:49 UTC 2010 (revision 156802)
Target: mipsel-linux-gnu
gcc version 4.3.4 (Debian 4.3.4-8)
Native configuration is mipsel-unknown-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
LAST_UPDATED: Tue Feb 16 13:25:49 UTC 2010 (revision 156802)
Target: i486-kfreebsd-gnu
gcc version 4.3.4 (Debian 4.3.4-8)
Native configuration is i486-pc-kfreebsd-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
LAST_UPDATED: Tue Feb 23 01:03:07 UTC 2010 (revision 156985)
Target: x86_64-linux-gnu
gcc version 4.5.0 20100223 (experimental) [trunk revision 156985] (Debian
4.5-20100222-1)
Native configuration is x86_64-pc-linux-gnu
=== g++ tests ===
Running target unix
FAIL:
LAST_UPDATED: Sun Jan 17 15:19:51 UTC 2010 (revision 155979)
Target: powerpc-linux-gnu
gcc version 4.5.0 20100117 (experimental) [trunk revision 155979] (Debian
20100117-1)
=== acats tests ===
=== acats Summary ===
# of expected passes2321
# of
clone 571532 -1
reassign -1 ant
thanks
so why does 1.7 work, and not 1.8? If we cannot resolve this, we should release
squeeze with 1.7.
I don't plan to work on this myself.
On 25.02.2010 21:08, Torsten Werner wrote:
Package: gij
Version: 4:4.4.2-3
Severity: critical
Justification: breaks
LAST_UPDATED: Obtained from SVN: tags/gcc_4_4_3_release revision 156151
Native configuration is alpha-unknown-linux-gnu
=== libgomp tests ===
Running target unix
=== libgomp Summary ===
# of expected passes2440
=== libstdc++ tests
LAST_UPDATED: Obtained from SVN: tags/gcc_4_4_3_release revision 156151
Target: i486-linux-gnu
gcc version 4.4.3 (Debian 4.4.3-3)
Native configuration is i486-pc-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
101 - 200 of 12761 matches
Mail list logo
