HDTenEightyP/NetNews huggingface dataset:
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: 2.3.2: friend decl breaks member op new
Organization: Minimal
Distribution: gnu
Date: Fri, 18 Dec 1992 00:33:35 GMT

>>>>> myersn%rwave.roguewave@rwave.UUCP (Nathan Myers) writes:

> Can anybody tell me why gcc's ::new calls __builtin_new(),
> rather than ::operator new() as specified in the ARM?
> This makes it awkward to provide a portable replacement for malloc
> and operator new.

void *operator new() becomes ___builtin_new in the output.  This may seem
strange, but how does it make it more difficult to override the g++
defaults?

--
Jason Merrill					jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: keister@poincare.phys.cmu.edu (Bradley D. Keister)
Subject: 2.3.2 constructor problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 11:38:32 GMT

I'm getting the following compiler error messages under g++ 2.3.2 on a
SPARC and an HP:

% g++ -c promote.c
promote.c: In function `void  _GLOBAL_$I$Atest1 ()':
promote.c:15: bad argument 1 for function `A::A (class Complex, class Complex)'
(type was class Complex*)
promote.c:15: in base initialization for class `A'

// --------------------------

This code compiles fine on a DECstation or SPARC running g++ 2.2.2 or
a DECstation running cfront 3.0.  The source is given below.

Brad Keister
Department of Physics
Carnegie Mellon University
Pittsburgh, PA 15213
(412) 268-2772 (office)
(412) 681-0648 (FAX)

internet:	keister@poincare.phys.cmu.edu
BITNET:		keister%poincare.phys.cmu.edu@CARNEGIE

// --------------------------

// file "promote.c"
#include <complex.h>
#include <stdio.h>

class A {

 protected:
  complex a, b;

 public:
  A(complex aa, complex bb) {a = aa; b = bb;}
  ~A() {}
};

A Atest1(1, 5);
A Atest2(1, complex(2, 3));

main() {}

Newsgroups: gnu.g++.bug
From: myersn%rwave.roguewave@rwave.UUCP (Nathan Myers)
Subject: 2.3.2: friend decl of new confuses constructor
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 00:33:00 GMT

Friend declarations of global operators new and delete confuse
the constructor and destructor:

$ cat bug.cc
#include <stddef.h>
struct Foo {
  friend void* operator new(size_t);
  friend void operator delete(void*);
  Foo();
  ~Foo();
};
Foo::Foo() { }
Foo::~Foo() { }

$ gcc -v -c bug.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2/2.3.2/specs
gcc version 2.3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2/2.3.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsun -Dsparc -Dunix -D__svr4__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__sun -D__sparc -D__unix -D__svr4__ -Asystem(unix) -Acpu(sparc) -Amachine(sparc) bug.cc /tmp/cca000j..i
GNU CPP version 2.3.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-solaris2/2.3.2/cc1plus /tmp/cca000j..i -quiet -dumpbase bug.cc -version -o /tmp/cca000j..s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.

bug.cc: In method `Foo::Foo ()':
bug.cc:8: no member function `Foo::operator new'
bug.cc: In method `Foo::~Foo ()':
bug.cc:9: no member function `Foo::operator delete'

---------------------
Nathan Myers
Rogue Wave Software
myersn@roguewave.com (or try myersn@ece.orst.edu)


Newsgroups: gnu.g++.bug
From: duan@cs.psu.edu (Niu Duan)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 15:54:26 GMT

Hi G++ folks,

I would like to report some problems I've encounted while running my g++ program.
I think there may be a bug within the compiler, because I could not find any 
explanation regrading the problem.

This is what happens:  I am trying to generate a tree structure.  Each tree node 
(of of class type GL_states) contains a set of pointers of child nodes and 
a pointer to it parent node.  The first generation of children are OK, while the 
second generation causes trouble.  While setting the my_dad pointer of a child,
the data contained in the parent node has also been changed.  The size of a tree
node is 32bytes, and the 1st and the 6th four bytes of the parent node are always
being effected.   

I was using the constructor function to set up the 'my_dad' pointer of each node.
I tryed to use an explicit member function to set the 'my_dad' value and got the
same error.  

The program environment:

	g++ version 2.3.2
	libg++ version 2.2
	gdb version 4.7
	sun sparc running sun OS 4.1

I am sending you with the next msg a uuencoded tar file which contains the
following files ( the file name after uudecode is bug_report.tar):

	emmn.h		- the header file
	emmlib.cc	- contains the member functions
	emmlibb.cc	- contains the member functions
	main.cc		- the main program
	Makefile	- makefile
	emm.def		- the 1st argument data file
	emmn.def	- the 2nd argument data file	
	bug.report	- output of gdb, where bugs are highlighted 
			- with '******....******'
	bug.msg		- this msg

If it was not a bug, I would appreciate if you could tell me what's wrong with
my program.  Thank you!

- Niu Duan


Newsgroups: gnu.g++.bug
From: nelson@berlioz.nsc.com (Taed Nelson)
Subject: @ Function template in 2.3.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 22:10:28 GMT

I am using G++ 2.3.2 on SunOS 4.1.1 on a sparcStation 1.  It generates bad
  assembly code when function templates are used.

The code supplied below compiles and runs correctly under Borland C++ on DOS.

------------------------------------------------------------------------------
g++ -Wall test.cc
as: "/usr/tmp/cca12274.s", line 151: error: redefinition of symbol "_getString"
as: "/usr/tmp/cca12274.s", line 167: error: redefinition of symbol "_getString"
------------------------------------------------------------------------------
#include <stdio.h>

class base {
public:
	int value;
	const char *string;
	base () { string = "BASE"; };
};

class d1 : public base {
public:
	const char *string;
	d1 () { string = "D1"; };
};

class d2 : public base {
public:
	const char *string;
	d2 () { string = "D2"; };
};


template <class T>
const char *getString (T *p_class)
{
	return (p_class->string);
};


int main ()
{
	base o_base;
	d1 o_d1;
	d2 o_d2;

	printf ("%s %s %s\n",
		getString (&o_base),
		getString (&o_d1),
		getString (&o_d2));

	return (0);
}
------------------------------------------------------------------------------





Newsgroups: gnu.g++.bug
From: tlukka@vinkku.hut.fi
Subject: Pure virtual destructors!
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Dec 1992 18:39:29 GMT

Pure virtual destructors dump core on HP-PA1.1 HP-UX 8.07
Running the sample code won't succeed.
Compiles ok, though.

	TJL

------ clip clip ---- sample code


class A
{
	int a;
public:	
	A() {}
	virtual ~A()=0;
};

class B:public A
{
	int b;
public:
	B() {}
	virtual ~B()
	{
	}
};


int main()
{
	B a;
}

---------------------

Newsgroups: gnu.g++.bug
From: 100065.72@compuserve.COM (Simon Greener)
Subject: GNU C++ template bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 15:28:30 GMT

#include <iostream.h>

template <class T>
class vector {
private:
    T a[3];
public:
    vector( T a1, T b2, T c3 )
    { 
        a[0] = a1;
        a[1] = b2;
        a[2] = c3;
    };

    T dot( const vector<T> other )
    {
        return (a[0] * other.a[0]) + (a[1] * other.a[1]) + (a[2] * other.a[2]);
    }
};


int main( int argc, char *argv[] )
{
    vector<int> v1(1,1,1);
    vector<int> v2(2,3,4);

    cout << "Dot Product = " << v1.dot(v2) << endl;

    return 0;
}

// The above gives up with "parse error before `>'" at line 16.  In general
// the GNU compiler does not seem to like template member functions referencing
// the type of the the template class.  I'm using GNUC version 2.2.2. on a PC
// running MS-DOS version 3.30.  The GNUCC is unmodified - as obtained from
// D.J. Delorie.
//
// My address is 100065.72@compuserv.com


Newsgroups: gnu.g++.bug
From: eks@daimi.aau.dk (Eigil Krogh S|rensen)
Subject: Wanted: Information from other Motorola sysV68 R3 users.
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Distribution: gnu
Date: Mon, 14 Dec 1992 22:22:18 GMT

To make  it possible  to tell  if  I am  a bungler,  there are  special
problems  on  Motorola sysV68  R3 (3300)  systems  or the  GNU software
packages  gcc, libg++ and groff have bugs  I would be very glad to hear
about experiences from others who  has worked with installation  of GNU
software on Motorola sysV68 R3 (3300) systems.

Status here is:

(Installed means  configure script,  make and  make install has  passed
without errors after  changes in the source code. It  is absolutely NOT
tantamount to the installed package being errorfree)

gcc-2.3.2         Installed.

libg++-2.2        Installed.

groff-1.06        Configure script  passed without errors.  First thing
                  that happens when make is run is that gcc-2.3.2 gives
                  errormessages  and make  stops. The  groff developers
                  tell me that my c++ compiler (gcc-2.3.2) is broken.

It would be very interesting to hear about experiences from others.

Thank you in advance.


Eigil Krogh Sorensen

(eks@daimi.aau.dk    eks@aar-vki.dk)


Newsgroups: gnu.g++.bug
From: fritz@mtl.mit.edu (Frederick Herrmann)
Subject: Bug report: trouble with long filenames?
Reply-To: fritz@mtl.mit.edu
Organization: MIT Microsystems Technology Laboratories
Distribution: gnu
Date: Fri, 11 Dec 1992 11:47:58 GMT

