Processing of gcc-2.95_2.95.4.ds15-22_i386.changes
gcc-2.95_2.95.4.ds15-22_i386.changes uploaded successfully to localhost along with the files: gcc-2.95_2.95.4.ds15-22.dsc gcc-2.95_2.95.4.ds15-22.diff.gz cpp-2.95-doc_2.95.4-22_all.deb g77-2.95-doc_2.95.4-22_all.deb gcc-2.95-doc_2.95.4-22_all.deb gpc-2.95-doc_2.95.4-22_all.deb gcc-2.95_2.95.4-22_i386.deb cpp-2.95_2.95.4-22_i386.deb g++-2.95_2.95.4-22_i386.deb gobjc-2.95_2.95.4-22_i386.deb g77-2.95_2.95.4-22_i386.deb chill-2.95_2.95.4-22_i386.deb libstdc++2.10-glibc2.2_2.95.4-22_i386.deb libstdc++2.10-dev_2.95.4-22_i386.deb libstdc++2.10-dbg_2.95.4-22_i386.deb libg++2.8.1.3-glibc2.2_2.95.4-22_i386.deb libg++2.8.1.3-dev_2.95.4-22_i386.deb libg++2.8.1.3-dbg_2.95.4-22_i386.deb gpc-2.95_2.95.4-22_i386.deb Greetings, Your Debian queue daemon
GCC fails check on x86_64
I would appreciate any suggestions for this oddity ... please ... Attached message is my most recent posting to the AMD64 porting list. GCC appears to build successfully, but checks fail as shown in the attachment. If someone would like the full 6MB (uncompressed) build log, let me know. Any other software that makes heavy use of floating point, such as blas or atlas, also fails to complete its selftest routines successfully. I don't know how to tell whether the problem is the GCC itself, a system library or a kernel corruption. The system runs memtest86 for hours on end and can build any other software, such as SSL, that doesn't need heavy access to the floating point support. I have a pure64 environment and a pure32 environment only ... at this time. I'm in the process of setting up a cross toolchain for pure64 that runs on pure32. Thanks, Alex. --- Begin Message --- John Goerzen wrote: On Mon, Mar 08, 2004 at 03:18:40PM -0800, Alex Perry wrote: With that change, the build runs to completion. Two concerns: 1. It doesn't run the torture tests for the binary-arch target; you have to debian/rules check and (when I do that) I get a series of segfaults and test failures. I've never run that; if it doesn't happen by default in binary-arch, you are stumbling across something I've never tried. So your result there may mimic mine. I've attached the slightly-revised script as well as the report from the selftest. It shows lots and lots of failures under test. I would _REALLY_ appreciate it if people with a pure64 chroot could run that script and see whether they get the same failures (which would blame something in GCC) or they get it to pass (which would blame something in my hardware or my kernel). 2. It appears not to have refreshed the gcc-3.3 deb file as you can see: Weird. I'm afraid I don't have any hint for you there. Note that I am a distinctly poor gcc hacker, and what I've been able to do has been mostly blind trial and error. I have no idea if it's correct or not. John, could you run the script at your convenience and check that it does build the gcc .deb for you, as expected, and there isn't some subtle mistake in my patch files? Meanwhile, I'll go back to trying to resurrect my biarch chroot so I can build a kernel. A second kernel may magically be able to make all these problems vanish... Alex. NOW RUNNING THE OPTIONAL TESTS - MAY TAKE A WHILE echo -e "\nPatches that Debian applied in this version:" > pxxx for i in cvs-updates gcc-version rename-info-files libstdc++-pic libstdc++-doclink gccbug libtool-rpath mips-branch-fix test-summary gcj-without-rpath libffi-install libffi-no-debug deb-protoize libobjc reporting autoreconf ; do \ echo -e "\n$i:" >> pxxx; \ sed -n 's/^# *DP: */ /p' debian/patches/$i.dpatch >> pxxx; \ done mv -f pxxx stamps/02-patch-stamp mkdir -p stamps /usr/bin/make -f debian/rules.conf control make[1]: Entering directory `/home/alex/build/gcc-3.3-3.3.3ds5' languages="ada c c++ f77 java objc pascal treelang"; \ addons="cdev c++dev fastjar fdev fixincl javadev libcxx libg2c"; \ addons="$addons libgcc libffi libgcj libgnat libnof libobjc libs"; \ addons="$addons lib64gcc lib64cxx lib64ffi lib64gcj lib64gnat"; \ addons="$addons lib64objc lib64g2c libnof objcdev proto"; \ echo "addons: $addons"; \ m4 -DCV=1:3.3.3 -DNV=1:3.3.4 -DGPC_CV=2:3.3.3.20030830-2 -DBINUTILSV=2.13.90.0.10 -DSRCNAME=gcc-3.3 -D__x86_64__ -DARCH=x86_64 -DOBJC_GC -DLIBC_DEP="libc6-dev (>= 2.3.1)" -DBINUTILS_BUILD_DEP="binutils (>= 2.14.90.0.4) | binutils (<< 2.14), binutils (>= 2.13.90.0.10) [!m68k !sparc] | binutils (>= 2.13.90.0.18-1.3) [m68k] | binutils (>= 2.13.90.0.18-1.4) [sparc]" -DLIBC_BUILD_DEP="libc6.1-dev (>= 2.3.1) [alpha ia64] | libc0.3-dev [hurd-i386] | libc1-dev [freebsd-i386] | libc12-dev [netbsd-i386] | libc6-dev (>= 2.3.1)" \ -DPV=-3.3 \ -DGPC_PV=-2.1-3.3 \ -DCXX_SO=5 \ -DGCC_SO=1 \ -DOBJC_SO=1 \ -DG2C_SO=0 \ -DGCJ_SO=4 \ -DGNAT_SO=3.15 \ -DGNAT_V=3.3 \ -DFFI_SO=2 \ -Denabled_languages="$languages $addons" \ -Dada_no_archs="!arm !hurd-i386 !m68k !freebsd-i386 !netbsd-i386 !amd64" \ -Dpascal_no_archs="!netbsd-i386 !alpha !ia64 !arm !amd64" \ -Dlibgc_no_archs="!avr !freebsd-i386" \ -Dcheck_no_archs="!hurd-i386" \ -Dlocale_no_archs="!netbsd-i386 !hurd-i386" \ debian/control.m4 > debian/control.tmp2 addons: cdev c++dev fastjar fdev fixincl javadev libcxx libg2c libgcc libffi libgcj libgnat libnof libobjc libs lib64gcc lib64cxx lib64ffi lib64gcj lib64gnat lib64objc lib64g2c libnof objcdev proto uniq debian/control.tmp2 > debian/control.tmp rm -f debian/control.tmp2 [ -e debian/control ] \ && cmp -s debian/control debian/control.tmp \ && rm -f debian/control.tmp && exit 0; \ mv debian/control.tmp debian/control; touch stamps/03-control-stamp rm -f debian/rules.parameters.tmp ( \ echo '# configuration parameters taken from upstream source files'; \ echo 'VER := 3.3.
gcc-2.95_2.95.4.ds15-22_i386.changes ACCEPTED
Accepted: chill-2.95_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/chill-2.95_2.95.4-22_i386.deb cpp-2.95-doc_2.95.4-22_all.deb to pool/main/g/gcc-2.95/cpp-2.95-doc_2.95.4-22_all.deb cpp-2.95_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/cpp-2.95_2.95.4-22_i386.deb g++-2.95_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/g++-2.95_2.95.4-22_i386.deb g77-2.95-doc_2.95.4-22_all.deb to pool/main/g/gcc-2.95/g77-2.95-doc_2.95.4-22_all.deb g77-2.95_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/g77-2.95_2.95.4-22_i386.deb gcc-2.95-doc_2.95.4-22_all.deb to pool/main/g/gcc-2.95/gcc-2.95-doc_2.95.4-22_all.deb gcc-2.95_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/gcc-2.95_2.95.4-22_i386.deb gcc-2.95_2.95.4.ds15-22.diff.gz to pool/main/g/gcc-2.95/gcc-2.95_2.95.4.ds15-22.diff.gz gcc-2.95_2.95.4.ds15-22.dsc to pool/main/g/gcc-2.95/gcc-2.95_2.95.4.ds15-22.dsc gobjc-2.95_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/gobjc-2.95_2.95.4-22_i386.deb gpc-2.95-doc_2.95.4-22_all.deb to pool/main/g/gcc-2.95/gpc-2.95-doc_2.95.4-22_all.deb gpc-2.95_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/gpc-2.95_2.95.4-22_i386.deb libg++2.8.1.3-dbg_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/libg++2.8.1.3-dbg_2.95.4-22_i386.deb libg++2.8.1.3-dev_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/libg++2.8.1.3-dev_2.95.4-22_i386.deb libg++2.8.1.3-glibc2.2_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/libg++2.8.1.3-glibc2.2_2.95.4-22_i386.deb libstdc++2.10-dbg_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/libstdc++2.10-dbg_2.95.4-22_i386.deb libstdc++2.10-dev_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/libstdc++2.10-dev_2.95.4-22_i386.deb libstdc++2.10-glibc2.2_2.95.4-22_i386.deb to pool/main/g/gcc-2.95/libstdc++2.10-glibc2.2_2.95.4-22_i386.deb Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian.
Bug#237207: g++-3.3: Warning about useless casts
Package: g++-3.3
Version: 1:3.3.3-1
Severity: wishlist
It would be nice if there was an option to add a warning about
"useless" casts. Although they are not really incorrect, they
might become incorrect/inefficient as the program evolves. Ie;
struct A { int a; };
struct B : A { int b; };
void func(A *a) { ++a; }
int main(int ac, char **av)
{
A a;
B b;
func((A*)&a); // Useless cast since a already is an A.
func(static_cast(&a)); // Just as useless.
func((A*)&b); // Useless cast since b is a kind of A.
func(static_cast(&b)); // Just as useless.
return 0;
}
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.4.21-xfs
Locale: LANG=sv_SE, LC_CTYPE=sv_SE
Versions of packages g++-3.3 depends on:
ii gcc-3.3 1:3.3.3-1The GNU C compiler
ii gcc-3.3-base1:3.3.3-1The GNU Compiler Collection (base
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii libstdc++5-3.3-dev 1:3.3.3-1The GNU Standard C++ Library v3 (d
-- no debconf information
Re: GCC fails check on x86_64
Alex Perry writes: > I would appreciate any suggestions for this oddity ... please ... > > Attached message is my most recent posting to the AMD64 porting > list. GCC appears to build successfully, but checks fail as shown > in the attachment. "fails"? the test results look pretty good. anyway, please build the gcc-3.4 package from experimental for a comparision. > Any other software that makes heavy use of floating point, such as > blas or atlas, also fails to complete its selftest routines > successfully. I don't know how to tell whether the problem is the > GCC itself, a system library or a kernel corruption. is this really needed for a first base system? > I have a pure64 environment and a pure32 environment only ... at this time. > I'm in the process of setting up a cross toolchain for pure64 that runs > on pure32. Maybe ask Arnd Bergmann who added biarch support for gcc? Look at debian/rules.defs how to enable the biarch i386. Matthias
Re: GCC fails check on x86_64
Matthias Klose wrote: Alex Perry writes: Attached message is my most recent posting to the AMD64 porting list. GCC appears to build successfully, but checks fail as shown in the attachment. "fails"? the test results look pretty good. I was assuming that this aspect of the test result was a bad thing. Is it bad, or is it normal that the checks give these unexpected items ? $ grep "unexpected" gcc-3.3.test # of unexpected successes 14 # of unexpected failures4 # of unexpected failures8 # of unexpected successes 6 # of unexpected failures1 # of unexpected successes 1 # of unexpected failures1 # of unexpected successes 1 # of unexpected failures8 # of unexpected successes 6 # of unexpected failures4 # of unexpected successes 14 anyway, please build the gcc-3.4 package from experimental for a comparision. Good idea. In progress. I note in passing that some of the patches have rejects. Any other software that makes heavy use of floating point, such as blas or atlas, also fails to complete its selftest routines successfully. I don't know how to tell whether the problem is the GCC itself, a system library or a kernel corruption. is this really needed for a first base system? Nonono; I'm mentioning BLAS (and others) as (a) how I first noticed that there was a problem, and (b) an indication of what areas the symptom is affecting. I have a pure64 environment and a pure32 environment only ... at this time. I'm in the process of setting up a cross toolchain for pure64 that runs on pure32. Maybe ask Arnd Bergmann who added biarch support for gcc? Look at debian/rules.defs how to enable the biarch i386. Thank you, I will do.
Cross-compiler patch for 3.4
> And maybe Nikita could update the cross packaging bits? Hello. Seems that at last I've got something that works - at least it does the same that my patches for gcc-3.3 did. Patch (against gcc 3.4 source package downloaded 2 weeks ago from from http://people.debian.org/~doko/gcc-3.4/) is attached. Since 3.3, there are some upstream changes related to cross-compiler build. Upstream Makefile in gcc 3.4 uses $program_transform_name to append target-alias to tool names (e.g. to convert "gcc" to "arm-linux-gcc"). In gcc 3.3 this conversion was explicit. Currently, if either of --program-prefix, --program-suffix or --program-transfrom-name is passed to gcc 3.4's configure, it fails to set up proper $program_transform_name, and target-alias prefix is not added to tool names. I workarounded that by adding explicit --program-prefix to configure call from debian/rules2 Once I did that, I faced a bug in gcc's configure.in (propagated to configure) - it fails to handle properly situation when both --program-prefix and --program-suffix are given. The bug is trivial to fix, and is fixed in debian/patches/cross-configure.dpatch, but since configure is not recreated from configure.in during debian package build, I have to patch configure directly, which is definitly a bad idea. Another problem is that gcc 3.4's build system seems to assume that binutils are built together with (cross-)gcc, so same $program_transform_name is applied to "nm", "ar" and similar - instead of using autoconf-detected available tools. Of course "arm-linux-nm-3.4" is not available, so build fails. There is explicit code in configure.in (and configure) that overwrites detected tool names and replaces them with not working ones. So I fixed that also by disabling that code (after all, we are not gouing to build binutils together with gcc, are we?). This is second part of cross-configure.dpatch, and again it modifies configure directly, which is bad. After finding and fixing the above and making some technical changes in debian/rules* and debian/rules.d/*cross*, I was able to build cross-compiler and cross-library debs: libgcc1-arm-cross_3.4-0pre1_all.deb gcc-3.4-arm-linux_3.4-0pre1_i386.deb g++-3.4-arm-linux_3.4-0pre1_i386.deb libstdc++6-arm-cross_3.4-0pre1_all.deb libstdc++6-dev-arm-cross_3.4-0pre1_all.deb libstdc++6-dbg-arm-cross_3.4-0pre1_all.deb libstdc++6-pic-arm-cross_3.4-0pre1_all.deb Both arm-linux-gcc-3.4 and arm-linux-g++-3.4, installed on my x86 host (together with dpkg-cross'ed glibc), create valid binaries that work on my Ipaq. Several more notes: - There is a typo in debian/control related to move to non-epoched versions: gcc-3.4 depends on libgcc1 (>= 3.4), but it should depend on libgcc1 (>= 1:3.4) - libgcc1 version is still epoched. I've fixed this in debian/control.m4, but not in debian/control (later seems to be always re-created during package build). - The change in README.cross mentions a way to build cross-binutils from binutils package source, and is also appropriate to gcc-3.3 packages. - Installing both 3.3 and 3.4 cross compiler packages on the same host works; update-alternatives is used to manage target-alias-gcc and target-alias-g++ links. Priorities for alternatives are currently hardcoded in debian/gcc-cross.postinst both in gcc-3.3 and gcc-3.4 source packages. Currently, 3.3 is preferred by default. I hope to hear some feedback to know what to do next. Nikita cross.diff.bz2 Description: BZip2 compressed data
[Bug target/13877] [3.3 regression] miscompilation with -O -funroll-loops on powerpc
--- Additional Comments From wilson at gcc dot gnu dot org 2004-03-10 23:43 --- I can reproduce the problem with gcc-3_3-branch on powerpc-darwin. I can also reproduce the problem with current sources using -O -fold-unroll-loops. The problem is a bad interaction between the old loop unroller and doloop. The loop in question executes 6 times. The initial value of the iterator is 0. The final value is pseudo-reg 118 which holds the value 6 at run time. The old loop unrolling preconditions the loop and then unrolls it four times. Now, at the LOOP_BEG note, the initial value is now 2 at runtime, or (mod (reg 118) (const_int 4)). The loop_info->initial_value field is not changed. Then doloop_optimize runs, and tries to do some of the same calculations as unroll.c. It decides that the loop will run (reg 118) times (i.e. 6 times), because that is final_value minus the initial_value. It sees that the loop increments the iterator by 4 each loop iteration, and thus the loop must execute ceil (r118 / 4) * 4, which at run time means 8. And now we are hosed, as doloop proceeds to make incorrect transformations based on the 8 number. One possible way to fix this is to clear loop_info->initial_value after preconditioning the loop, to indicate that the initial value is now unknown. This disables the doloop optimization, avoiding the bug. Putting the (mod...) expression here seems less useful, as that might confuse other loop optimizers. An even better solution would be to pass enough info from unroll_loops to do_loop_optimize so that the optimization can still occur. I haven't looked at how to do this. This problem does not occur with the new loop unroller because it is a separate pass from loop.c, and does not use the loop_info structure. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-03-10 23:43:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13877 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Bug target/13877] [3.3 regression] miscompilation with -O -funroll-loops on powerpc
--- Additional Comments From wilson at gcc dot gnu dot org 2004-03-10 23:49 --- Created an attachment (id=5894) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=5894&action=view) clear loop_info->initial_value is loop preconditioned This fixes the problem by disabling doloop when it would interfere with loop unrolling. This works for the testcase, but otherwise has not been tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13877 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Results for 3.3.3 (Debian 20040306) testsuite on m68k-unknown-linux-gnu
LAST_UPDATED: Native configuration is m68k-unknown-linux-gnu === g77 tests === Running target unix === g77 Summary === # of expected passes1720 # of unsupported tests 8 /build/buildd/gcc-3.3-3.3.3ds5/build/gcc/testsuite/../g77 version 3.3.3 (Debian 20040306) === gcc tests === Running target unix WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c, -O1 WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c, -O2 WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c, -O3 -fomit-frame-pointer WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c, -O3 -g WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c, -Os FAIL: gcc.c-torture/execute/20020418-1.c execution, -O2 FAIL: gcc.c-torture/execute/20020418-1.c execution, -Os FAIL: gcc.c-torture/execute/loop-2f.c execution, -O0 FAIL: gcc.c-torture/execute/loop-2f.c execution, -O1 FAIL: gcc.c-torture/execute/loop-2f.c execution, -O2 FAIL: gcc.c-torture/execute/loop-2f.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/loop-2f.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/loop-2f.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/loop-2f.c execution, -O3 -g FAIL: gcc.c-torture/execute/loop-2f.c execution, -Os FAIL: gcc.c-torture/execute/loop-2g.c execution, -O0 FAIL: gcc.c-torture/execute/loop-2g.c execution, -O1 FAIL: gcc.c-torture/execute/loop-2g.c execution, -O2 FAIL: gcc.c-torture/execute/loop-2g.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/loop-2g.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/loop-2g.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/loop-2g.c execution, -O3 -g FAIL: gcc.c-torture/execute/loop-2g.c execution, -Os FAIL: gcc.c-torture/execute/string-opt-10.c execution, -O0 FAIL: gcc.c-torture/execute/string-opt-10.c execution, -O1 FAIL: gcc.c-torture/execute/string-opt-10.c execution, -O2 FAIL: gcc.c-torture/execute/string-opt-10.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/string-opt-10.c execution, -O3 -g FAIL: gcc.c-torture/execute/string-opt-10.c execution, -Os FAIL: gcc.c-torture/execute/string-opt-17.c execution, -O1 FAIL: gcc.c-torture/execute/string-opt-17.c execution, -O2 FAIL: gcc.c-torture/execute/string-opt-17.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/string-opt-17.c execution, -O3 -g FAIL: gcc.c-torture/execute/string-opt-17.c execution, -Os FAIL: gcc.c-torture/execute/string-opt-9.c execution, -O0 FAIL: gcc.c-torture/execute/string-opt-9.c execution, -O1 FAIL: gcc.c-torture/execute/string-opt-9.c execution, -O2 FAIL: gcc.c-torture/execute/string-opt-9.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/string-opt-9.c execution, -O3 -g FAIL: gcc.c-torture/execute/string-opt-9.c execution, -Os FAIL: gcc.dg/20020312-2.c (test for excess errors) WARNING: gcc.dg/20020312-2.c compilation failed to produce executable FAIL: gcc.dg/bitfld-3.c execution test FAIL: gcc.dg/bitfld-4.c execution test XPASS: gcc.dg/c99-flex-array-4.c sizeof != offsetof (test for bogus messages, line 24) FAIL: gcc.dg/duff-2.c (test for excess errors) FAIL: gcc.dg/pack-test-1.c (test for excess errors) FAIL: gcc.dg/uninit-A.c uninitialized variable warning (test for bogus messages, line 52) FAIL: gcc.dg/uninit-A.c uninitialized variable warning (test for bogus messages, line 53) FAIL: gcc.dg/weak/typeof-2.c scan-assembler baz3.*baz3.*baz3.*baz3.*baz3.*baz3 === gcc Summary === # of expected passes20999 # of unexpected failures48 # of unexpected successes 1 # of expected failures 68 # of unsupported tests 194 /build/buildd/gcc-3.3-3.3.3ds5/build/gcc/xgcc version 3.3.3 (Debian 20040306) === g++ tests === Running target unix FAIL: g++.dg/abi/bitfield4.C execution test FAIL: g++.dg/abi/empty6.C (test for warnings, line 6) FAIL: g++.eh/spec3.C Execution test FAIL: g++.eh/spec4.C Execution test XPASS: g++.other/init5.C Execution test === g++ Summary === # of expected passes8153 # of unexpected failures4 # of unexpected successes 1 # of expected failures 93 # of untested testcases 23 # of unsupported tests 30 /build/buildd/gcc-3.3-3.3.3ds5/build/gcc/testsuite/../g++ version 3.3.3 (Debian 20040306) === objc tests === Running target unix === objc Summary === # of expected passes1166 /build/buildd/gcc-3.3-3.3.3ds5/build/gcc/xgcc version 3.3.3 (Debian 20040306) === treelang tests === Running target unix === treelang Summary === # o
(Bw) (c-heap) (vi)-(agra)
w Cia-lis Is A New ImpotenceDrug. n. B v Cia-lis is in a class of medications known as PDE5-IInhibittors, which are used to treat MaleImp-otence. a Up to 86% of patients WhoTakeCialis experience an improvement in their e-rections.K. Cia-lisActs in the SameWay As Vi-agra.E. w w YouGain E-rections faster and easier with Cialis.o j T WhyWe??? C. H - NoPrescriptionRequired v. D - FreeConsultations q. w - WorldwideShipping m. c - SatisfactionGuaranteed W. Z - MoneyBackGuarantee Z. http://15.smart-pharmacy.com/15/
Re: GCC fails check on x86_64
Matthias Klose wrote: anyway, please build the gcc-3.4 package from experimental for a comparision. Alex Perry wrote: > Good idea. In progress. > I note in passing that some of the patches have rejects. $ grep unexpected gcc-3.4.log # of unexpected failures8 # of unexpected successes 1 /bin/sh: -c: line 1: syntax error near unexpected token `;;' # of unexpected successes 1 # of unexpected failures37 # of unexpected successes 1 # of unexpected failures8 # of unexpected failures37 # of unexpected successes 1
cpp-2.95_2.95.4-7_i386.deb
Hi, I am looking for the source code for cpp-2.95_2.95.4-7_i386.deb, but I could only find the 2.95.4-11woody1 version on the debian site. Is there an archive where I can get the 2.95.4-7 version? Thanks! David Fu.
