Your message dated Wed, 20 Jul 2005 11:22:40 +0200 with message-id <[EMAIL PROTECTED]> and subject line [fixed in 3.3] gcc 3.0.4 generates bad code on Debian 3.0/PARISC has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 18 Jan 2004 22:28:48 +0000 >From [EMAIL PROTECTED] Sun Jan 18 14:28:48 2004 Return-path: <[EMAIL PROTECTED]> Received: from willy.net1.nerim.net [62.212.114.60] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1AiLPT-0000y8-00; Sun, 18 Jan 2004 14:28:47 -0800 Date: Sun, 18 Jan 2004 23:28:44 +0100 From: Willy Tarreau <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: gcc 3.0.4 generates bad code on Debian 3.0/PARISC Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_01_14 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-4.4 required=4.0 tests=HAS_PACKAGE,LARGE_HEX autolearn=no version=2.60-bugs.debian.org_2004_01_14 X-Spam-Level: Package: gcc Version: 2:3.0.4-5 Kernel: Linux hp 2.4.24-pa0 #1 Sun Jan 11 18:48:21 CET 2004 parisc unknown glibc: Version: 2.2.5-11.5 GCC 3.0.4 included in Debian 3.0 generates bad code on PARISC platform. The original apache 1.3.26 distributed in this port returns lines full of zeroes in the size field of the files between 1 and 100 MB : linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 0.0000000000000000000000000000000000000000000000000000M patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 -0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000M CONTENTS-2.4.20-wt17 08-Jun-2003 10:52 18k ... and so on. So I have recompiled 1.3.29 from sources with gcc-3.0.4, and the problem was exactly the same. Digging through the code, I discovered that for exactly these files, apache uses a floating point representation for the size, and it calls ap_rprintf() which is sort of an sprintf(), with (size/1048576.0) as an argument, and "%4.1fM" as the format string. Replacing the format with "%4eM" gave me something interesting : linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 8.417643e-53M patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 1.284430e-57M CONTENTS-2.4.20-wt17 08-Jun-2003 10:52 18k I've read the complete implementation of ap_rprintf(), and it seems correct to me. But some double arguments are passed as va_args at several places. So I thought that it could be possible that gcc does not handle this very well. Then I recompiled only util_script.c and ap_snprintf.c with gcc-3.3.2, not changing anything else, and apache now reports correct sizes : linux-2.4.20-wt17.tar.bz2 08-Jun-2003 11:05 30.1M patch-2.4.20-to-2.4.20-wt17.bz2 08-Jun-2003 11:04 7.2M CONTENTS-2.4.20-wt17 08-Jun-2003 10:52 18k Now I've found that it's very easy to reproduce. Consider this trivial program : #include <stdio.h> #include <stdlib.h> main() { printf("%4.1f\n", 1.23456); } Now, test it : # gcc -O2 -o fp-test fp-test.c # ./fp-test 0.0 # gcc -O1 -o fp-test fp-test.c # ./fp-test 1.2 # gcc-3.3.2-parisc -O2 -o fp-test fp-test.c # ./fp-test 1.2 # gcc -v Reading specs from /usr/lib/gcc-lib/hppa-linux/3.0.4/specs Configured with: ../src/configure -v --enable-languages=c,c++,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --with-cpp-install-dir=bin hppa-linux Thread model: posix gcc version 3.0.4 # gcc-3.3.2-parisc -v Reading specs from /usr/lib/gcc-lib/hppa1.1-hp-linux-gnu/3.3.2/specs Configured with: ../gcc-3.3.2/configure --prefix=/usr --with-gnu-ld --with-gnu-as --host=hppa1.1-hp-linux-gnu --target=hppa1.1-hp-linux-gnu --with-cpu=7100LC --enable-languages=c,c++ --disable-nls --disable-locale --enable-shared --enable-target-optspace --enable-version-specific-runtime-libs --program-suffix=-3.3.2-parisc --enable-threads Thread model: posix gcc version 3.3.2 So it seems that the work-around simply is to switch back to -O1. Unfortunately, I tried about 20 -fno-XXX with -O2 to find the culprit, but I couldn't. And I don't remember how I can dump the -O1 and -O2 equivalents. I hope I didn't forget anything. At the moment, I don't know if there are packages other than apache which have been affected by this bug. Regards, Willy --------------------------------------- Received: (at 228421-done) by bugs.debian.org; 20 Jul 2005 09:22:43 +0000 >From [EMAIL PROTECTED] Wed Jul 20 02:22:43 2005 Return-path: <[EMAIL PROTECTED]> Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1DvAmp-0002St-00; Wed, 20 Jul 2005 02:22:43 -0700 Received: from mailhost.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.17.13]) by mail.cs.tu-berlin.de (8.9.3p2/8.9.3) with ESMTP id LAA09758 for <[EMAIL PROTECTED]>; Wed, 20 Jul 2005 11:22:41 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mailhost.cs.tu-berlin.de (Postfix) with ESMTP id C341CF211 for <[EMAIL PROTECTED]>; Wed, 20 Jul 2005 11:22:40 +0200 (MEST) Received: from mailhost.cs.tu-berlin.de ([127.0.0.1]) by localhost (bueno [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id 22534-48 for <[EMAIL PROTECTED]>; Wed, 20 Jul 2005 11:22:40 +0200 (MEST) 14074 Received: from bolero.cs.tu-berlin.de (bolero.cs.tu-berlin.de [130.149.19.1]) by mailhost.cs.tu-berlin.de (Postfix) with ESMTP for <[EMAIL PROTECTED]>; Wed, 20 Jul 2005 11:22:40 +0200 (MEST) Received: (from [EMAIL PROTECTED]) by bolero.cs.tu-berlin.de (8.12.10+Sun/8.12.8/Submit) id j6K9MeTs024477; Wed, 20 Jul 2005 11:22:40 +0200 (MEST) From: Matthias Klose <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <[EMAIL PROTECTED]> Date: Wed, 20 Jul 2005 11:22:40 +0200 To: [EMAIL PROTECTED] Subject: Re: [fixed in 3.3] gcc 3.0.4 generates bad code on Debian 3.0/PARISC X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Virus-Scanned: by amavisd-new at cs.tu-berlin.de Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-CrossAssassin-Score: 2 Package: gcc Version: 4:3.3 closing this report, seen only in oldstable/woody, fixed in current stable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]