G++ is giving me "Internal compiler error" messages.
My guess is that it's barfing on long filenames in preprocessor line
controls.

Background:

   Observed problem on Sun IPC and IPX.
   Do not observe problem on DecStation under Ultrix 4.2C.

   % head -1 /etc/motd
   SunOS Release 4.1.3 (MTL-4.1.3-1) #1: Sat Oct 17 16:56:33 EDT 1992
   % gcc -v
   Reading specs from /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
   gcc version 2.3.2


Discovery:

1. Trying to re-write our old simulator in c++.  (I'm new at c++, so
   please excuse my code.)  Code is not fully debugged, but at least
   it compiles. 

2. Started getting compiler errors after reorganizing the source tree.
   Did a few random experiments to try and figure out what was going
   on.

3. Copied the troublesome .cc file and the necessary .h file to a
   different dir.  Compiles fine.

4. Used "g++ -E" to generate pre-processed .i files in both the good
   and bad directories.


Symptom:

   I have two .i files.  One compiles, and the other doesn't.  The only
   differences between them are in the pre-processor line controls.

   % g++ -c bug_good.i
   % g++ -c bug_bad.i
   fritztest.cc: In function `int  main (int, char **)':
   fritztest.cc:12: Internal compiler error.
   fritztest.cc:12: Please report this to `bug-g++@prep.ai.mit.edu'.
   % diff bug_{good,bad}.i 
   1c1
   < # 1 "bug.cc"
   ---
   > # 1 "fritztest.cc"
   750c750
   < # 1 "bug.cc" 2
   ---
   > # 1 "fritztest.cc" 2
   753c753
   < # 1 "simarray.h" 1
   ---
   > # 1 "/fs/wayne/a/app/xapp/include/simarray.h" 1
   789c789
   < # 16 "simarray.h" 2
   ---
   > # 16 "/fs/wayne/a/app/xapp/include/simarray.h" 2
   792c792
   < # 1 "./defs.h" 1
   ---
   > # 1 "/fs/wayne/a/app/xapp/include/defs.h" 1
   :
   : etc.

Files:
   I will make the file g++bug.tar.Z available for anonymous ftp on
   mtl.mit.edu.  If you need any more information I will be happy to
   provide it.

Thanks for your attention to this report.  I think you guys are doing
a great job.

				- Fritz
				  fritz@mtl.mit.edu

Newsgroups: gnu.g++.bug
From: jeremy@sw.oz.AU (Jeremy Fitzhardinge)
Subject: GNU C++ emits unnecessary warning with class with a private destructor
Organization: Softway Pty Ltd
Distribution: gnu
Date: Sat, 19 Dec 1992 03:52:33 GMT

GNU C++ 2.3.2 emits a warning when a class has a private destructor and
no friends.  However, this doesn't mean that the destructor can never be
called if, for example, there is a public method that calls it.

It is probably worthwhile to have this as a warning, but not by default.

Also, the warning message refers to line number 0, which isn't very accurate.

