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 <iostream>
class Class {
public:
void M1 (void) { cout << "M1" << endl; };
void M2 (void) { cout << "M2" << endl; };
void M3 (void) { cout << "M3" << endl; };
};
typedef void (Class::*ClassMemberFn)(void);
#define callMemberFunction(object,ptrToMember) ((object).*(ptrToMember))
int main (int argc, char* argv[]) {
Class obj;
// This works fine: Array size == 2
ClassMemberFn a[2] = { &Class::M1, &Class::M2};
for (unsigned int i=0; i<2; ++i) {
callMemberFunction (obj, a[i]) ();
}
// This will cause the internal compiler error: Array size > 2
ClassMemberFn b[3] = { &Class::M1, &Class::M2,&Class::M3};
for (unsigned int i=0; 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 <URL:http://www.gnu.org/software/gcc/bugs.html> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: Digital signature
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20030429/33bf9f0a/attachment.bin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think your public methods for the class Class should be static. On Tuesday 29 April 2003 10:38 am, Simon Barner wrote:> 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 <iostream> > class Class { > public: > void M1 (void) { cout << "M1" << endl; }; > void M2 (void) { cout << "M2" << endl; }; > void M3 (void) { cout << "M3" << endl; }; > }; > > typedef void (Class::*ClassMemberFn)(void); > #define callMemberFunction(object,ptrToMember) > ((object).*(ptrToMember)) > > int main (int argc, char* argv[]) { > Class obj; > > // This works fine: Array size == 2 > ClassMemberFn a[2] = { &Class::M1, &Class::M2}; > for (unsigned int i=0; i<2; ++i) { > callMemberFunction (obj, a[i]) (); > } > > > // This will cause the internal compiler error: Array size > 2 > ClassMemberFn b[3] = { &Class::M1, &Class::M2,&Class::M3}; > for (unsigned int i=0; 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 <URL:http://www.gnu.org/software/gcc/bugs.html> 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- -- Paul Marquis pmarquis@pobox.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+rsvqIuLAUo3z6B0RAlsCAJsFuNqfb6qcVf1zpCXUKi9yzVqo2QCfbHEN yvCB4MLhLHGcNphP/srT9iY=OW8B -----END PGP SIGNATURE-----
pmarquis@pobox.com said:> I think your public methods for the class Class should be static.Well, you could make them static but that changes the meaning of the program. The original was a valid (if unusual) design and should be accepted by the compiler. The compiler is not maintained by FreeBSD, so C++ bugs should be reported to the egcs web page. But I suspect they'll say "fixed in egcs 3.x" so there's probably not much that can be done for FreeBSD 4 other than install and use the gcc33 port for your application (and all the libraries linked with it!) Greg.
In message: <200304291501.02430.pmarquis@pobox.com>
Paul Marquis <pmarquis@pobox.com> writes:
: I think your public methods for the class Class should be static.
No need. He's using member function pointers, and an object, so the
code looks right to my eye.
Warner