HDTenEightyP/NetNews huggingface dataset:
From: tmcconne@sedona.intel.com (Tom McConnell~)
Subject: Re: g++ compiler problem on IBM RS6000
Reply-To: tmcconne@sedona.intel.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 04:00:46 GMT

In article <1993Jan5.191313.6049@news2.cis.umn.edu>, you write:
> Hi,
> 	I am having trouble compiling a c++ program on th IBM RS6000 550 AIX 3.2

  <stuff deleted>
> 
> --
> /*-hoberoi@limerick.cbs.umn.edu--612-624-4938-Univeristy-of-Minnesota-St-Paul--*/
> 

  This is not a bug in g++ or libg++, it is a bug in the RS/6000 assembler. You
need a new /bin/as.

  From the ./gcc-2.3.3/README.RS6000:

    ... Ask for emergency shipment of the rs6000 AIX fix for
    APAR IX26107.

    If you tell them you're running AIX version 3.2, you may be told that
    no fix is available yet.  In fact the 3.15 fix works fine on version
    3.2.  Talk them into shipping it to you anyway.


    Cheers,

    Tom McConnell

 Tom McConnell          |     Internet: tmcconne@sedona.intel.com
 Intel, Corp. C3-91     |     Phone: (602)-554-8229
 5000 W. Chandler Blvd. | The opinions expressed are my own. No one in 
 Chandler, AZ  85226    | their right mind would claim them.

Newsgroups: gnu.g++.bug
From: tim@uk.ac.cf.astro.hecate (Tim Barnett)
Subject: g++-include/stdio.h under SCO UNIX
Reply-To: barnett@cardiff.ac.uk
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 14:45:07 GMT

Platform:   sco-unknown-sysvr3.2.2       [SCO UNIX (SysVr3.2.2)]
G++Version: 2.3.3

Impact:    programs with member functions called 'remove' will often fail,
           with error messages about 'no member function foo::unlink', or
	   foo::unlink may be called where foo::remove was intended.

Cause:     SCO UNIX:/usr/include/stdio.h does
           #define remove(path) unlink(path)
           in order to be POSIX compliant, according to them.

Fix-by:
  I know this is not a 'bug' with G++ as such  (a product which is quite
  incredible in my opinion)  but the only place to patch this braindead
  SCO-ism is in the g++-include/stdio.h header file, hence this suggestion.
  Something like the following, placed after the '#define __stdio_h_recursive'
  would be a boon to all of us poor SCO victims  (and is approximately what
  their version of the AT&T C++ compiler does).

  #if defined(SCO) && defined(remove)
  #undef remove
  #endif

Many thanks
Tim

Newsgroups: gnu.g++.bug
From: tim@uk.ac.cf.astro.hecate (Tim Barnett)
Subject: g++-include/stdio.h under SCO (final)
Reply-To: barnett@cardiff.ac.uk
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 15:23:48 GMT

Ok - I seem to have gotten everything wrong (its been a long night) ...
The lines are
#ifdef remove
#undef remove
#endif
And come after  '#define _stdio_h 1'  (not '#define __stdio_h_recursive').

Goodnight,
Tim

Newsgroups: gnu.g++.bug
From: Henk.Mos@fys.ruu.NL (Henk Mos)
Subject: gcc 2.3.3 problem (Ultrix)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 09:47:33 GMT

Environment:

>>ULTRIX V4.3 (Rev. 44) System #3: Mon Dec 14 12:22:46 MET 1992

>>Reading specs from /usr/local/lib/gcc-lib/mips-dec-ultrix/2.3.3/specs
>>gcc version 2.3.3

I tried to build groff 1.06 with gcc 2.3.3 and got the following error:

Making all in pic
. 
. 
. 
gcc -O -I. -I. -I../include -I./../include -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 
 -g  -c object.cc
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'.
make[2]: *** [object.o] Error 1
make[1]: *** [pic] Error 1