-- bug.cc --
//	This is a trivial example which produces the warning

class foo
{
private:
	int	data;

		~foo();

public:
	void	remove();
		foo(int x)	{ data = x; }
};

void
foo::remove()
{
	data=0;
	delete this;
}
-- end bug.cc --

Reading specs from /usr/local/lib/gcc-lib/sparc-sunos4/2.3.2/specs
gcc version 2.3.2
 /usr/local/lib/gcc-lib/sparc-sunos4/2.3.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -I/usr/local/libg++/2.2/include bug.cc /tmp/cca27111.i
GNU CPP version 2.3.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sunos4/2.3.2/cc1plus /tmp/cca27111.i -quiet -dumpbase bug.cc -version -o /tmp/cca27111.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
bug.cc:0: warning: class `foo' only defines a private destructor and has no friends
 as -o bug.o /tmp/cca27111.s

	J


Newsgroups: gnu.g++.bug
From: joseph@iac.UUCP ( Joseph )
Subject: gcc 2.3.2 bug in referencing a member of enclosing class from a friend class.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 18:09:53 GMT

C++ code
=========================================================================

class X {
public:
  int   	k;
  
  friend class Y {
  public:
    X*		x;
    void      	g(void) { int i = x->k; }
  };
};

=========================================================================



G++ 2.3.2 run
=========================================================================

bin/g++ -v -c b1.cc
Reading specs from /home/users/joseph/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
gcc version 2.3.2
 /home/users/joseph/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix b1.cc /tmp/cca01976.i
GNU CPP version 2.3.2 (sparc)
 /home/users/joseph/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/cc1plus /tmp/cca01976.i -quiet -dumpbase b1.cc -version -o /tmp/cca01976.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
b1.cc: In method `void  Y::g ()':
b1.cc:8: assignment to non-static member `k' of enclosing class `X'

Compilation exited abnormally with code 1 at Fri Dec 11 10:00:26


=========================================================================

gcc 2.3.2 has been configured with:

./configure --target=sparc-sun-sunos4.1


=========================================================================

Any patch/suggestions are more than welcome.
(As i am off the net right now, pls mail if possible)

-pepe


Newsgroups: gnu.g++.bug
From: yb@lri.FR
Subject: g++ problem with virtual const method in template
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 21:06:43 GMT

g++ 2.3.2 failed to compiled this file :

------------------------------------------------------
template <class T> class A {
public:
virtual	void foo () const;
};

template <class T> void A<T> :: foo () const {}

template <class T> class B : public A<T> {
public:
	void foo () const;
	void bar () { foo(); }
};

B<int> b;
--------------------------------------------------------

The bug disappear when 'const' or 'virtual' is removed.

Here is what happens :

sun2->gcc -v -c bug.cc
Reading specs from /usr/local/gnu/lib/gcc-lib/sun4/2.3.2/specs
gcc version 2.3.2
 /usr/local/gnu/lib/gcc-lib/sun4/2.3.2/cpp -lang-c++ -v -undef
-D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix
-D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix test.cc
/usr/tmp/cca04703.i
GNU CPP version 2.3.2 (sparc)
 /usr/local/gnu/lib/gcc-lib/sun4/2.3.2/cc1plus /usr/tmp/cca04703.i
-quiet -dumpbase test.cc -version -o /usr/tmp/cca04703.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
test.cc: In method `void  B<int>::bar ()':
test.cc:12: Internal compiler error.
test.cc:12: Please report this to `bug-g++@prep.ai.mit.edu'.
sun2->


+--------------------------+------------------------------------+
|                          |       E-mail : yb@lri.lri.fr       |
|     Yves Berteaud        |                yb@FRLRI61.BITNET   |
|                          |                                    |
|       +-=-+-=-+          |       Voice :  33 (1) 69-41-69-10  |
|                          |       Fax   :  33 (1) 69-41-65-86  |
+--------------------------+------------------------------------+
|      ######      **                                           |
|     ##     #         Laboratoire de recherche en informatique |
|    ##       #   ##   Batiment 490                             |
|   ##       #   ##    Universite de Paris-Sud                  |
|  ##    ####   ##     91405 ORSAY Cedex                        |
| ######    ## ##      FRANCE                                   |
|######      ###                                                |
+---------------------------------------------------------------+

Newsgroups: gnu.g++.bug
From: myersn%rwave.roguewave@rwave.UUCP (Nathan Myers)
Subject: 2.3.2: friend decl breaks member op new
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 16 Dec 1992 19:55:00 GMT

// Friend declaration disables access to member operator new
//   (this bug does not occur in gcc 2.2.2)

#include <stddef.h> // for size_t
struct Link {
  void* operator new(size_t, int);
  friend void* __builtin_new(size_t);  // This declaration triggers the bug
};
void f() { new(2) Link; }

Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2/2.3.2/specs
gcc version 2.3.2
 /usr/local/lib/gcc-lib/sparc-sun-solaris2/2.3.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsun -Dsparc -Dunix -D__svr4__ -D__sun__ -D__sparc__ -D__unix__ -D__svr4__ -D__sun -D__sparc -D__unix -D__svr4__ -Asystem(unix) -Acpu(sparc) -Amachine(sparc) gccbug.cc /tmp/cca000KN.i
GNU CPP version 2.3.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-solaris2/2.3.2/cc1plus /tmp/cca000KN.i -quiet -dumpbase gccbug.cc -version -o /tmp/cca000KN.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.

gccbug.cc: In function `void f ()':
gccbug.cc:10: too many arguments for function `operator new'


Can anybody tell me why gcc's ::new calls __builtin_new(),
rather than ::operator new() as specified in the ARM?
This makes it awkward to provide a portable replacement for malloc
and operator new.

-------------------
Nathan Myers
Rogue Wave Software 
myersn@ece.orst.edu


Newsgroups: gnu.g++.bug
From: ricks%dogbert@[144.212.2.21] (Rick Spada)
Subject: class templates
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 17 Dec 1992 20:27:27 GMT

Enclosed is an example of a problem that I've run into using class templates.
Can anyone shed some light on this?

-- Rick Spada
   The MathWorks, Inc.
   ricks@mathworks.com

Using:
	gcc version 2.2.2
	GNU CPP version 2.2.2 (sparc)
	GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.

/*
 * Can anyone tell me what\'s wrong with this?  With THIS_COMPILES undef\'d, I
 * get error messages ofthe form:
 *
 * >    lipman.cc: In function `int  main ()':
 * >	lipman.cc:35: template for method `Array' doesn't match any in class `Array<int>'
 * >	lipman.cc:35: warning: dbx info for template class methods not yet supported
 * >	lipman.cc:35: template for method `Array' doesn't match any in class `Array<float>'
 */

# include <iostream.h>
# include <stdlib.h>

#define THIS_COMPILES
#undef THIS_COMPILES

template <class type>
class Array {
  public:
#if defined(THIS_COMPILES)
    Array(int sz = 12) : ia(new type[sz]), size(sz) { }
    ~Array(void) { delete ia; }
#else
    Array(int sz = 12);
    ~Array(void);
#endif
    
    inline type & operator[] (int elem) { return ia[elem]; }
    
    inline int Size(void) { return size; }
    
  private:
    type *ia;
    int size;
};

#if !defined(THIS_COMPILES)

template <class type>
Array<type>::Array (int sz) : ia(new type[sz]), size(sz) { }

template <class type>
Array<type>::~Array (void) { delete ia; }

#endif

main ()
{
    Array<int> ia;
	Array<float> fa;
    
    for (int i = 0; i < ia.Size (); i++) {
        ia[i] = rand ();
		fa[i] = rand ();
	}
    
    for (i = 0; i < ia.Size (); i++)
        cout << ia[i] << "\n";
    
    for (i = 0; i < fa.Size (); i++)
        cout << fa[i] << "\n";
}

Newsgroups: gnu.g++.bug
From: jaf@inference.COM (Jose A. Fernandez)
Subject: gcc2.3.2
Organization: Inference Corporation
Distribution: gnu
Date: Sat, 19 Dec 1992 18:54:12 GMT

    rrh> the very long program at the end of this posting causes
    rrh> ...[omitted]...

Hello Robert,

