Re: G++ rejects legal code
"Martin v. Loewis" wrote:
> I think so. I fail to see the bug in your report, though. Your code is
> illegal (or, rather, ill-formed - some GNU coding style advises us not
> to claim that you are breaking the law by writing the code).
>
> > template
> > struct SGBMb : public SGBb <_TW>
> > {
> > typedef _TTWO _TWO;
> > _TWO osy;
> >
> > SGBMb <_TW, _TWO> (_TW _sy, _TWO _osy, void* _st)
> > : sy (_sy), osy (_osy), st (_st) {}
> > };
>
> The class SGBMb (i.e. all instantiations of the class template) has
> only one data member, namely osy. The members sy and st are defined in
> the base class, so they must not be mentioned in the member
> initializer of the derived class. Instead, you should write
Why only one data member? Members sy and st are public in the base class.
Initialization in the constructor body works OK. Moreover, (week argument, but)
Visual C++ compiles this OK.
> template
> struct SGBMb : public SGBb <_TW>
> {
> typedef _TTWO _TWO;
> _TWO osy;
>
> SGBMb <_TW, _TWO> (_TW _sy, _TWO _osy, void* _st)
> : SGBb<_TW>(_sy, _st), osy (_osy) {}
> };
(or initialize sy and st in {} )
Bug#108881: Wrong package version of libstdc++2.10 in testing and/or unstable?
Package: libstdc++2.10 Version: 1:2.95.2-14 We just discovered the fact that the .deb version of this package in woody/testing is 1:2.95.2-14, while both sid/unstable and potato/stable contain 1:2.95.2-13. (Visit e.g. http://packages.debian.org/cgi-bin/search_packages.pl?keywords=libstdc%2B%2B2.10&searchon=names&subword=1&version=all&release=all to see for yourself.) The file name for woody/testing's .deb file is dists/woody/main/binary-i386/base/libstdc++2.10_2.95.2-14.deb (i.e. the package pool is not used yet) which suggests this version went into woody when woody was still unstable and testing did not exist yet. We came across this inconsistency on a sid/unstable system when we found that libstdc++2.10 was the only package in /var/lib/dpkg/available that did not have a "Filename:" entry (apparently because the system has version 1:2.95.2-14 installed back from its old woody/unstable days, but the only version that is available now is 1:2.95.2-13). -- Arndt Schoenewald <[EMAIL PROTECTED]>
Re: G++ rejects legal code
> Why only one data member? Members sy and st are public in the base > class. Initialization in the constructor body works OK. Moreover, > (week argument, but) Visual C++ compiles this OK. This is explained in 12.6.2, [class.base.init]. Paragraph 1 explains the syntax for member initializers ctor-initializer: : mem-initializer-list mem-initializer-list: mem-initializer mem-initializer , mem-initializer-list mem-initializer: mem-initializer-id ( expression-list opt ) mem-initializer-id: ::opt nested-name-specifier-opt class-name identifier Then, paragraph 2 explains what "identifier" means here # Names in a mem-initializer-id are looked up in the scope of the # constructor s class and, if not found in that scope, are looked up # in the scope containing the constructor s definition. [Note: ...] # Unless the mem-initializer-id names a nonstatic data member of the # constructor's class or a direct or virtual base of that class, the # mem-initializer is ill-formed. A mem-initializer-list can # initialize a base class using any name that denotes that base class # type. So the identifier is only looked up in the scope of the class itself, not in any base classes; it must name a data member or a base class. In the body of the constructor, it is not initialization anymore - it is assignment. Inside a method, name lookup will find member names of the base class. Please note that specifying an initialization in a derived class would be extremely confusing. In C++, each object is initialized (constructed) only once. Now, each constructor first calls the base class constructor. The base class constructor, in turn, will initialize all members. Now, in the derived class, you want to initialize the member again??? I recommend to study a book on C++. Regards, Martin
Bug#101732: [rodrigc@gcc.gnu.org] Re: optimization/3279: internal error at compiling a c++ source file
Hi, I tested again with ii g++-3.0 3.0.1-0pre010811The GNU C++ compiler. and the bug is fixed. Thanks ! --- Begin Message --- Synopsis: internal error at compiling a c++ source file State-Changed-From-To: open->closed State-Changed-By: rodrigc State-Changed-When: Sun Aug 12 11:09:38 2001 State-Changed-Why: Fixed in gcc 3.0.1 in CVS. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3279&database=gcc --- End Message --- -- Laurent.
Bug#101732: marked as done ([PR optimization/3315] ICE compiling mozilla with -O3)
Your message dated Thu, 16 Aug 2001 21:46:30 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#101732: [EMAIL PROTECTED] Re: optimization/3279: internal error at compiling a c++ source file 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.) Darren Benham (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 21 Jun 2001 07:07:25 + >From [EMAIL PROTECTED] Thu Jun 21 02:07:25 2001 Return-path: <[EMAIL PROTECTED]> Received: from bacchus.lis.inpg.fr [:::195.220.21.21] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15CyYm-00021y-00; Thu, 21 Jun 2001 02:07:24 -0500 Received: from irancy.lis.inpg.fr ([EMAIL PROTECTED] [195.220.21.167]) by bacchus.lis.inpg.fr (8.9.3/8.9.3/cf de Bacchus - 25/05/2000) with ESMTP id JAA00946; Thu, 21 Jun 2001 09:07:12 +0200 Received: from bonnaud by irancy.lis.inpg.fr with local (Exim 3.22 #1 (Debian)) id 15CyYa-0006rp-00; Thu, 21 Jun 2001 09:07:12 +0200 From: laurent bonnaud <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: g++-3.0 ICE compiling mozilla X-Reportbug-Version: 1.18 X-Mailer: reportbug 1.18 Date: Thu, 21 Jun 2001 09:07:12 +0200 Message-Id: <[EMAIL PROTECTED]> Sender: laurent bonnaud <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Package: g++-3.0 Version: 1:3.0-1 Severity: important Hi, here is the bug: $ fakeroot apt-get -b source mozilla [building mozilla_0.9.1-3...] nsFormControlHelper.cpp: In static member function `static void nsFormControlHelper::PaintFixedSizeCheckMark(nsIRenderingContext&, float)': nsFormControlHelper.cpp:731: Internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. In the directory /tmp/LB/mozilla-0.9.1/layout/html/forms/src The following command failed to execute properly: c++ -o nsFormControlHelper.o -c -DOSTYPE="Linux2.4" -DOSARCH="Linux" -DOJI -D_IMPL_NS_HTML -DENDER_LITE -I../../../../dist/include -I../../../../dist/include -I/tmp/LB/mozilla-0.9.1/dist/include/nspr -I./../../../base/src -I./../../base/src -I./../../style/src -I./../../../xul/base/src -I/usr/X11R6/include -fPIC -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wbad-function-cast -Wcast-align -Woverloaded-virtual -Wsynth -pedantic -Wno-long-long -pipe -fshort-wchar -pthread -pipe -w -O3 -DNDEBUG -DTRIMMED -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../../../config-defs.h -Wp,-MD,.deps/nsFormControlHelper.pp nsFormControlHelper.cpp -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux irancy 2.4.4-686 #1 Sun Apr 29 12:22:40 EST 2001 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages g++-3.0 depends on: ii gcc-3.0 1:3.0-1The GNU C compiler. ii gcc-3.0-base 1:3.0-1The GNU compiler collection (base ii libc6 2.2.3-6GNU C Library: Shared libraries an ii libstdc++3-dev1:3.0-1The GNU stdc++ library version 3 ( --- Received: (at 101732-done) by bugs.debian.org; 16 Aug 2001 19:50:45 + >From [EMAIL PROTECTED] Thu Aug 16 14:50:45 2001 Return-path: <[EMAIL PROTECTED]> Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15XTAC-0008DI-00; Thu, 16 Aug 2001 14:50:44 -0500 Received: from bolero.cs.tu-berlin.de ([EMAIL PROTECTED] [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id VAA24528; Thu, 16 Aug 2001 21:46:31 +0200 (MET DST) Received: (from [EMAIL PROTECTED]) by bolero.cs.tu-berlin.de (8.10.2+Sun/8.9.3) id f7GJkVN05451; Thu, 16 Aug 2001 21:46:31 +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: Thu, 16 Aug 2001 21:46:30 +0200 To: Laurent Bonnaud <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Bug#101732: [EMAIL PROTECTED] Re: optimization/3279: internal error at compiling a c++ source file In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Delivered-To: [EMAIL PROTECTED] Laurent Bonnaud writes: > > Hi, > > I tested again with > > ii g++-3.0 3.0.1-0pre010811The GNU C++ compiler. > > and the bug is fixed. >
Bug#106464: marked as done ([alpha] gcc-2.95 generates bad STABS debugging info on Alpha)
Your message dated Thu, 16 Aug 2001 16:13:21 -0400 (EDT) with message-id <[EMAIL PROTECTED]> and subject line gcc-2.95 generates bad STABS info on Alpha 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.) Darren Benham (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 24 Jul 2001 18:54:07 + >From [EMAIL PROTECTED] Tue Jul 24 13:54:07 2001 Return-path: <[EMAIL PROTECTED]> Received: from dsl092-073-086.bos1.dsl.speakeasy.net (spawn.hockeyfiend.com) [:::66.92.73.86] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15P7Jn-0003u6-00; Tue, 24 Jul 2001 13:54:07 -0500 Received: from localhost ([127.0.0.1] ident=chris) by spawn.hockeyfiend.com with esmtp (Exim 3.31 #1 (Debian)) id 15P7Jj-0007OX-00 for <[EMAIL PROTECTED]>; Tue, 24 Jul 2001 14:54:03 -0400 Date: Tue, 24 Jul 2001 14:54:03 -0400 (EDT) From: "Christopher C. Chimelis" <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [alpha] gcc-2.95 generates bad STABS debugging info on Alpha Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] Package: gcc-2.95 Version: 2.95.4-0.010629 Severity: critical While packaging a new binutils, I noticed that 'strip -g' called twice failed to strip binaries that were generated by gcc-2.95, and in fact, produced binaries that no longer worked (as well as causing strip to segfault). This only appears to affect object files, NOT linked binaries, so stripping archives won't work properly. When comparing assembly output, it appears that the stabs info isn't correctly generated. Using gcc-3.0 to compile the same file (with the -gstabs option) produced a correct object file that could be stripped repeatedly without problems. Also, using DWARF2 output from gcc-2.95 as well as gcc-3.0 both worked fine. I emailed upstream for binutils to verify this and HJ Lu confirmed that the stabs info doesn't look correct and that binutils was actually correct. This appears to only affect Alpha and is holding back a binutils upload. This bug is meant as a tracking mechanism for me while I try to fix this problem, but if someone wants to ask upstream, I can provide asm output and a very simple testcase. Binutils that uncovered the problem: 2.11.90.0.24. 2.11.90.0.7 appears to work fine, but I could reproduce the same problem if I used a certain file and passed it certain flags. All gcc-2.95.4 versions that I have (dating back to April) showed this problem. C --- Received: (at 106464-done) by bugs.debian.org; 16 Aug 2001 20:13:22 + >From [EMAIL PROTECTED] Thu Aug 16 15:13:22 2001 Return-path: <[EMAIL PROTECTED]> Received: from dsl092-073-086.bos1.dsl.speakeasy.net (spawn.hockeyfiend.com) [66.92.73.86] (mail) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15XTW6-0001Dv-00; Thu, 16 Aug 2001 15:13:22 -0500 Received: from localhost ([127.0.0.1] ident=chris) by spawn.hockeyfiend.com with esmtp (Exim 3.32 #1 (Debian)) id 15XTW5-0007Py-00 for <[EMAIL PROTECTED]>; Thu, 16 Aug 2001 16:13:21 -0400 Date: Thu, 16 Aug 2001 16:13:21 -0400 (EDT) From: "Christopher C. Chimelis" <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: gcc-2.95 generates bad STABS info on Alpha Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] Turns out that this was a gas problem after all. Solved in binutils 2.11.90.0.27-1. For historical reasons, there is something wrong with what gcc-2.95 outputs, but the problems that I was seeing shouldn't have been caused by that at all. C
Bug#106466: marked as done ([alpha] gcc-2.95.4.ds4-0.010703 doesn't compile on alpha and other problems)
Your message dated Thu, 16 Aug 2001 16:14:34 -0400 (EDT) with message-id <[EMAIL PROTECTED]> and subject line New patch allows compilation on alpha 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.) Darren Benham (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 24 Jul 2001 19:02:26 + >From [EMAIL PROTECTED] Tue Jul 24 14:02:26 2001 Return-path: <[EMAIL PROTECTED]> Received: from dsl092-073-086.bos1.dsl.speakeasy.net (spawn.hockeyfiend.com) [:::66.92.73.86] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15P7Rp-0004B0-00; Tue, 24 Jul 2001 14:02:25 -0500 Received: from localhost ([127.0.0.1] ident=chris) by spawn.hockeyfiend.com with esmtp (Exim 3.31 #1 (Debian)) id 15P7Rp-0007P5-00 for <[EMAIL PROTECTED]>; Tue, 24 Jul 2001 15:02:25 -0400 Date: Tue, 24 Jul 2001 15:02:25 -0400 (EDT) From: "Christopher C. Chimelis" <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [alpha] gcc-2.95.4.ds4-0.010703 doesn't compile on alpha and other problems Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] Package: gcc-2.95 Version: 0.010703 Severity: critical Apparently, the new gcc-gas-hidden patch isn't correct, or rather, isn't complete. As it stands, gcc will not bootstrap with that patch applied. The change needed to make this patch work involves possibly changing the C++ ABI, since we're adding __dso_handle to the binaries, which the C++ constructors and destructors are supposed to "hang off of". These were, in fact, the main part of the changes that got C++ working on Alpha in gcc 3.0.x. If the entire patch is applied, which again is quite sizable and would involve changing non-arch-specific parts of gcc, everything C++ should be recompiled on Alpha for it to work correctly. I'm not sure this is a good idea. On the other hand, according to the glibc list, we need this patch or similar to generate a glibc that doesn't have the atexit() and fstat() problems that we have now (since it also helps hidden and weak symbols to be linked in DSOs properly). So the dilemma stands... Is there any way that we can fix gcc-2.95 to link DSOs with hidden and weak symbols properly without altering the code so much? My alternative seems to be to move Alpha to gcc-3.0 for woody, which generates a properly linked glibc (supposedly..untested so far), but which may also cause more recompilations and problems at this stage of the release cycle. This bug is meant more as a tracking bug for me while I look into this, but if you could ask upstream about the linking problems, I would greatly appreciate it. I'm a bit swamped by Alpha issues and my own packages ATM and can't spend too much time working this out on a few lists... C --- Received: (at 106466-done) by bugs.debian.org; 16 Aug 2001 20:14:35 + >From [EMAIL PROTECTED] Thu Aug 16 15:14:35 2001 Return-path: <[EMAIL PROTECTED]> Received: from dsl092-073-086.bos1.dsl.speakeasy.net (spawn.hockeyfiend.com) [66.92.73.86] (mail) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 15XTXH-0001M4-00; Thu, 16 Aug 2001 15:14:35 -0500 Received: from localhost ([127.0.0.1] ident=chris) by spawn.hockeyfiend.com with esmtp (Exim 3.32 #1 (Debian)) id 15XTXG-0007QJ-00 for <[EMAIL PROTECTED]>; Thu, 16 Aug 2001 16:14:34 -0400 Date: Thu, 16 Aug 2001 16:14:34 -0400 (EDT) From: "Christopher C. Chimelis" <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: New patch allows compilation on alpha Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] The original hidden-weak linkage patch was incomplete, hence the compilation problems. We now have a working patch that appears to do exactly what it should (CVS already updated), so this bug can be closed. C
