From owner-freebsd-stable@FreeBSD.ORG Tue Apr 29 07:38:45 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C6B437B401 for ; Tue, 29 Apr 2003 07:38:45 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1081943F3F for ; Tue, 29 Apr 2003 07:38:44 -0700 (PDT) (envelope-from barner@in.tum.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5])3990262B8 for ; Tue, 29 Apr 2003 16:38:43 +0200 (MEST) Received: from mail.informatik.tu-muenchen.de (mail.informatik.tu-muenchen.de [131.159.0.26])2DA0C7945 for ; Tue, 29 Apr 2003 16:38:43 +0200 (MEST) Received: from zi025.glhnet.mhn.de (unknown [129.187.19.157]) by mail.informatik.tu-muenchen.de (Postfix) with ESMTP id 1BA9398 for ; Tue, 29 Apr 2003 16:38:43 +0200 (MEST) Received: by zi025.glhnet.mhn.de (Postfix, from userid 1000) id C704C37683; Tue, 29 Apr 2003 16:38:41 +0200 (CEST) Date: Tue, 29 Apr 2003 16:38:41 +0200 From: Simon Barner To: freebsd-stable@freebsd.org Message-ID: <20030429143841.GA5828@zi025.glhnet.mhn.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: Bug in g++ 2.95.4 (Pointer to member functions) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 14:38:45 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I think I have discovered a bug in FreeBSD 4.8-STABLE's system C++ compiler: % gcc -v % Using builtin specs. % gcc version 2.95.4 20020320 [FreeBSD] Here is a stripped down example that can be used to reproduce the bug: // ----------- begin bug.cpp ----------- #include class Class { public: void M1 (void) { cout << "M1" << endl; }; void M2 (void) { cout << "M2" << endl; }; void M3 (void) { cout << "M3" << endl; }; }; =20 typedef void (Class::*ClassMemberFn)(void); #define callMemberFunction(object,ptrToMember) ((object).*(ptrToMember)) int main (int argc, char* argv[]) { Class obj; =09 // This works fine: Array size =3D=3D 2 ClassMemberFn a[2] =3D { &Class::M1, &Class::M2}; for (unsigned int i=3D0; i<2; ++i) { callMemberFunction (obj, a[i]) (); } =09 // This will cause the internal compiler error: Array size > 2 ClassMemberFn b[3] =3D { &Class::M1, &Class::M2,&Class::M3}; for (unsigned int i=3D0; i<3; ++i) { callMemberFunction (obj, b[i]) (); } return 0; } // ----------- end bug.cpp ----------- This is how you can reproduce the internal compiler error: % gcc -c bug.cpp % bug.cpp: In function `int main(int, char **)': % bug.cpp:20: Internal compiler error in `const_hash', at varasm.c:2373 % Please submit a full bug report. % See for instructions. I have tested the same source (which is an adoption from the C++ FAQ-lite, http://www.parashift.com/c++-faq-lite/pointers-to-members.html) an the following systems: Success: GCC 2.9.2, SunOS 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-60 GCC 3.2.2, SunOS 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-60 GCC 2.9.6 (redhat) , Linux athalle1 2.4.18-27.7.xsmp #1 SMP Same compiler error: GCC 2.9.2, Linux athalle1 2.4.18-27.7.xsmp #1 SMP My conclusion is, that this bug is i386 specific, and that it has been fixed in g++ 3.x and Redhat's 2.96 proprietary version. What should I do (apart from using gcc 3.x from the ports collection)? Should I file a bug at the GCC gnats site, but I think they do not maintain GCC 2.9.4 any longer (I have seen according comments at the end of closed bug reports)? Or should I send a PR? Is there any chance that this bug will be fixed? I also had a look at the gcc source file from that error message, but it's not very helpful as it's the location of an abort () call only... Cheers, Simon --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+ro5xCkn+/eutqCoRAlqYAKCSW66XrfWWy3Z4sN5kYuXgBrDbTQCfakB4 Ic8+i23RMM/Jgg7SKSYmHoY= =yftD -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ--