HDTenEightyP/NetNews huggingface dataset:
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: "warning: dbx info for template class methods not yet supported"
Reply-To: tmb@idiap.ch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 02:03:59 GMT

================================================================
In file included from Parameters.cc:1:
Parameters.h:46: warning: dbx info for template class methods not yet supported
================================================================

I'm pretty tired of seeing this warning message again and again when
compiling my code with gcc 2.3.2. It gets particularly annoying when I
compile a bunch of files and get an error message in one of the last
files, since under Emacs, I have to step through all the warning
messages before finally getting to the real error message.

This warning should either be eliminated completely, or there should
be an option to disable it selectively ("-w" is not a choice, since I
do want to get other kinds of warnings).

					Thomas.

Newsgroups: gnu.g++.bug
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Subject: gcc (C++) 2.3.2 generates bad assembly language output (redefined symbol)
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
Distribution: gnu
Date: Mon, 4 Jan 1993 16:31:59 GMT

[sorry for the duplicate posting, but this message hasn't made it to
gnu.g++.bug under the correct "Subject:" line apparently due to some
gateway problems at GNU]

gcc -v -c foo.cc
Reading specs from /sym/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
gcc version 2.3.2
 /sym/gnu/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 foo.cc /local/tmp/cca11717.i
GNU CPP version 2.3.2 (sparc)
 /sym/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/cc1plus /local/tmp/cca11717.i -quiet -dumpbase foo.cc -version -o /local/tmp/cca11717.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
 as -o foo.o /local/tmp/cca11717.s
as: "/local/tmp/cca11717.s", line 96: error: redefinition of symbol "_lookup"
gcc: foo.o: No such file or directory

== foo.cc ======================================================
#include <std.h>

template <class Y>
struct NameValuePair {
	char *name;
	Y y;
};

template <class Y>
inline Y lookup(NameValuePair<Y> *data,char *name) {
	while(data->name) {
		if(!strcmp(data->name,name)) return data->y;
		data++;
	}
	abort();
	return data->y;		// to keep GCC happy
}

template <class T>
void swap(T &x,T &y) {
	T temp = x;
	x = y;
	y = temp;
}

typedef char (*canonicalizer)(char &,float *);

NameValuePair<canonicalizer> canonicalizers[] = {
	{0,0}
};

typedef float (*extractor)(float &image,float g=2.0);

NameValuePair<extractor> extractors[] = {
	{0,0}
};

void foo() {
	canonicalizer canonicalize = lookup(canonicalizers,(char*)"foo");
	extractor extract = lookup(extractors,(char*)"bar");
}

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




Newsgroups: gnu.g++.bug
From: eks@vki68.aar-vki.DK (Eigil Krogh Sorensen)
Subject: Information.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 15:24:58 GMT

Enclosed is an e-mail from jclark.com!jjc.

The changes he suggests helped so gcc-2.3.3 could compile errarg.cc
from groff-1.06 without errors.

I just thought this could be of interest to others.

(Now there is problems with groff-1.06 - lex.cc as reported in another
e-mail)


Best,
Eigil Krogh Sorensen.