Building groff 1.06 with gcc 2.3.1 gave no problems. I'm not very
familiar with c++ so I can just report the error.

Sincerely, Henk Mos

-- 
----------------------------------------------------------------------
Henk J. Mos, Dept of Physics and Astrophysics, University of Utrecht.
P.O. Box 80.000, 3508 TA Utrecht, The Netherlands.
Telephone: +31-30-532239
e-mail   : mos@fys.ruu.nl
----------------------------------------------------------------------


Newsgroups: gnu.g++.bug
From: klamer@mi.el.utwente.NL (Klamer Schutte)
Subject: 2.3.3: Internal compiler error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 14:45:40 GMT

In the file:
---------------- cut here -----------------
class A
{
public:
		~A();

  	A	&operator= (const A& a);

};


class B
{
public:
	int	i;	 
	A	a;
//	void	operator=(const B &b)
//		{	i = b.i;
//			a = b.a;	}
};

void test( B (*q)() )
{
	B	b;

	b = (*q)();
}
--------------- cut here ------------------
g++ 2.3.3 dies with the message:

1 klamer@mi7 13:35 76> g++ -v -c q.cc
Reading specs from /usr/local/lib/gcc-lib/sun4/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/sun4/2.3.3/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 q.cc /tmp/cca01832.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sun4/2.3.3/cc1plus /tmp/cca01832.i -quiet -dumpbase q.cc -version -o /tmp/cca01832.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
q.cc: In function `void  test (auto class B(*)())':
q.cc:22: Internal compiler error.
q.cc:22: Please report this to `bug-g++@prep.ai.mit.edu'.

Adding the assignment operator in class B (as commented) cures the
problem.

Klamer

PS Error does also occur in genclass generated code, if you use List on
   a class similar to class B.


Newsgroups: gnu.g++.bug
From: weiss@scs.fiu.edu (Mark Weiss)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 20:11:28 GMT

I'm having a problem with version 2.3.3.
The source coude is below.  When the include statement at
(approximately) line 47 is commented out, the program compiles.
When it's in, a get a parse error on the }; at the end of the class.
The included file has only two blank lines, so that's not the problem!

Thanks,

--Mark Weiss
weiss@fiu.edu

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

#include <iostream.h>

void
error( char *s )
{
	cerr << s << "\n";
}

//SF fig3_41
template <class element_type>
class stack
{
    private:
	// The stack is a linked list with no header.

	struct node
	{
		element_type element;
		struct node *next;

		node( element_type e = 0, struct node *n = 0 )
		{
			element = e;  next = n;
		}
	};

	typedef struct node *node_ptr;

	node_ptr stack_top;


    public:
	// Default stack size is meaningless.
	stack( unsigned int max_size = 100 ) : stack_top ( 0 ) { };
	stack( stack & value );

	//Destructor
	~stack( );

	void push( element_type x );
	void pop( );
	element_type pop_and_top( );
	element_type top( );
	int is_empty( ) { return stack_top == 0; }
//STOP
#include "print_stack.cc"		// THIS IS THE PROBLEM
//START

};
//EF

//template <class element_type>
//stack<element_type>::stack( stack & value )
//{
//}
	
//SF fig3_42
template <class element_type>
inline void stack<element_type>::push( element_type x )
{
	node_ptr p = new node( x, stack_top );

	if( !p )
		error( "Out of memory" );
	else
		stack_top = p;
}
//EF

//SF fig3_44
template <class element_type>
inline void stack<element_type>::pop( )
{
	node_ptr p;

	if( is_empty( ) )
		error( "Empty stack" );
	else
	{
		p = stack_top->next;
		delete stack_top;
		stack_top = p;
	}
}
//EF

//SF fig3_45
template <class element_type>//L1
inline element_type stack<element_type>::pop_and_top( )
{
	element_type top_element = top( );

	if( !is_empty( ) )
		pop( );

	return top_element;
}
//EF