A significant number of people receive their mail via UUCP over phone
lines.  I consider myself very fortunate to have a relatively high speed
phone link; it only took 13 minutes to download your posting at average
800 chars/sec.  However, I wonder how certain people felt when it took
anywhere from 30 minutes to 2 HOURS to download your bug report.

For future reference, please compress/uuencode large bodies of code or
output.  Pretty please.

Newsgroups: gnu.g++.bug
From: jbg@qualcomm.com (Jeff Gehlhaar)
Subject: G++ Bug Report 14
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 02:48:46 GMT

This is using the newest 2.3 libg++.....

// When warnings for overloaded virtuals are turned on:
//      an error is detected in <fstream.h>
//      it's an error and not a warning
// Compiling this with ``g++ -v -c -Woverloaded-virtual bug014.cc'' gets:
// Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
// gcc version 2.3.2
// In file included from bug014.cc:11:
// /usr/local/lib/g++-include/fstream.h:34: conflicting specification
deriving virtual function `void  fstreambase::setbuf (char *, int)'

#include <iostream.h>
#include <fstream.h>



Newsgroups: gnu.g++.bug
From: jeremym@syma.sussex.ac.uk (Jeremy Maris)
Subject: reported compiler error with g++ 2.3.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 19:24:27 GMT

I tried to build groff (1.06) with gcc 2.3.2 and libg++ 2.3. Whilst compiling
pic I got the following: (Ultrix 4.2)
All was fine 'till then.

Reading specs from /usr/local/lib/gcc-lib/decstation-ultrix/2.3.2/specs
gcc version 2.3.2
 /usr/local/lib/gcc-lib/decstation-ultrix/2.3.2/cpp -lang-c++ -v -I. -I.
-I../include -I./../include -undef -D__GNUC__=2 -D__GNUG__=
2 -D__cplusplus -D__ANSI_COMPAT -DMIPSEL -DR3000 -DSYSTYPE_BSD
-D_SYSTYPE_BSD -Dbsd4_2 -Dhost_mips -Dmips -Dultrix -Dunix -D__ANSI_COMPAT
-D__MIPSEL__ -D__R3000__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__
-D__bsd4_2__ -D__host_mips__ -D__mips__ -D__ultrix__ -D__unix__
-D__ANSI_COMPAT -D__MIPSEL -D__R3000 -D__SYSTYPE_BSD -D___SYSTYPE_BSD
-D__bsd4_2 -D__host_mips -D__mips -D__ultrix -D__unix -D__OPTIMIZE__ 
-g -D__LANGUAGE_C_PLUS_PLUS__ -D__LANGUAGE_C_PLUS_PLUS
-D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C -DHAVE_UNISTD_H=1 
-DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_CC_LIMITS_H=1
-DHAVE_CC_UNISTD_H=1 -DSTDLIB_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 
-DHAVE_MMAP=1 -DHAVE_RENAME=1 -DHAVE_SYS_SIGLIST=1
-DWCOREFLAG=0200 object.cc /usr/tmp/cca27173.i
GNU CPP version 2.3.2 [AL 1.1, MM 29] DECstation running ultrix
/usr/local/lib/gcc-lib/decstation-ultrix/2.3.2/cc1plus
/usr/tmp/cca27173.i -mgpopt -quiet -dumpbase object.cc -g -O -version -o
/usr/tmp/cca27173.s
GNU C++ version 2.3.2 [AL 1.1, MM 29] DECstation running ultrix compiled
by GNU C version 2.3.2.
object.cc: In method `circle_object::circle_object (double)':
object.cc:1030: Internal compiler error.
object.cc:1030: Please report this to `bug-g++@prep.ai.mit.edu'.


Code extract:

class circle_object : public ellipse_object {
public:
  circle_object(double);
  object_type type() { return CIRCLE_OBJECT; }
  void print();
};

circle_object::circle_object(double diam)
: ellipse_object(position(diam, diam))
{					<<<< line 1030
}

void circle_object::print()
{
  if (lt.type == line_type::invisible && fill < 0.0)
    return;
  out->circle(cent, dim.x/2.0, lt, fill);
}


Thanks for groff and g++!

Jeremy Maris



Newsgroups: gnu.g++.bug