>From jclark.com!jjc Wed Jan  6 13:42:00 1993
Return-Path: <jclark.com!jjc>
Received: by vki68.aar-vki.dk (Smail3.1.28.1 #16)
	id m0n9b17-0000t4C; Wed, 6 Jan 93 13:41 GMT
Received: from jclark.com by dkuug.dk with SMTP id AA05056
  (5.65c8/IDA-1.4.4j for <eks@vki68.aar-vki.dk>); Wed, 6 Jan 1993 13:25:06 +0100
Received: by jclark.com (4.1/SMI-4.1)
	id AA11218; Wed, 6 Jan 93 12:23:45 GMT
Date: Wed, 6 Jan 93 12:23:45 GMT
From: jjc@jclark.com (James Clark)
Message-Id: <9301061223.AA11218@jclark.com>
To: eks@vki68.aar-vki.dk
Subject: error while making groff-1.06 with gcc-2.3.3
X-Charset: US-DK
X-Char-Esc: 29
Status: RO

gcc on your system appears not to be able to handle anonymous unions
correctly.  You could try changing errarg.h so it doesn't use a union:
change

  union {
    const char *s;
    int n;
    char c;
    double d;
  };

to

  const char *s;
  int n;
  char c;
  double d;

in errarg.h.  This would be inefficient, but it might work.


Newsgroups: gnu.g++.bug
From: rwk@integra.UUCP (Richard W. Kreutzer)
Subject: enum bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 23:48:34 GMT

The following code won't compile with gcc-2.3.2 under SunOS 4.1.1:

	class foo {
	  enum {d, e, f=e+2};
	};

	$ gcc -c bug.cc
	bug.cc:2: `e' undeclared, outside of functions
	bug.cc:2: enumerator value for `f' not integer constant

It works if the enum is global.  Shouldn't it also work in class scope?
Is there a work-around?

Regards,
Dick

Newsgroups: gnu.g++.bug
From: zougas@me.utoronto.ca (Tom Zougas)
Subject: fixed bug with templates
Organization: UofT Mechanical Engineering
Distribution: gnu
Date: Tue, 5 Jan 1993 07:16:06 GMT

version: gcc-2.3.3
system:  SPARC SunOS4.1.1

In an earlier posting, I had asked if static variables in class templates
should be initializeable at the global scope level.  I found I could only
get them initialized within a function call. This problem has been fixed.
By using 'gnu-ld' as the loader, static variables in template classes are
now properly initialized. 'ld' that comes with my system (SPARC SunOS4.1.1)
did not do it properly.

-- 
===========================================================================
Tom Zougas					      zougas@me.utoronto.ca
Engineering Mechanics and Design Laboratory		       416-978-1281
Dept of Mechanical Engineering, University of Toronto,      Toronto, CANADA

Newsgroups: gnu.g++.bug
From: jjc@jclark.com (James Clark)
Subject: internal error 145
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 12:19:04 GMT

$ cat bug2.cc
template<class T>
class A {
public:
  A();
};

template<class T>
A<class T>::A()                 // incorrect
{
}

$ gcc -v -c bug2.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 bug2.cc /usr/tmp/cca06801.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca06801.i -quiet -dumpbase bug2.cc -version -o /usr/tmp/cca06801.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.2.
bug2.cc:0: conflicting types for `T'
bug2.cc:7: previous declaration of `T'
bug2.cc:9: Internal compiler error 145.
bug2.cc:9: Please report this to `bug-g++@prep.ai.mit.edu'.
$ 

Newsgroups: gnu.g++.bug
From: leopold@informatik.uni-kl.DE (Thomas Leopold)
Subject: Bug report gcc version 2.3.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 15:49:40 GMT

Bug report
==========

Program: gcc version 2.3.3 (g++)
Machine: Sun Sparc ELC
OS:      Sun-OS 4.1.1

When compiling the program set.c with

g++ set.c

the following error message occurs:

set.c: In method `int  Set<int>::size ()':
set.c:9: Internal compiler error 162.
set.c:9: Please report this to `bug-g++@prep.ai.mit.edu'.

set.c
-----------------------------------------------------------------------
template <class Element>
  class Set {
    Element**  _set ;
    int        _size ;
    int        _max ;
    static int chunk ;
  public:
               Set() ;
    int        size() { return _size ; }
    Set&       insert( Element& ) ;
    Set&       remove( Element& ) ;
    int        contains( Element& ) ;
  } ;


// ============= class member functions for class Set =============


template <class Element>
  Set<Element>::Set()
  {
    _max = chunk ;
    _size = 0 ;
  }

template <class Element>
   Set<Element>::size()
  {
    return _size ;
  }


int main( void )
{
  Set<int> a ;
  int i ;


  return 0 ;
}
-----------------------------------------------------------------------

I know that this program is not correct, but I think this is not the
error message one expects.

Thomas Leopold, University of Kaiserslautern, Germany
leopold@informatik.uni-kl.de


Newsgroups: gnu.g++.bug
From: jjc@jclark.com (James Clark)
Subject: initializer for static class member array
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 11:03:05 GMT

I think g++ is wrong to complain here:

$ cat bug4.cc
struct A {
  static int v[];
};

int A::v[1] = { 1 };

$ gcc -c -v bug4.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 bug4.cc /usr/tmp/cca29460.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca29460.i -quiet -dumpbase bug4.cc -version -o /usr/tmp/cca29460.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.2.
bug4.cc:5: invalid initializer
bug4.cc:2: storage size of `v' isn't known
$
 

Newsgroups: gnu.g++.bug
From: hoberoi@limerick.cbs.umn.edu (Himanshu Oberoi)
Subject: Compiler generates inclrrect code IBM RS6000 AIX 3.2.junk
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 10 Jan 1993 19:29:40 GMT

Re: g++ compiler problem on IBM RS6000
Reply-To: hoberoi@limerick.cbs.umn.edu


I finally figured out the problem It is reproducible
on our machine The example is at the end of this message

This is the description of the problem I posted :
--------xxxxx---------------------------------------------
Well I went back and reinstalled gcc2.2.2 and libg++2.2

Problem 1. assembler code problem

with g++ 2.3.3

	.extern .error__C6StringPCc
	.csect _Data.rw_MPlex.rw_cc_Data.ro_MPlex.ro_cc 	I@[RO]
								 ^^^^^^^^^

and with g++ 2.2.2

	.extern .error__C6StringPCc
	.csect _Data.rw_MPlex.rw_cc_Data.ro_MPlex.ro_cc \[RO]
	.align 2

 								^^^ note that there are 
	some control characters here
Solution: (both 2.3.3 and 2.2.2
	compile with S flag, hand edit file, assemble and the program
works !!!


Problem 2. undefined symbols

the problems with the undefined symbols

g++ 2.3.3 libg++.2.3

.__ls__FR7ostreamPCc
.__ls__FR7ostreamf


g++ 2.2.2 libg++2.2.2

no undefined symbols
Successs !!

Next step, Compile libg++2.2.2 with gcc 2.3.3 and see if the ostream 
stuff still shows up
--------------------------------------------------------------------

************************************************* 10 Jan 92
Ok Guess what I know what causes the problem I may be all wrong but
what the heck....

try 
genclass fooo ref MPlex
genclass fooo ref Plex
genclass fooo ref defs

do the mandatory edit to fooo.defs.h
then 
g++ -c fooo.MPlex.cc
watch them errors.
next 
g++ -S fooo.MPlex.cc

look at the assembly file there is the ^H and some blanks next to the 
.csect _fooo ........ [RO]


What causes this ? 
A base of 4 or 5 characters. REALLY it is true. I tried the following
strings in place of 
fooo 
aaaa 
aaaaa 
bbbb 
bbbbb
Goat
 
all give the same error.
Odd :) 

I have tried this with gcc 2.2.2 anf libg++2.2

himanshu ---
--
/*-hoberoi@limerick.cbs.umn.edu--612-624-4938-Univeristy-of-Minnesota-St-Paul--*/

Newsgroups: gnu.g++.bug
From: stravers@muresh.et.tudelft.nl (Paul Stravers)
Subject: public in derived clashes with private in base class
Reply-To: Paul Stravers <stravers@donau.et.tudelft.nl>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 01:59:14 GMT

This reports a bug in g++ version 2.3.1 and 2.3.3.

If a derived class has a method that has the same name as a private member in
its base class then g++ does not allow access to the public method. Example:
------------------------------------------------------------------------------
class base
{
private:
   char *hello;
};

class derived: public base
{
public:
   char *hello() {return "hello, world!";}
};

main()
{
   derived thing;
   thing.hello();
}
------------------------------------------------------------------------------
Compiling this code gives:

   % g++ -v
   Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/specs
   gcc version 2.3.3
   % g++ test.C
   test.C: In function `int  main ()':
   test.C:16: member `hello' is private

Cfront does not complain, but then again: ``Lang leve GNU!''

Paul Stravers
-- 
Delft University of Technology      |  email stravers@donau.et.tudelft.nl
Faculty of Electrical Engineering   |  fax +31 15 786190
Mekelweg 4                          |  ph. +31 15 786280
2628 CD   Delft                     |
the Netherlands                     |

Newsgroups: gnu.g++.bug
From: norene@iscnvx.lmsc.lockheed.COM (Norene T. Graham)
Subject: "template" supported?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 08:43:59 GMT

I am using g++ 1.40.3 on a Sun SPARC2 running SunOS 4.1.2.

I am using template in my code:

	template<class X>

and the compiler complains:

	parse error before `<'

Will template be supported in a later release of g++?

--Norene T. Graham
  norene@iscnvx.lmsc.lockheed.com
  Office: 1 408 742-0518
  Fax:    1 408 742-2563

Newsgroups: gnu.g++.bug
From: jbg@qualcomm.com (Jeff Gehlhaar)
Subject: Enum bug, affects library
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 02:20:50 GMT

// An enum problem: Internal compiler error 73.

// This replaces a problem with enums (bug005) reported previously.  That
// suicide attempt no longer happens; now it gets an ``internal compiler
// error'' instead.  The code is extracted from the G++ include files.

// The result of ``g++ -v -fshort-enums bug016.cc'' is attached below.

// -- Greg

// from <streambuf.h>
class ios {
  public:
    enum { skipws=01, left=02, right=04, internal=010,
           dec=020, oct=040, hex=0100,
           showbase=0200, showpoint=0400, uppercase=01000, showpos=02000,
           scientific=04000, fixed=010000, unitbuf=020000, stdio=040000,
           dont_close=0x80000000 //Don't delete streambuf on stream destruction
           };

};

// from <iostream.h>
inline ios& dec(ios& i)
{ i.setf(ios::dec, ios::dec|ios::hex|ios::oct); return i; }

/* Compiler output follows:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 bug016.cc
/usr/tmp/cca29216.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus
/usr/tmp/cca29216.i -quiet -dumpbase bug016.cc -version -fshort-enums -o
/usr/tmp/cca29216.s
GNU C++ version 2.3.3 (sparc) compiled by CC.
bug016.cc: In function `class ios& dec (class ios&)':
bug016.cc:25: Internal compiler error 73.
bug016.cc:25: Please report this to `bug-g++@prep.ai.mit.edu'.
Compiler output above */


======================================================
Jeff Gehlhaar           Qualcomm Inc,  
jbg@qualcomm.com        San Diego, CA, USA
(619) 597-5241          "The Elegant Solution...."
======================================================


Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Bug in accessing protected member
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 09:48:05 GMT

This problem has been fixed, and should not exist in gcc 2.3.2 and on.

Thanks for the report.

> Posted-Date: Mon, 15 Jun 92 13:12:32 PDT
> Message-Id: <199206152012.AA07127@aerospace.aero.org>
> From: gorlick@aero.org
> To: bug-gcc@prep.ai.mit.edu
> Date: Mon, 15 Jun 92 13:12:32 PDT

> The compiler produces an error message when a derived class tries to  
> assign to a protected member of a base class using a qualified name.

> /* Start of example */
> class A
> {
>  public:
>   A() {}
>   ~A() {}

>  protected:
>   int a;
> };

> class B : public A
> {
>  public:
>   B() {}
>   ~B() {}
>   void foo(int);
> };

> void
> B::foo(int i)
> {
>  A::a = i; /* Error message issued for this assignment. */
> }
> /* End of example */

> The compiler output is:
> gcc -v -c /tmp/foo.cc
> gcc version 2.2.1
>  /usr/aero/xlib/gcc-lib/next/2.2.1/cpp -lang-c++ -v -undef  
> -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dmc68000 -Dm68k -DNeXT  
> -Dunix -D__MACH__ -D__mc68000__ -D__m68k__ -D__NeXT__ -D__unix__  
> -D__MACH__ -D__mc68000 -D__m68k -D__NeXT -D__unix -D__MACH__  
> /tmp/foo.cc /usr/tmp/cc002635.i
> GNU CPP version 2.2.1 (68k, MIT syntax)
>  /usr/aero/xlib/gcc-lib/next/2.2.1/cc1plus /usr/tmp/cc002635.i -quiet  
> -dumpbase foo.cc -version -o /usr/tmp/cc002635.s
> GNU C++ version 2.2.1 (68k, MIT syntax) compiled by GNU C version  
> 2.2.1.
> /tmp/foo.cc: In method `void  B::foo (int)':
> /tmp/foo.cc:22: invalid lvalue in unary `&'

Newsgroups: gnu.g++.bug
From: bashford@scripps.edu
Subject: g++-2.3.3 on Dec Alpha gets internal error on ?: expression
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 11 Jan 1993 13:10:00 GMT

I have built gcc on the dec alpha using "configure --target=alpha-dec-osf1"
The compiler built and compiled itself.  It did not pass the stage3
stage2 comparison test, but this seems to be because the native assembler
puts strings in the object files giving the name of the /tmp/cc*.s files
which, of course differ each time.

My machine identifies itself this way when I log in:
  DEC OSF/1 T1.2-1  (Rev. 12); Tue Jan 05 15:04:54 PST 1993
  DEC OSF/1 T1.2-1 Worksystem Software (Rev. 11)
and the arch command returns "alpha".


When I try to build libg++-2.3, I get an internal compiler error when
from line 90 of libg++/src/builtin.h while compiling Obstack.cc

The error can be reproduced from the following four line fragment:
% cat bug.cc 
inline double abs(double arg)  
{ 
  return (arg < 0.0)? -arg : arg; 
} 


And here is the crash:

% gcc -v -c bug.cc 
Reading specs from /usr/local/lib/gcc-lib/alpha-dec-osf1/2.3.3/specs 
gcc version 2.3.3 
 /usr/local/lib/gcc-lib/alpha-dec-osf1/2.3.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -D__osf__ -D__alpha -D__alpha__ -D_LONGLONG -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__ -D__osf__ -D__alpha -D__alpha__ -D___LONGLONG__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__ -D__unix -D__osf__ -D__alpha -D__alpha__ -D___LONGLONG -D__SYSTYPE_BSD -D___SYSTYPE_BSD -D__LANGUAGE_C_PLUS_PLUS__ -D__LANGUAGE_C_PLUS_PLUS bug.cc /usr/local/lib/tmp/cc008725.i 
GNU CPP version 2.3.3 
 /usr/local/lib/gcc-lib/alpha-dec-osf1/2.3.3/cc1plus /usr/local/lib/tmp/cc008725.i -quiet -dumpbase bug.cc -version -o /usr/local/lib/tmp/cc008725.s 
GNU C++ version 2.3.3 compiled by GNU C version 2.3.3. 
bug.cc: In function `double  abs (double)': 
bug.cc:3: Internal compiler error. 
bug.cc:3: Please report this to `bug-g++@prep.ai.mit.edu'. 
% 


It goes away if you replace the ?: statement with something simpler.

Don Bashford
bashford@scripps.edu

Newsgroups: gnu.g++.bug
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Subject: Problem with optimized inline functions
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 22:25:59 GMT

The following inline function taken from the file BitString.h in the
libg++-2.3 distribution does not compile properly with gcc -O (version
2.3.3) on a HP Apollo 9000 series 700 running hpux 8.07:

inline BitString shorttoBitString(unsigned short w) return r
{
   r.rep = BStr_alloc(0, &w, 0, BITSTRBITS, BITSTRBITS);
}

Routines (e.g., tBitString) using this inline function dump core.  The
problem seems to be in the evaluation of the address of w.  Using a
temporary variable for w circumvents the problem:

inline BitString shorttoBitString(unsigned short w) return r
{
   unsigned short u = w;
   r.rep = BStr_alloc(0, &u, 0, BITSTRBITS, BITSTRBITS);
}

There is a similar problem taking the address of a character variable
in the module String.h.

Dave Anglin
National Research Council of Canada

Newsgroups: gnu.g++.bug
From: hugh@sivs.COM (Hugh Daschbach)
Subject: Re:  Floating point exception during 2.3.1/2.3.2 build (i386-sysv3)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 22:56:22 GMT

> 2.3.3 is the current version of GCC 2.x.  Building an earlier version
> is not useful at this point.

I downloaded gcc-2.3.3.diff.Z, patch, and rebuilt.  Same problem.

Original problem report follows:

Just tried upgrading an i386-sysv3 (ESIX SysV R3.2) from 2.2.2 to
2.3.2 using patches downloaded from ftp.uu.net.  At the end of the
phase 1 build, "enquire" fails leaving the error message "***
Unexpected signal at point 19" at the tail of float.h.

I backed off to 2.3.1.  Same result.  I tried compiling with pcc
instead of the 2.2.2 gcc.  Same result.

Here's the compile of enquire.o:

./xgcc -B./  -DIN_GCC   -g     -DNO_MEM -DNO_STDDEF -DNO_LONG_DOUBLE_IO -O0 -I. -c ./enquire.c

Enclosed is a bt from running enquire under gdb:

$ gdb enquire
GDB 3.5, Copyright (C) 1989 Free Software Foundation, Inc.
There is ABSOLUTELY NO WARRANTY for GDB; type "info warranty" for details.
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "info copying" to see the conditions.
Reading symbol data from /u/gnu/gcc-2.2.2/enquire...done.
Function abort not defined.
Type "help" for a list of commands.
(gdb) r -f
Starting program: /u/gnu/gcc-2.2.2/enquire -f
/* float.h */
#ifndef _FLOAT_H___
#define _FLOAT_H___
/* Produced by enquire version 4.3, CWI, Amsterdam */

   /* Radix of exponent representation */
#define FLT_RADIX 2
   /* Number of base-FLT_RADIX digits in the significand of a float */
#define FLT_MANT_DIG 1
   /* Number of decimal digits of precision in a float */
#define FLT_DIG 0

Program received signal 8, SIGFPE
0x2d74 in fDiff (a=-2, b=0.375) (enquire.c line 2117)
2117	Number Diff ARGS2(Number, a, Number, b){Number r; Store(a-b, &r); return (r); }
(gdb) bt
#0  0x2d74 in fDiff (a=-2, b=0.375) (enquire.c line 2117)
#1  0x4201 in fprop (bits_per_byte=8) (enquire.c line 2327)
#2  0x7bf in main (argc=2, argv=(char **) 0x7ffffea4) (enquire.c line 730)
(gdb) c
Continuing.
*** Unexpected signal at point 19

/* For hints on dealing with the problem above
   see the section 'TROUBLESHOOTING' in the file ./enquire.c */

Program exited with code 01.
(gdb) q


I haven't a clue as to where to start looking for the problem.  If you
need any more documentation, please let me know.
__
Hugh Daschbach                  hugh@sivs.com
Member of the League for Programming Freedom

Newsgroups: gnu.g++.bug
From: ged@cs.uq.oz.au
Subject: problems with release 2.3.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 20:45:42 GMT

Hi. I am having problems with the latest release of g++. My program used to 
compile and run with no errors under an earlier release (I think it was 2.2.2)
Now I get a whole bunch of errors complaining about classes having virtual
functions when they clearly don't. At first I thought it was the latest changes 
I had made to the code. But the earlier version of my code does the same thing.

It also falls over on one peice of code:

g++ -DTESTDATABASE=1 -DINTERACTIVE=1 -DSTATISTICS=1 -DENCODE=1  -DENCODE_SEARCH=1 -c chesstyp.cc 
chesstyp.cc: In function `void  _GLOBAL_$I$__eq__FRC6stringPCc ()':
chesstyp.cc:23: Internal compiler error.
chesstyp.cc:23: Please report this to `bug-g++@prep.ai.mit.edu'.
*** Error code 1
make: Fatal error: Command failed for target `chesstyp.o'


Are you aware of similar problems. I am thinking about going back to the old
release.

Thanks.

Cheers, Gerard.

Newsgroups: gnu.g++.bug