//SF fig3_46
template <class element_type>
stack<element_type>::~stack( )
{
	node_ptr p = stack_top;

	while( p )
	{
		node_ptr after_p = p->next;
		delete p;
		p = after_p;
	}
}
//EF

//SF fig3_43
template <class element_type>
inline element_type stack<element_type>::top( )
{
	if( is_empty( ) )
		error( "Empty stack" );

	return stack_top->element;
}
//EF

main( )
{
	stack<int> S;

	for( int i=1; i<=10; i++ )
		S.push( i );
	cout << "Elements pushed\n";
	//S.rec_print_stack( cout );
	cout << "Result from pushing.\n";
	//S.print_stack( cout );
	cout << "Result from pushing.\n";
	while( !S.is_empty( ) )
		cout << S.pop_and_top( ) << "\n";
}



Newsgroups: gnu.g++.bug
From: enewton@uunet.uu.net
Subject: 2.3.3 multiple inheritance: wrong virtuals called
Reply-To: srg!enewton@uunet.uu.net
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Dec 1992 19:12:02 GMT

// gcc version 2.3.3 configured with ./configure sun4 on a Sun IPX.
// compiled with gcc -xc++ bug.c
// running ./a.out yields incorrect output
// I see:
//  D's create
//  D's create
//  D's create
//
// current workaround is to never compile the constructor from
// classes multiply-derived from the same parent in the same source
// file.  On tuesdays. 8-)
//
// -Eric uunet.uu.net!srg!enewton
//

extern "C" {
   void puts(const char *);
}

/*
	A   Q
	 \ /
	  C
	 / \
	D   E

*/

class A
{
 public:
   virtual void f() {}
};

class Q
{
 public:
   virtual void create() { puts("Q's create"); }
};

class C : public A,public Q
{
};

class E : public C
{
 public:
   virtual void create() { puts("E's create"); }
};

class D : public C
{
 public:
   virtual void create() { puts("D's create"); }
};

main()
{
   C * p;
   p = new C; p->create();
   p = new D; p->create();
   p = new E; p->create();
}



Newsgroups: gnu.g++.bug
From: schwartz@loki-gw.den.mmc.com (  Michael Schwartz)
Subject: Problem with function matching rules
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 16:49:48 GMT

There appears to be a bug in function matching rules using conversion
operators to convert class types to built-in types.

The following example fails:

class A
{
  public:
    operator const char * (void) { return "Hello"; }
    A() {}
    ~A() {}
};

main()
{
  A a;
  const char *cp = 1 + a;
  const char *cp2 = a + 1;
}

Output of compile:

Reading specs from /usr/local/lib/gcc-lib/m68k-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/m68k-sun-sunos4.1/2.3.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dmc68000 -Dsun -Dunix -D__mc68000__ -D__sun__ -D__unix__ -D__mc68000 -D__sun -D__unix -D__HAVE_68881__ -D__mc68020__ -Dmc68020 bad_match.cc /usr/tmp/cca02076.i
GNU CPP version 2.3.3 (68k, MIT syntax)
 /usr/local/lib/gcc-lib/m68k-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca02076.i -quiet -dumpbase bad_match.cc -version -o /usr/tmp/cca02076.s
GNU C++ version 2.3.3 (68k, MIT syntax) compiled by GNU C version 2.3.3.
bad_match.cc: In function `int  main ()':
bad_match.cc:14: undefined A operator + ()
bad_match.cc:15: undefined A operator + ()

Newsgroups: gnu.g++.bug
From: root@gwha.com (Super-User)
Subject: c++ bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 00:29:47 GMT

Dear sirs:

I have found a problem with the gnu c++ compiler
while compiling the following construct:

========= contents of file bug.cc =============

class A {
	class B {
		public:
			~B();
	};
};

A::B::~B()
{
}
===============================================
Commands:

gcc -v
Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux/2.3.3/specs
gcc version 2.3.3

gcc bug.cc -c
bug.cc:9: Internal compiler error 346.
bug.cc:9: Please report this to `bug-g++@prep.ai.mit.edu'.


