[gnu.g++.bug] BUG REPORT

kha@idt.unit.no (04/20/89)

Sorry for not reporting this bug before, it is trivial so I forgot it
for a while. When compiling gcc and g++ from gcc.xtar.Z and g++.xtar.Z
on yahi.stanford.edu I get some small problems on sun3-os4. Make
fails, cc and gcc cant find tm.h!! 

It is easy to fix this by making a copy of tm.h in the config
directory, but this leads to another problem: This new tm.h has to be
manually changed when compiling g++. g++ uses a softling to gcc's
contrib bug tm.h are different: This explains my earlier
linking-problems, wrong crt0 will be used if this manual change is forgotten.

This tm.h problem should be fixed in the makefile.

This problem does not exist for sun os3.4.


                                        Knut-Haavard Aksnes.

tiemann@YAHI.STANFORD.EDU (Michael Tiemann) (04/20/89)

The problem with tm.h in config will be fixed in release 1.35.0.

Michael

ned%cadillac.cad.mcc.com@mcc.com (Ned Nowotny) (12/02/89)

Two bugs in g++:

1.  If a derived class is accidently (and incorrectly, of course) declared
    more than once and the base class from which the multiply declared
    class is derived contains a virtual function, the compile will eventually
    dump core with a segmentation violation.  It appears that the combination
    of a virtual function in the base class with the multiple declaration is
    significant.  The following code still printed the correct error messages,
    but did not dump core when the "virtual" keyword was removed.

2.  Hardly worth noting:  g++ -v prints "gcc version ... (based on GCC ...)".
    It seems that "g++ version ... (based on GCC ...)" is intended.

Script started on Fri Dec  1 14:57:27 1989
$ cat /etc/motd ; mach ; arch
SunOS Release 4.0.3 (GENERIC) #2: Mon Apr 24 16:53:06 PDT 1989
sparc
sun4
$ /net/maverick/usr/local/gnu/bin/g++ -v
gcc version 1.36.1 (based on GCC 1.36)
$ cat test.c
/* test.c */

#include <stream.h>

class a
{
    public:
	a() { cout << "I think I will be an a.\n"; }
	virtual void Print();
};

class b : a
{
    public:
	b() { cout << "I think I will be a b.\n"; }
	void Print();
};

class b : a
{
    public:
	b() { cout << "I think I will be a b.\n"; }
	//void Print();
};

void a::Print()
{
    cout << "I think I am an a.\n";
}

void b::Print()
{
    cout << "I must be a b.\n";
}

$ g++ -c test.c
test.c:20: redeclaration of derivation chain of type `b'
test.c:24: redefinition of `struct b'
test.c:36: Segmentation violation
g++: Program cc1plus got fatal signal 11.
$ exit

script done on Fri Dec  1 14:58:37 1989


Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX  78720  Ph: (512) 338-3715
ARPA: ned@mcc.com                   UUCP: ...!cs.utexas.edu!milano!cadillac!ned
-------------------------------------------------------------------------------
"We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.

schmidt@crimee.ics.uci.edu (Doug Schmidt) (02/25/90)

The following short example either illustrates a bug in cfront 2.0
or g++ 1.36.4:

----------------------------------------
class foo
{
public:
  foo::foo ();
  foo::~foo ();
};
----------------------------------------

cfront 2.0 reports (somewhat misleadingly...):
----------------------------------------
"test.c", line 5: error: foo ::~foo () with return type
----------------------------------------

g++ does not complain.

Doug
--
The grave's a fine and private place,     | schmidt@ics.uci.edu (ARPA)
but none, I think, do there embrace.      | office: (714) 856-4043
                  -- Andrew Marvell