Re: Bug#121282: On i386, gcc-3.0 allows $ in indentifiers but not the asm
> Step 3: Start making the case upstream with the gcc SC, or at least try. > As you've pointed out, it takes forever to get rid of an option > or change it in gcc, which is understandable in a way, so why not > start sooner than later, right? :-) Exactly. > The latter is ugly code, IMO, but at least gas won't have a problem > with it on x86 and could be considered acceptable by some people's > definitions (regarding the $b case, though...if gas won't let it > through on linux, I see no redeeming value for making that case a > warning only situation...at least as far as we are > concerned...upstream is another matter altogether). Agreed. Martin
Re: C++ Exception handlin on mips [was Re: Mozilla...]
> Ugh, yep. Recompiling the dependencies also with the current toolchain > should fix this, correct? I'm not saying to do it, but it would be an > interesting experiment if all else fails (read: weapon of last resort). I think there are still problems compiling glibc with gcc 3; glibc will claim to export symbols from libgcc, when it really can't (since the symbols in libgcc_s won't be incorporated into glibc). I believe there are patches circulating to solve this problem (and also deal with the issue that libc depends on libgcc_s). Regards, Martin
Re: C++ Exception handlin on mips [was Re: Mozilla...]
On Wed, 28 Nov 2001, Martin v. Loewis wrote: > I think there are still problems compiling glibc with gcc 3; glibc > will claim to export symbols from libgcc, when it really can't (since > the symbols in libgcc_s won't be incorporated into glibc). I believe > there are patches circulating to solve this problem (and also deal > with the issue that libc depends on libgcc_s). That wouldn't surprise me...especially after living through the whole libc_nonshared issue :-) That would definitely hose EH in some instances (as you've already noted). C
Re: Bug#121282: On i386, gcc-3.0 allows $ in indentifiers but not the asm
On Wed, Nov 28, 2001 at 06:59:27AM +0100, Martin v. Loewis wrote:
> > I could have sworn it was NTFS...
> >
> > util.h:
> > typedef enum {
> > FILE_$Mft = 0,
> > FILE_$MftMirr = 1,
>
> What kernel version? In 2.4.10, this reads
>
> typedef enum {
> FILE_Mft= 0,
> FILE_MftMirr= 1,
> FILE_LogFile= 2,
> ...
I stand corrected, then. It's been like that for at least most of 2.4
up through 2.4.7, which one of my boards is still running.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
Processed: reassign 120333 to g++
Processing commands for [EMAIL PROTECTED]: > reassign 120333 g++ Bug#120333: menu: update-menus gets Bus Error on mips Bug reassigned from package `menu' to `g++'. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: ecawave fails to build on alpha
Processing commands for [EMAIL PROTECTED]: > reassign 118814 g++-2.95 Bug#118814: ecawave: compile fails with internal compiler error on alpha Bug reassigned from package `ecawave' to `g++-2.95'. > severity 118814 normal Bug#118814: ecawave: compile fails with internal compiler error on alpha Severity set to `normal'. > retitle 118814 ecawave: compile fails with internal compiler error with > g++-2.95 on alpha. Bug#118814: ecawave: compile fails with internal compiler error on alpha Changed Bug title. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: gcc 2.95, not 2.96
Processing commands for [EMAIL PROTECTED]: > reassign 115978 libstdc++2.10 Bug#115978: stringstream adds extra characters at the end (forwarded from libstdc++2.10-dev) Bug reassigned from package `libstdc++2.10-glibc2.2' to `libstdc++2.10'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#101223: marked as done (Undefined reference to 'cout')
Your message dated Wed, 28 Nov 2001 17:59:20 +
with message-id <[EMAIL PROTECTED]>
and subject line works for me
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; 17 Jun 2001 19:34:46 +
>From [EMAIL PROTECTED] Sun Jun 17 14:34:46 2001
Return-path: <[EMAIL PROTECTED]>
Received: from (debian-home) [:::12.44.140.126]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15BiJp-0006TU-00; Sun, 17 Jun 2001 14:34:46 -0500
Received: from gbsadler by debian-home with local (Exim 3.22 #1 (Debian))
id 15BiJp-0008SV-00
for <[EMAIL PROTECTED]>; Sun, 17 Jun 2001 14:34:45 -0500
Date: Sun, 17 Jun 2001 14:34:45 -0500
From: Gordon Sadler <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: Undefined reference to 'cout'
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.18i
X-Reportbug-Version: 1.17
Sender: Gordon Sadler <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Package: g++-2.95
Version: 1:2.95.4-0.010604
Severity: important
I have no idea when this started. Perhaps a packaging bug?
If you compile the attached 'hello' program:
g++ -v bar.cpp
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20010604 (Debian prerelease)
/usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2
-D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__
-D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix)
-D__EXCEPTIONS -Acpu(i386)
-Amachine(i386) -Di386 -D__i386 -D__i386__ bar.cpp /tmp/ccf6bars.ii
GNU CPP version 2.95.4 20010604 (Debian prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
/usr/lib/gcc-lib/i386-linux/2.95.4/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
End of omitted list.
/usr/lib/gcc-lib/i386-linux/2.95.4/cc1plus /tmp/ccf6bars.ii -quiet -dumpbase
bar.cc -version -o /tmp/ccqPnv88.s
GNU C++ version 2.95.4 20010604 (Debian prerelease) (i386-linux) compiled by
GNU C version 2.95.4 20010604 (Debian prerelease).
as -V -Qy -o /tmp/ccBAeHI5.o /tmp/ccqPnv88.s
GNU assembler version 2.11.90.0.7 (i386-linux) using BFD version 2.11.90.0.7
/usr/lib/gcc-lib/i386-linux/2.95.4/collect2 -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o -L/usr/local/kde2.2/lib
-L/usr/local/qt2.3/lib -L/usr/local/lib -L/usr/lib/gcc-lib/i386-linux/2.95.4
/tmp/ccBAeHI5.o -lstdc++ -lm -lgcc -lc -lgcc
/usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o /usr/lib/crtn.o
/tmp/ccBAeHI5.o: In function `main':
/tmp/ccBAeHI5.o(.text+0xf): undefined reference to `cout'
/tmp/ccBAeHI5.o(.text+0x14): undefined reference to `ostream::operator<<(char
const *)'
collect2: ld returned 1 exit status
I've tried different versions (using namespace std, std::cout, cout)
None of them will link here, same error for all. When compiled with
g++-3.0 I have no problems.
*** bar.cpp
#include
int main ()
{
std::cout << "hello ...\n";
return 0;
}
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux debian-home 2.2.19 #1 Sat May 19 16:25:04 CDT 2001 i686
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages g++-2.95 depends on:
ii g++1:2.95.4-1The GNU C++ compiler.
ii gcc-2.95 1:2.95.4-0.010604 The GNU C compiler.
ii libc6 2.2.3-6 GNU C Library: Shared libraries an
ii libstdc++2.10-dev 1:2.95.4-0.010604 The GNU stdc++ library (developmen
--
Gordon Sadler
---
Received: (at 101223-done) by bugs.debian.org; 28 Nov 2001 17:59:21 +
>From [EMAIL PROTECTED] Wed Nov 28 11:59:21 2001
Return-path: <[EMAIL PROTECTED]>
Received: from parcelfarce.linux.theplanet.co.uk (www.linux.org.uk)
[195.92.249.252] (exim)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 1698zR-0006vG-00; Wed, 28 Nov 2001 11:59:21 -0600
Received: from willy by www.linux.org.uk with local (Exim 3.33 #5)
id 1698zQ-0004gz-00; Wed, 28 Nov 2001 17:59:20 +
Date: Wed, 28 Nov 2001 17:59:20 +
From:
Processed: gcc 2.95, not 2.96
Processing commands for [EMAIL PROTECTED]: > reassign 94955 libstdc++2.10 Bug#94955: Linking with libstdc++ changes behavior of a program (which does not require libstdc++) Bug reassigned from package `libstdc++2.10-glibc2.2' to `libstdc++2.10'. > reassign 52382 libstdc++2.10 Bug#52382: [fixed with libstdc++-v3] setw is ignored for strings output Bug#76645: [fixed with libstdc++-v3] setw & ios::width fails with libstdc++2.10-glibc2.2 Bug reassigned from package `libstdc++2.10-glibc2.2' to `libstdc++2.10'. > reassign 76645 libstdc++2.10 Bug#76645: [fixed with libstdc++-v3] setw & ios::width fails with libstdc++2.10-glibc2.2 Bug#52382: [fixed with libstdc++-v3] setw is ignored for strings output Bug reassigned from package `libstdc++2.10' to `libstdc++2.10'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#116823: marked as done (Debian's g++-3.0 forgets to generate some code.)
Your message dated Wed, 28 Nov 2001 18:24:45 +
with message-id <[EMAIL PROTECTED]>
and subject line submitter requested close
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; 23 Oct 2001 19:37:36 +
>From [EMAIL PROTECTED] Tue Oct 23 14:37:36 2001
Return-path: <[EMAIL PROTECTED]>
Received: from higgs.physik.uni-mainz.de [134.93.128.134] (root)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15w7Ml-0004wB-00; Tue, 23 Oct 2001 14:37:35 -0500
Received: from localhost ([EMAIL PROTECTED])
by higgs.physik.uni-mainz.de (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP
id VAA07176
for <[EMAIL PROTECTED]>; Tue, 23 Oct 2001 21:37:33 +0200
X-Authentication-Warning: higgs.physik.uni-mainz.de: kreckel owned process
doing -bs
Date: Tue, 23 Oct 2001 21:37:33 +0200 (CEST)
From: "Richard B. Kreckel" <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Debian's g++-3.0 forgets to generate some code.
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
Package: g++-3.0
Version: 1:3.0.2-0pre011014
Severity: important
Summary: It seems like some bug crept into Debian's gcc-3.0. The bug does
not seem to be present upstream. This bug renders the CLN package
unlinkable with our compiler.
The following piece of code is extracted from CLN's PROVIDE/REQUIRE
mechanism for setting up global objects:
extern "C" void module__prin_globals__firstglobalfun () {}
extern "C" void module__prin_globals__ctorend (void);
extern "C" void module__prin_globals__dtorend (void);
__asm__("\t.globl _GLOBAL__I_module__prin_globals__firstglobalfun");
__asm__("\t.globl _GLOBAL__D_module__prin_globals__firstglobalfun");
static int module__prin_globals__counter;
struct module__prin_globals__controller {
inline module__prin_globals__controller ()
{
if (module__prin_globals__counter++){
__asm__ ("jmp %*%0" : : "rm" ((void*)(
module__prin_globals__ctorend ))) ;
}
}
inline ~module__prin_globals__controller ()
{
__asm__ ("\n" "" "module__" "prin_globals" "__dtorend" ":")
;
}
};
static module__prin_globals__controller module__prin_globals__ctordummy;
When compiled with `g++-3.0 -O -c' the resulting .o file starts with
U _GLOBAL__D_module__prin_globals__firstglobalfun
0058 T _GLOBAL__I_module__prin_globals__firstglobalfun
Rather, there should be a text section for `_GLOBAL__D_module_...' as
well, in the following fashion:
0070 T _GLOBAL__D_module__prin_globals__firstglobalfun
0050 T _GLOBAL__I_module__prin_globals__firstglobalfun
I am able to generate the above (correct) symbols with either RedHat's
`g++3' or with the snapshot `gcc-3.0.2-20011014' bootstrapped on a Woody
system with no configure-options other than --prefix. The erroneously
missing symbols can also be reproducsed with Debian's version
1:3.0.2-0pre010922. Also, analyzing the output directly with `cc1plus',
one finds that we cannot blame binutils. The code is simply not generated
with Debian's compiler:
$ /usr/lib/gcc-lib/i386-linux/3.0.2/cc1plus -quiet -dumpbase foo.cpp -O
-version -o foo.s foo.cpp
GNU CPP version 3.0.2 20011014 (Debian prerelease) (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0.2 20011014 (Debian prerelease) (i386-linux)
compiled by GNU C version 3.0.2 20011014 (Debian prerelease).
$ grep _D_ foo.s # WRONG
.globl _GLOBAL__D_module__prin_globals__firstglobalfun
$ grep _I_ foo.s # okay
.globl _GLOBAL__I_module__prin_globals__firstglobalfun
.type _GLOBAL__I_module__prin_globals__firstglobalfun,@function
_GLOBAL__I_module__prin_globals__firstglobalfun:
.size
_GLOBAL__I_module__prin_globals__firstglobalfun,.Lfe4-_GLOBAL__I_module__prin_globals__firstglobalfun
.long _GLOBAL__I_module__prin_globals__firstglobalfun
Whereas it is generated fine with the hand-bootstrapped compiler:
$
/home/kreckel/projects/gcc-3.0.2-20011014/lib/gcc-lib/i686-pc-linux-gnu/3.0.2/cc1plus
-quiet -dumpbase foo.cpp -O -version -o foo.s foo.cpp
GNU CPP version 3.0.2 20011014 (prerelease) (cpplib) (i386 Linux/ELF)
Bug#101371: marked as done ([PR libstdc++/3551] error in auto_ptr implementation)
Your message dated Wed, 28 Nov 2001 18:30:48 +
with message-id <[EMAIL PROTECTED]>
and subject line upstream closed bug
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 Jun 2001 21:06:00 +
>From [EMAIL PROTECTED] Mon Jun 18 16:06:00 2001
Return-path: <[EMAIL PROTECTED]>
Received: from klecker.debian.org [:::198.186.203.20]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15C6Dg-IU-00; Mon, 18 Jun 2001 16:06:00 -0500
Received: from morsig.xs4all.nl (fog.mors.wiggy.net) [213.84.43.14]
by klecker.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15C6De-0001PP-00; Mon, 18 Jun 2001 14:05:59 -0700
Received: from fog.mors.wiggy.net (IDENT:ORVM5jjQbP3e/[EMAIL PROTECTED]
[127.0.0.1])
by localhost (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10) with
ESMTP id f5IL3U7q026161;
Mon, 18 Jun 2001 23:03:30 +0200
Received: (from [EMAIL PROTECTED])
by fog.mors.wiggy.net (8.12.0.Beta10/8.12.0.Beta10/Debian
8.12.0.Beta10) id f5IL3SD1026158;
Mon, 18 Jun 2001 23:03:28 +0200
Message-Id: <[EMAIL PROTECTED]>
From: Wichert Akkerman <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: error in auto_ptr implementation
X-Reportbug-Version: 1.18
X-Mailer: reportbug 1.18
Date: Mon, 18 Jun 2001 23:03:28 +0200
Delivered-To: [EMAIL PROTECTED]
Package: g++-3.0
Version: 1:3.0-0pre010613
Severity: normal
Tags: sid
The code below does not compile with g++ 3.0, but it seems correct
judging by my C++ books.
Wichert.
#include
#include
using namespace std;
int main(int, char**) {
auto_ptr api(new int(5));
list > lapi;
lapi.push_back(api);
return 0;
}
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux fog 2.2.19+ext3+ipsec #1 Thu Apr 12 17:22:37 CEST 2001 i686
Locale: LANG=en_GB.ISO-8859-1, LC_CTYPE=en_GB.ISO-8859-1
Versions of packages g++-3.0 depends on:
ii gcc-3.0 1:3.0-0pre010613 The GNU C compiler.
ii gcc-3.0-base1:3.0-0pre010613 The GNU compiler collection (base
ii libc6 2.2.3-6 GNU C Library: Shared libraries an
ii libstdc++3-dev 1:3.0-0pre010613 The GNU stdc++ library version 3 (
---
Received: (at 101371-close) by bugs.debian.org; 28 Nov 2001 18:30:49 +
>From [EMAIL PROTECTED] Wed Nov 28 12:30:49 2001
Return-path: <[EMAIL PROTECTED]>
Received: from parcelfarce.linux.theplanet.co.uk (www.linux.org.uk)
[195.92.249.252] (exim)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 1699Tt-Yr-00; Wed, 28 Nov 2001 12:30:49 -0600
Received: from willy by www.linux.org.uk with local (Exim 3.33 #5)
id 1699Ts-0005Qq-00
for [EMAIL PROTECTED]; Wed, 28 Nov 2001 18:30:48 +
Date: Wed, 28 Nov 2001 18:30:48 +
From: Matthew Wilcox <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: upstream closed bug
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
upstream decided this wasn't a bug, so i'm closing the associated debian bug.
--
Revolutions do not require corporate support.
Bug#114795: marked as done (gcc-3.0: Weird behaviour with -I/usr/include)
Your message dated Wed, 28 Nov 2001 18:28:06 + with message-id <[EMAIL PROTECTED]> and subject line not a bug 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; 7 Oct 2001 22:25:54 + >From [EMAIL PROTECTED] Sun Oct 07 17:25:54 2001 Return-path: <[EMAIL PROTECTED]> Received: from b55a8.pppool.de (atterer.net) [213.7.85.168] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15qMMr-00051k-00; Sun, 07 Oct 2001 17:25:54 -0500 Received: from richard by atterer.net with local (Exim 3.32 #1 (Debian)) id 15qJ75-0005cz-00; Sun, 07 Oct 2001 20:57:23 +0200 From: Richard Atterer <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: gcc-3.0: Weird behaviour with -I/usr/include X-Reportbug-Version: 1.28 X-Mailer: reportbug 1.28 Date: Sun, 07 Oct 2001 20:57:22 +0200 Message-Id: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Package: gcc-3.0 Version: 1:3.0.1-0pre010811 Severity: normal Hello, I encountered some very strange behaviour when using -I/usr/include. Obviously, it doesn't make much sense to supply this switch on the command line, but in any case gcc's reaction is wrong. (I came across this because libwww-config happens to include -I/usr/include in its --cflags output.) > echo '#include ' >x.cc > touch string.hh > g++-3.0 -I/usr/include -c x.cc -o x.o In file included from /usr/include/g++-v3/bits/char_traits.h:39, from /usr/include/g++-v3/bits/std_string.h:41, from /usr/include/g++-v3/string:31, from x.cc:1: /usr/include/g++-v3/bits/std_cstring.h:40:25: string.h: No such file or directory In file included from /usr/include/g++-v3/bits/char_traits.h:39, from /usr/include/g++-v3/bits/std_string.h:41, from /usr/include/g++-v3/string:31, from x.cc:1: /usr/include/g++-v3/bits/std_cstring.h:68: `memcpy' not declared /usr/include/g++-v3/bits/std_cstring.h:69: `memmove' not declared /usr/include/g++-v3/bits/std_cstring.h:70: `strcpy' not declared /usr/include/g++-v3/bits/std_cstring.h:71: `strncpy' not declared /usr/include/g++-v3/bits/std_cstring.h:72: `strcat' not declared /usr/include/g++-v3/bits/std_cstring.h:73: `strncat' not declared [...] -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux elessar 2.2.19 #1 Mon May 21 19:42:05 CEST 2001 i686 Locale: LANG=C, LC_CTYPE=de_DE Versions of packages gcc-3.0 depends on: ii binutils 2.11.90.0.31-1 The GNU assembler, linker and bina ii cpp-3.0 1:3.0.1-0pre010811 The GNU C preprocessor. ii gcc-3.0-base 1:3.0.1-0pre010811 The GNU Compiler Collection (base ii libc6 2.2.4-1GNU C Library: Shared libraries an ii libgcc1 1:3.0.1-0pre010811 GCC support library. --- Received: (at 114795-done) by bugs.debian.org; 28 Nov 2001 18:28:07 + >From [EMAIL PROTECTED] Wed Nov 28 12:28:07 2001 Return-path: <[EMAIL PROTECTED]> Received: from parcelfarce.linux.theplanet.co.uk (www.linux.org.uk) [195.92.249.252] (exim) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 1699RH-0008SY-00; Wed, 28 Nov 2001 12:28:07 -0600 Received: from willy by www.linux.org.uk with local (Exim 3.33 #5) id 1699RG-0005Oe-00 for [EMAIL PROTECTED]; Wed, 28 Nov 2001 18:28:06 + Date: Wed, 28 Nov 2001 18:28:06 + From: Matthew Wilcox <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: not a bug Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] upstream does not consider this to be a bug, see http://gcc.gnu.org/ml/gcc/2001-07/msg00307.html -- Revolutions do not require corporate support.
Bug#121639: libgcj2: serialization of java.util.Date is broken
Package: libgcj2
Version: 1:3.0.2-3
Severity: important
Tags: patch
Serialization of the java.util.Date class is broken in libgcj.
Although the "Date" class is correctly marked as "implements
java.io.Serializable", the actual data stored in the Date class is
marked transient! This means that the field won't actually get
serialized. Below is a patch to correct the problem. I could write a
small demonstration program to show the difference in behavior from
javac, if desired.
-- Agthorr
--- gcc-20011024/libjava/java/util/Date.java~ Tue Jan 9 01:43:39 2001
+++ gcc-20011024/libjava/java/util/Date.javaWed Nov 28 16:09:36 2001
@@ -24,7 +24,7 @@ public class Date implements java.io.Ser
{
private static final long serialVersionUID = 7523967970034938905L;
- transient private long millis;
+ private long millis;
public Date() { millis = System.currentTimeMillis(); }
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux eleutheromania 2.4.12 #1 Fri Oct 12 15:06:20 PDT 2001 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages libgcj2 depends on:
ii libc6 2.2.4-5GNU C Library: Shared libraries an
ii libgcc1 1:3.0.2-3 GCC support library.
ii zlib1g1:1.1.3-16 compression library - runtime
Bug#121636: libgcj2: ObjectInputStream.readObject() calls constructors
Package: libgcj2
Version: 1:3.0.2-3
Severity: normal
The implementation of ObjectInputStream.readObject() in this version
of libgcj calls the constructor of the serialize object it is reading.
Sun's implementation does not do this, nor (I think) did earlier
versions of libgcj. Below is a sample program which prints "foo" once
with javac, but twice with gcj/libgcj.
I found this while debugging a real program, where it was causing me
quite a bit of confusion.
-- Agthorr
import java.io.*;
class Break implements Serializable {
int x;
public Break () {
System.err.println ("foo");
}
static public void main (String [] args)
throws java.io.IOException, java.lang.ClassNotFoundException
{
ByteArrayOutputStream bufout = new ByteArrayOutputStream ();
ObjectOutputStream out = new ObjectOutputStream (bufout);
Break foo = new Break ();
foo.x = 5;
out.writeObject (foo);
byte [] bytes = bufout.toByteArray ();
ByteArrayInputStream bufin = new ByteArrayInputStream (bytes);
ObjectInputStream in = new ObjectInputStream (bufin);
in.readObject ();
}
public String toString () {return Integer.toString (x);}
}
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux eleutheromania 2.4.12 #1 Fri Oct 12 15:06:20 PDT 2001 i686
Locale: LANG=C, LC_CTYPE=
Versions of packages libgcj2 depends on:
ii libc6 2.2.4-5GNU C Library: Shared libraries an
ii libgcc1 1:3.0.2-3 GCC support library.
ii zlib1g1:1.1.3-16 compression library - runtime
Bug#121642: libstdc++3: Unable to do buffered cout (?)
Package: libstdc++3
Version: 1:3.0.2-3
Severity: normal
Hi!
I have seen an strange behaviour of libstdc++ regarding buffering of
streams; I don't know if it is my fault or the libraries fault. It
basically writes character per character whenever I do a cout <<
"something".
Given the following program:
#include
using namespace std;
int main (void)
{
cout << "Hello world!" << endl;
return 0;
}
compiled it with gcc-2.95 and gcc-3.0 (ok, g++ actually). When
compiled with gcc-2.95 and run with strace(1), I get the following:
$ g++-2.95 -Wall -O2 testout.cc -o testout
$ ./testout
Hello world!
$ strace ./testout > /dev/null
execve("./testout", ["./testout"], [/* 28 vars */]) = 0
uname({sys="Linux", node="milikk", ...}) = 0
brk(0) = 0x8049834
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=66967, ...}) = 0
old_mmap(NULL, 66967, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000
close(3)= 0
open("/usr/lib/libstdc++-libc6.2-2.so.3", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\251\1"..., 1024) =
1024
fstat64(3, {st_mode=S_IFREG|0644, st_size=291720, ...}) = 0
old_mmap(NULL, 303748, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40027000
mprotect(0x4005e000, 78468, PROT_NONE) = 0
old_mmap(0x4005e000, 69632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x36000) = 0x4005e000
old_mmap(0x4006f000, 8836, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4006f000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 I\0\000"..., 1024) =
1024
fstat64(3, {st_mode=S_IFREG|0644, st_size=134668, ...}) = 0
old_mmap(NULL, 137220, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40072000
mprotect(0x40093000, 2052, PROT_NONE) = 0
old_mmap(0x40093000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x2) = 0x40093000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0(\327\1"..., 1024) =
1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1171196, ...}) = 0
old_mmap(NULL, 1187968, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40094000
mprotect(0x401ac000, 41088, PROT_NONE) = 0
old_mmap(0x401ac000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x117000) = 0x401ac000
old_mmap(0x401b2000, 16512, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401b2000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401b7000
munmap(0x40016000, 66967) = 0
fstat64(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE, 0xb718) = -1 ENOTTY (Inappropriate ioctl for
device)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40016000
write(1, "Hello world!\n", 13) = 13
_exit(0)= ?
Note the previous-to-last line, write(1, "Hello world!\n", 13), that
is, a buffered write, as expected. However, now let's do the same with
3.0:
$ g++-3.0 -Wall -O2 testout.cc -o testout
$ ./testout
Hello world!
$ strace ./testout > /dev/null
execve("./testout", ["./testout"], [/* 28 vars */]) = 0
uname({sys="Linux", node="milikk", ...}) = 0
brk(0) = 0x804c890
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=66967, ...}) = 0
old_mmap(NULL, 66967, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000
close(3)= 0
open("/usr/lib/libstdc++.so.3", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\255"..., 1024) =
1024
fstat64(3, {st_mode=S_IFREG|0644, st_size=565536, ...}) = 0
old_mmap(NULL, 587464, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40027000
mprotect(0x4009e000, 100040, PROT_NONE) = 0
old_mmap(0x4009e000, 81920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x76000) = 0x4009e000
old_mmap(0x400b2000, 18120, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400b2000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 I\0\000"..., 1024) =
1024
fstat64(3, {st_mode=S_IFREG|0644, st_size=134668, ...}) = 0
old_mmap(NULL, 137220, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400b7000
mprotect(0x400d8000, 2052, PROT_NONE) = 0
old_mmap(0x400d8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x2) = 0x400d8000
close(3)= 0
open("/lib/libgcc_s.so.1", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\330\22"..., 1024) =
1024
fstat64(3, {st_mode=S_IFREG|0
Re: Bug#121642: libstdc++3: Unable to do buffered cout (?)
> I tried to investigate and found nothing. I was thinking maybe
> there is a switch for it or something, but found none. Anyway, by
> default, the output should be buffered, AFAIK ... and unless I am
> missing anything.
>
> Any clues?
That appears to be the implementation of the requirement that
std::cout and std::stdout are always synchronized (i.e. tied).
This is done in ios.cc
void
ios_base::Init::_S_ios_create(bool __sync)
{
int __out_bufsize = __sync ? 0 : static_cast(BUFSIZ);
int __in_bufsize = __sync ? 1 : static_cast(BUFSIZ);
In gcc 2.95, tieing stdout and cout was achieved by having the same
buffer objects. Since the ABI changed, and since the buffer is in
glibc, this isn't possilbe anymore.
Regards,
Martin
Bug#121642: libstdc++3: Unable to do buffered cout (?)
> That appears to be the implementation of the requirement that > std::cout and std::stdout are always synchronized (i.e. tied). > This is done in ios.cc > > ... > > In gcc 2.95, tieing stdout and cout was achieved by having the same > buffer objects. Since the ABI changed, and since the buffer is in > glibc, this isn't possilbe anymore. So, is the final behaviour (aka: non-buffered output) the standard behaviour? My guess is not ... if so, is there a way to fix it? Thanks :) Iñaky Pérez González -- (503) 677 6807 I do not speak for Intel Corp, opinions are my own.