Thanks,  Jon Anderson (jon@gwha.com)


Newsgroups: gnu.g++.bug
From: eks@vki68.aar-vki.DK (Eigil Krogh Sorensen)
Subject: groff-1.06 and gcc-2.3.3 status/information
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 21:11:26 GMT

This is for information not a bug report.

System:
Motorola sysV68 R3V5.1 (mvme147/68030 (mot330) based).

Groff-1.06 has now been made with gcc-2.3.3, installed and tested.

It seems to work.

The only problem so far was "anonymous unions" with gcc-2.3.3 (C++).



- Eigil


Newsgroups: gnu.g++.bug
From: jimc@pic.ucla.edu
Subject: Internal err 145 when ordinary method defined as template
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 00:35:20 GMT

// bug20.C -- Method of ordinary class defined as template: int err 145

/* Gnu g++ v2.3.3 for Sparc-SunOS-SunOS v4.1.1
A member function of a non-template class is defined as a template.
This gives the compiler internal error 145.

bug20.C:11: Internal compiler error 145.
bug20.C:11: Please report this to `bug-g++@prep.ai.mit.edu'.

James F. Carter        (213) 825-2897
UCLA-Mathnet;  6221 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90024-1555
Internet: jimc@math.ucla.edu            BITNET: jimc%math.ucla.edu@INTERBIT
UUCP:...!{ucsd,ames,ncar,gatech,purdue,rutgers,decvax,uunet}!math.ucla.edu!jimc

 */

struct gorf {
    int stuff;
    void snarf();
};

template <class T> void gorf::snarf()	//Internal Error 145
{ return; }

Newsgroups: gnu.g++.bug
From: fritz@mtl.mit.edu (Frederick Herrmann)
Subject: templates and const
Organization: MIT Microsystems Technology Laboratories
Distribution: gnu
Date: Mon, 11 Jan 1993 19:08:09 GMT

I'm having trouble with type unification for templates with const
args.  We are running g++ 2.3.3 under SunOS 4.1.3 and Ultrix 4.2

The FAQ says there are still some problems with templates.  Is this a
real bug or am I doing something wrong?

			Thanks,

				- Fritz
				  fritz@mtl.mit.edu

#include <iostream.h>

// This code produces type unification errors when
// CONST is defined to be const, but works fine when
// compiled with -DNOCONST

#ifdef NOCONST
#  define CONST /*blank*/
#else
#  define CONST const
#endif  

template<class C> void cpy( C* to, CONST C* from)
{
  while ( *to++ = *from++);
}

int main( int argc, char** argv)
{
  char tobuf[9];
  CONST char frombuf[] = "Testing.";

  cpy( tobuf, frombuf);
  
  cout << tobuf << '\n';
}

Newsgroups: gnu.g++.bug
From: conrad@cse.ucsc.EDU (Al Conrad)
Subject: g++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 00:19:59 GMT

Hi.  I am having difficulty since a new version of the compiler was
installed on our system.  Could you please tell me what the following
undefined symbols indicate:
   ___ls__FR7ostreamc 
   ___ls__FR7ostreami 
   ___ls__FR7ostreamPCc 

Thansk you very much,

Al Conrad

Newsgroups: gnu.g++.bug
From: jeff@dcs.warwick.ac.UK (Jeff Smith)
Subject: libg++ on sun-3 reveals problem with g++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 17:47:51 GMT

The following program generates the errors:

/tmp/K.C: In function `double  hypot (double, double)':
/tmp/K.C:21: warning: float or double assigned to integer data type
/tmp/K.C:21: warning: float or double assigned to integer data type

However, these conversions should not have been selected at all, and
cfront-3.0.1 correctly calls the double sqrt (double x) routine. The
problem comes to light on a sun-3 when you make libg++, because the
math-68881.h header contains equivalent code, but it would appear that
all recent g++ compilers actually have the bug. I compiled this
particular example on a sun-4 with gcc-2.3.3. Any ideas anyone...?
 --------------------------------------------------------------------------



class Integer
{
public:
                  Integer(long);
                  Integer(const Integer&);
                  operator long() const;
                  operator double() const;
};

extern Integer  sqrt(const Integer&);  

extern "C" {			 
   extern double sqrt (double x);

}

/*extern "C" { */
    double hypot ( double x,  double y)
      {
	double temp= x*x + y*y;
	temp = sqrt(temp);
	return temp;
      }

/*}*/



--
Jeff Smith, Computer Science, Warwick University, Coventry, CV4 7AL, England
jeff@dcs.warwick.ac.uk	phone: +44 203 523485	fax: +44 203 525714


Newsgroups: gnu.g++.bug
From: bard%cutter@icarus.ssd.loral.com (J H Woodyatt)
Subject: GCC-2.3.3: undocumented -fno-builtin not honored
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 04:16:49 GMT

The flag is defined in cp-decl2.c, but it isn't honored anywhere.  It
*is* honored by the C front end.  The flag is totally missing from the
Objective-C front end (but then, it might not have `builtin' functions
-- I haven't looked.)

Yeah, I know this isn't a `bug,' technically speaking, but it would be
really nice if the feature was enabled in the FSF sources.

If it isn't going to happen until some intrepid hacker sends in a patch
for it, I'll jump right to it -- otherwise, I do have a work-around
that saves me from the annoying warnings.


--
+---------------------------+  ``Man has not a single right which is
| J H Woodyatt              |  the product of anything but might.''
| bard@cutter.ssd.loral.com |                           -- Mark Twain
+---------------------------+  

Newsgroups: gnu.g++.bug
From: girod.tms_os.kpd@kilohp.kiloapo.ts.tele.NOkia.FI (unknown)
Subject: Signal 6 with pure virtual destructor. g++ 2.3.3
Reply-To: marc.girod@ntc.nokia.com
Organization: /user/girod/.organization
Distribution: gnu
Date: Mon, 4 Jan 1993 18:18:05 GMT

Hi netters!

I get a core dump from the following code, if in separate files,
although everything goes fine if they are grouped together.

-b.h--------------------------------------------------------
class B {
  public:
    virtual ~B() = 0;
};

-b.C--------------------------------------------------------
#include <iostream.h>
#include "b.h"

B::~B() { 
	cout << "B::~B() for: " << this << endl;
}

-main.C-----------------------------------------------------
#include <iostream.h>
#include "b.h"

class A: public B {
  public:
	~A();
};

A::~A() {
	cout << "A::~A() for: " << this << endl;
}

main() {
	A fred;

	cout << "That's all Folks!..." << endl;
	return 0;
}

-test--------------------------------------------------------
> ab
That's all Folks!...
A::~A() for: 0x68fad4d8
Abort(coredump)

...and under gdb:
Program received signal 6, Aborted
0x158c0 in ___stdio_unsup_1 ()

As I said, this is ok:

-main.C------------------------------------------------------
#include <iostream.h>

class B {
  public:
    virtual ~B() = 0;
};

B::~B() { 
	cout << "B::~B() for: " << this << endl;
}

class A: public B {
  public:
	~A();
};

A::~A() {
	cout << "A::~A() for: " << this << endl;
}

main() {
	A fred;

	cout << "That's all Folks!..." << endl;
	return 0;
}

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

Best Regards!
--
+-----------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
| TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
| SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
|    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
+-----------------------------------------------------------------------------+

Newsgroups: gnu.g++.bug
From: rwk@integra.UUCP (Richard W. Kreutzer)
Subject: Previous bug report on virtual functions.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 22:54:38 GMT

I forgot to mention that I am running gcc-2.3.2 on SunOS 4.1.1

Thanks,
Dick

Newsgroups: gnu.g++.bug
From: tiller@quattro.NOsubdomain.NOdomain (Mike Tiller)
Subject: Re: "warning: dbx info for template class methods not yet supported"
Organization: University of Illinois at Urbana
Distribution: gnu
Date: Wed, 6 Jan 1993 17:15:21 GMT

gs4t@virginia.edu (Gnanasekaran  Swaminathan) writes

> tmb@idiap.CH (Thomas M. Breuel) writes:
>: I'm pretty tired of seeing this warning message again and again when
>: compiling my code with gcc 2.3.2.

>You can edit your *compilation* buffer and remove unnecessary
>warnings and errors. After that to go to the first error, do
>evaluate (next-error t). Following errors can be reached in the
>usual way. 

Or you can do what I do, when you compile g++ take the warning
out of dbxout.c (it's easy to find).  After the first 10,000 times
seeing this message I got the idea.  Of course, if other people
will be using it you should probably warn them.

Michael Tiller

Newsgroups: gnu.g++.bug
From: werner@ast1.uibk.ac.at ( Werner Benger     )
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 12:20:25 GMT

 I am very sorry to tell you, that there are some errors remaining in
GCC 2.3.3. 
  GCC has problems, if the constructor of a nested class
is called to generate an object as parameter to another class. If
a temporary object is used, there are no troubles.

/****************************************************************************/
class	A
{
	class	B
	{
	public:	B(int i,float k);
	};

public:	A(int,B&);
};

A a(1,A::B(8,4.56));	// <---- no constructor named `B' in visible scope
			//	 invalid functional cast

A::B	tmp(8,4.56);		// <---- This is ok !
A	b(1,tmp);

/*****************************************************************************/
 It is not possible to define a pointer to a class member as function
parameter.
/*****************************************************************************/
struct X
{
	int a,b;
};

void x(int X::*i)	// <--- parse error before `i'
{
	int X::*j=i;	// <--- `i` undeclared
}

main()
{
	int X::*i=&X::a;	// ( This line is ok for GCC )
	x(&X::a);
}
/*****************************************************************************/

	Best greetings from werner@ast1.uibk.ac.at


Newsgroups: gnu.g++.bug
From: vtessier@vela.acs.oakland.edu (Vince Tessier)
Subject: libg++-2.3 fails "make check" (sparc-sun-sunos4.1.1)
Summary: "make check" fails, but no problem?
Organization: Oakland University, Rochester MI.
Distribution: gnu
Date: Sun, 10 Jan 1993 00:55:31 GMT

Hardware: SPARCstation 1
Software: SunOS 4.1.1, gcc version 2.3.3

I've recently installed gcc version 2.3.3 (with fixincludes) & libg++-2.3
with what seems to be no problems, except that libg++-2.3 failed 
"make check" as follows:

cd test; make check ...
make[6]: Entering directory `/usr/gnu/src/libg++-2.3/libg++/iostream/test'
	<<<successful tests deleted>>>
gcc -O2 -nostdinc++ -I. -I../.. -I./.. -I./../stdio -I./../../g++-include \
	-c tformat.C
gcc -o tformat tformat.o ../libio.a ../../libg++.a
./tformat
Error in line 3490 using "%.5G".  Result is "5.3770E+14"; should be: \
	"5.377E+14".
Encountered 1 errors in 3988 tests.
make[6]: *** [check-tformat] Error 1
make[6]: Leaving directory `/usr/gnu/src/libg++-2.3/libg++/iostream/test'

I went ahead and installed libg++ anyway, and for the first time ever
was able to build and install groff with no problems.

Is the "make check" error above a real or pseudo error?  I don't recall
seeing this problem reported before.

-- 
	Vince Tessier (vtessier@vela.acs.oakland.edu)
Mort Sahl: General, aren't you supporting Castro by smoking that Havana cigar?
Alexander Haig:	I prefer to think of it as burning his crops to the ground.
(from an interview of Mort Sahl on National Public Radio, 23nov91)

Newsgroups: gnu.g++.bug