HDTenEightyP/NetNews huggingface dataset:
From: arnaud@lamisun.epfl.ch ((Pierre Arnaud))
Subject: g++ 2.3.2, exceptions, constructors and delete
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 13:35:47 GMT

Hi !

I have just ported g++ 2.3.2 on my Smaky (a Swiss computer
using a 68020 and running a Swiss real time kernel). I enjoyed
the many improvement you added and very much appreciated that
some known bug have been fixed. But... I stumbled across some
new problems. I don't know if these are well known or if they
aren't bugs at all, but I have posted three problems below.


I tried to compile this small example :

---cut
class X {
  // ...
public:
  void operator delete (void*, long);
};
---cut

and I got an error saying that "operator delete cannot
be overloaded". Strange indeed, because Stroustrup says it
is possible (C++ prog lang, 2nd ed, section r.12.4, p.577)
or haven't I got it the right way ?


Well, I heard that the exceptions didn't work fine, but is
this to say that they don't work at all ? I tried following :

--cut
  try { } catch (...) { throw; }
--cut

and compiled it with the -fansi-exceptions flag, but all I
got was a strange error saying that "cannot convert a pointer
of type `ExceptionHandler' to a pointer of type `'". It is
rather explicit, isn't it ? (-:


Another problem, when calling a function with a class as a
parameter, I get some trouble :

---cut
class X {

public:
  X () { printf ("construct\n"); }
  ~X () { printf ("destroy\n"); }
};

void foo (X x) { printf ("foo\n"); }

int main ()
{
  foo (X ());
  return 0;
}
---cut

I expected to get the messages "construct", "foo" and "destroy",
but I get "destroy" twice. In fact, the destructor gets called
within `foo' and within `main'. Why ?

Could you please have a look at these small examples and give
me some feed-back ? I would be pleased if you could fix these
small problems. I am highly interested in the exception
mechanisms of g++ !


I wich you Marry Chrismas and a happy new year !!!

  Pierre ARNAUD


Pierre ARNAUD :: EPSITEC-system SA :: CH-1437 Suscevaz, SWITZERLAND
  arnaud@lamisun.epfl.ch :: Swiss Federal Institute of Technology
          "There is always one more bug." (Murphy's law)


Newsgroups: gnu.g++.bug
From: gs4t@kelvin.seas.virginia.edu (Gnanasekaran  Swaminathan)
Subject: Fix for overloaded postfix increment decrement bug in gcc2.3.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 14:56:25 GMT

A patch that fixes the overloaded postfix increment decrement
bug in gcc 2.3.3 follows an example:

The correct output should be
++X 1
X++ 1 0
++X 3
X++ 3 1
Y++ 100 0
++Y 102
++Y 103
Y++ 103 10


#include <iostream.h>

class X {
    int i;
public:
    X (): i(0) {}

    X& operator ++ ()
 	{ ++i; cout << "++X " << i << endl; return *this; }
    X& operator ++ (int j=2)
	{ cout << "X++ " << i << ' ' << j << endl; i++; return *this; }
};

class Y {
    int i;
public:
    Y (): i(100) {}

    friend Y& operator ++ (Y& y)
 	{ ++y.i; cout << "++Y " << y.i << endl; return y; }
    friend Y& operator ++ (Y& y, int j)
	{ cout << "Y++ " << y.i << ' ' << j << endl; ++y.i; return y; }
};

main()
{
    X x;
    ++x;
    x++;

    x.operator ++ ();
    x.operator ++ (1);

    Y y;
    y++;
    ++y;

    operator ++ (y);
    operator ++ (y, 10);
}

ChangeLog:

Tue Dec 29 19:36:26 EST 1992 Gnanasekaran Swaminathan (gs4t@virginia.edu)

	* cp-method.c (build_opfncall): If type of xarg1 is an aggregate,
	then set xarg2 to integer_zero_node for postfix increment and 
	decrement expressions as required by ARM p338-339.

*** cp-method.c.orig	Tue Dec 29 18:55:41 1992
--- cp-method.c	Tue Dec 29 19:11:18 1992
***************
*** 2096,2113 ****
    switch (code)
      {
!     case PREINCREMENT_EXPR:
!       code = POSTINCREMENT_EXPR;
!       binary_is_unary = 1;
!       try_second = 0;
!       break;
! 
      case POSTDECREMENT_EXPR:
-       code = PREDECREMENT_EXPR;
-       binary_is_unary = 1;
-       try_second = 0;
-       break;
- 
      case PREDECREMENT_EXPR:
!     case POSTINCREMENT_EXPR:
      case COMPONENT_REF:
        binary_is_unary = 1;
--- 2096,2103 ----
    switch (code)
      {
!     case POSTINCREMENT_EXPR:
      case POSTDECREMENT_EXPR:
      case PREDECREMENT_EXPR:
!     case PREINCREMENT_EXPR:
      case COMPONENT_REF:
        binary_is_unary = 1;
***************
*** 2274,2280 ****
       argument.  */
  
!   if (IS_AGGR_TYPE (type1))
!     fields1 = lookup_fnfields (TYPE_BINFO (type1), fnname, 0);
! 
    if (fields1 == NULL_TREE && global_fn == NULL_TREE)
      return rval;
--- 2264,2275 ----
       argument.  */
  
!   if (IS_AGGR_TYPE (type1)) {
!       fields1 = lookup_fnfields (TYPE_BINFO (type1), fnname, 0);
!       if (code == POSTINCREMENT_EXPR || code == POSTDECREMENT_EXPR) {
! 	  xarg2 = integer_zero_node;
! 	  binary_is_unary = 0;
!       }
!   }
! 	  
    if (fields1 == NULL_TREE && global_fn == NULL_TREE)
      return rval;

Newsgroups: gnu.g++.bug
From: rfg@segfault.UUCP
Subject: Humorous warning message.
Reply-To: uunet!segfault!rfg@uunet.uu.net
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 3 Jan 1993 18:31:39 GMT

Who says there's no humor left in programming?

Given the following code:

	struct S {
		struct { int foobar; };
	};

Compiling with g++ 2.3.3, I get the message:

test14.C:2: warning: un-usable class ignored (anonymous classes and unions are useless)

I find the assertion that anonymous unions are "useless" most humorous.

This is either a political statement about Bjarne Stroustrup's decision to
include this particular feature in the language, or else it is a profound
statement about the ignorance of the g++ maintainers.

Either way, it's pretty funny.


// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
// 	"On the one hand I knew that programs could have a compelling
// 	 and deep logical beauty, on the other hand I was forced to
// 	 admit that most programs are presented in a way fit for
// 	 mechanical execution, but even if of any beauty at all,
// 	 totally unfit for human appreciation."
// 						-- Edsger W. Dijkstra

Newsgroups: gnu.g++.bug
From: jjc@jclark.com (James Clark)
Subject: extern "C" causes internal error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 06:40:07 GMT

$ cat bug.cc
extern "C" { int foo(int, int); }
struct A;
int foo(A);
extern "C" { int foo(int, int); }
$ gcc -c -v bug.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 bug.cc /usr/tmp/cca14899.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca14899.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca14899.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.2.
bug.cc:4: Internal compiler error.
bug.cc:4: Please report this to `bug-g++@prep.ai.mit.edu'.

Newsgroups: gnu.g++.bug
From: dap@fubar.UUCP
Subject: include <iostream.h> causes compiler to choke
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 19:28:09 GMT

... when -fansi-exceptions are turned on.  These exceptions are
mighty fancy, probably not fANSI, and definitely not useful.

% cat test.cc
//
// test - just test some things
//

#include <iostream.h>

main(int c, char **v) {

  cout << "Good bye, world\n";

  throw "up";
}

% /usr/local/bin/g++ -v -fansi-exceptions -c test.cc
Reading specs from /usr/local/lib/gcc-lib/i386-bsdi/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/i386-bsdi/2.3.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -D__bsdi__ -Dbsdi -DBSD_NET2 -D__unix__ -D__i386__ -D__bsdi__ -D__bsdi__ -D__BSD_NET2__ -D__unix -D__i386 -D__bsdi__ -D__bsdi -D__BSD_NET2 test.cc /var/tmp/cc000469.i
GNU CPP version 2.3.3 (80386, BSD syntax)
 /usr/local/lib/gcc-lib/i386-bsdi/2.3.3/cc1plus /var/tmp/cc000469.i -quiet -dumpbase test.cc -version -fansi-exceptions -o /var/tmp/cc000469.s
GNU C++ version 2.3.3 (80386, BSD syntax) compiled by GNU C version 2.3.3.
/usr/local/lib/g++-include/streambuf.h: In method `class ostream* ios::tie ()const ':
In file included from /usr/local/lib/g++-include/iostream.h:24, from test.cc:5:
/usr/local/lib/g++-include/streambuf.h:140: Internal compiler error.
/usr/local/lib/g++-include/streambuf.h:140: Please report this to `bug-g++@prep.ai.mit.edu'.
*** Error code 1 (continuing)
`test' not remade because of errors.



Newsgroups: gnu.g++.bug
From: max@ise.fhg.de
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 14:59:42 GMT

------------------ cut here ----------------------------
class I
{
  public:
	operator int();
};

I i;

class K 
{
  public:
	K( const int& );
};

K k( (const int&)i );
------------------ cut here ----------------------------
g++ gets fatal signal 6

###output from  `g++ -v t.C', with t.C being the file above:

Reading specs from /usr/local/gnu/lib/gcc-lib/m68k-hp-hpux/2.2.2/specs
gcc version 2.2.2
 /usr/local/gnu/lib/gcc-lib/m68k-hp-hpux/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dhp9000s200 -Dhp9000s300 -DPWB -Dhpux -Dunix -D__hp9000s300 -D__hp9000s200 -D__PWB -D__hpux -D__unix -D__hp9000s200__ -D__hp9000s300__ -D__PWB__ -D__hpux__ -D__unix__ -D__hp9000s300 -D__hp9000s200 -D__PWB -D__hpux -D__unix -D__hp9000s200 -D__hp9000s300 -D__PWB -D__hpux -D__unix -D__hp9000s300 -D__hp9000s200 -D__PWB -D__hpux -D__unix -D__HAVE_68881__ -Dmc68020 -D_HPUX_SOURCE -D__HPUX_ASM__ t.C /us
r/tmp/cca04037.i
GNU CPP version 2.2.2 (68k, SGS/hpux syntax)
 /usr/local/gnu/lib/gcc-lib/m68k-hp-hpux/2.2.2/cc1plus /usr/tmp/cca04037.i -quiet -dumpbase t.cc -version -o /usr/tmp/cca04037.s
GNU C++ version 2.2.2 (68k, SGS/hpux syntax) compiled by CC.
/usr/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

###output from `uname -a':

HP-UX server1 B.08.00 B 9000/385 0800091148c7

###output from `ll /usr/gnu/src/gcc-2.2.2/tm.h /usr/gnu/src/gcc-2.2.2/md':

lrwxr-xr-x   1 gnu      other         16 Jul 21 11:07 /usr/gnu/src/gcc-2.2.2/md -> ./config/m68k.md
lrwxr-xr-x   1 gnu      other         16 Jul 21 11:07 /usr/gnu/src/gcc-2.2.2/tm.h -> ./config/hp320.h

thanx for g++, it's a good one
Max


Newsgroups: gnu.g++.bug
Path::findFile(const fxStr& name, fxStr& result)
{
    if (name[0] == '/' && access((char*) name, 0) == 0) {
	result = name;
	return (1);
    }
    for (PathIterator it(*this); it.notDone(); it++) {
#ifdef __bsdi__
//
// Note:  the bug is evident if __bsdi__ or not __bsdi__.  I was mucking
// around here trying to figure out a workaround, but gave up.
//
// However, the compiler will coredump on the following if it manages
// to get past the ``gxx_bug = it''.
//

	fxStr gxx_bug;

	gxx_bug = it;		// compiler goes infinite here

	gxx_bug |= "/";		// then, after an infinite amount of time&space,
				//   dumps core here. (fast CPUs are wonderful)
	gxx_bug |= name;

	char* pathname = gxx_bug;
#else
	char* pathname = it | "/" | name;
#endif
	if (access(pathname, 0) == 0) {
	    result = pathname;
	    return 1;
	}
    }
    return 0;
}



Newsgroups: gnu.g++.bug
From: jackson@galaxy.COM (Bill Jackson)
Subject: Internal compiler error 62.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 17:20:10 GMT

***** Configuration *****
    Machine:	Sun 4/310  (a modified 4/110)
    OS:		SunOS 4.1.1
    Compiler:	gcc version 2.3.1


***** Source file test.cc *****
class ClassA {
public:
    typedef ClassA& (*PMFV)(const char*);
    static PMFV setMapper(PMFV);
    static PMFV _mapper;
};


class ClassB {
public:
    typedef ClassB& (*PMFV)(const char*);
};


ClassA::PMFV ClassA::setMapper(ClassA::PMFV newFunc)
{
    PMFV oldFunc = _mapper;
    _mapper = newFunc;

    return oldFunc;
}


***** Output from gcc *****
gcc -g -c test.cc
test.cc: In function `class ClassA&(* static ClassA::setMapper (auto class ClassA&(*)(const char *)))(const char *)':
test.cc:17: Internal compiler error 62.
test.cc:17: Please report this to `bug-g++@prep.ai.mit.edu'.


***** Comments *****
If line 17 is changed from
	PMFV oldFunc = _mapper;
to
	ClassA::PMFV oldFunc = _mapper;
then the compiler does not report an error.

-------------------------------------------------------------------------
William E. Jackson	| Internet: wjackson%xphoton.uucp@gordian.COM
Excellon Automation	|     UUCP: ...!sun!sunkist!xphoton!wjackson
242751 Crenshaw Blvd.	|    Voice: (310) 534-6715
Torrance, CA  90505	|      FAX: (310) 534-6707
-------------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: zougas@me.utoronto.ca (Athanasios(Tom) Zougas)
Subject: compiler error 15
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 17:23:24 GMT

I got an internal compiler error 15 with the following code:

////////////////////////////////////////////////////////////////
// test.cc
////////////////////////////////////////////////////////////////
#include <iostream.h>

#include "test.h"

int _Test::x = 99;
int Test<int>::x(88);		// <===this caused the error
// int Test<int>::x = 88;	// <===but this was accepted

main()
{
  Test<int> ti;
  ti.print();
}

////////////////////////////////////////////////////////////////
// test.h
////////////////////////////////////////////////////////////////
#include <iostream.h>

class _Test {
public:
  _Test() {}
  void print() { cout << x << endl; }
  static int x;
};

template <class Type>
class Test : public _Test {
public:
  void print() { _Test::print(); cout << x << endl; }
  static int x;
};


===========================================================================
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: jeff@dcs.warwick.ac.UK (Jeff Smith)
Subject: Patch for libg++-2.3/libg++/etc/trie-gen/compact.cc
Organization: Department of Computer Science, Warwick University, England
Distribution: gnu
Date: Wed, 23 Dec 1992 17:46:24 GMT

The following patch applies to libg++-2.3/libg++/etc/trie-gen/compact.cc
and fixes a problem with statements of the form printf("...",i,++i) which
genberate results that are dependent on the order in which the arguments
are evaluated.

This bug also affects at least libg++-2.2.

*** xcompact.cc	Tue Dec  1 00:57:07 1992
--- compact.cc	Wed Dec 23 17:35:22 1992
***************
*** 303,310 ****
            max_number < MAX_UNSIGNED_CHAR ? "char" : max_number < MAX_UNSIGNED_SHORT ? "short" : "int",
            current_rows);
        
!   for (i = 0; i < current_rows; )
!     printf ("%*d,%s", field_width, row_offsets[i], ++i % COL_WIDTH ? " " : "\n  ");
        
    max_number = 0;
  
--- 303,310 ----
            max_number < MAX_UNSIGNED_CHAR ? "char" : max_number < MAX_UNSIGNED_SHORT ? "short" : "int",
            current_rows);
        
!   for (i = 0; i < current_rows; i++ )
!     printf ("%*d,%s", field_width, row_offsets[i], (i+1) % COL_WIDTH ? " " : "\n  ");
        
    max_number = 0;
  
***************
*** 319,326 ****
            max_number < MAX_UNSIGNED_CHAR ? "char" : max_number < MAX_UNSIGNED_SHORT ? "short" : "int",
            compressed_len + 1);
        
!   for (i = 0; i < compressed_len + 1; )
!     printf ("%*d,%s", field_width, checks[i], ++i % COL_WIDTH ? " " : "\n  ");
        
    max_number = 0;
  
--- 319,326 ----
            max_number < MAX_UNSIGNED_CHAR ? "char" : max_number < MAX_UNSIGNED_SHORT ? "short" : "int",
            compressed_len + 1);
        
!   for (i = 0; i < compressed_len + 1; i++)
!     printf ("%*d,%s", field_width, checks[i], (i+1) % COL_WIDTH ? " " : "\n  ");
        
    max_number = 0;
  
***************
*** 335,342 ****
            max_number < MAX_SIGNED_CHAR ? "char" : max_number < MAX_SIGNED_SHORT ? "short" : "int",
            compressed_len + 1);
        
!   for (i = 0; i <= compressed_len; )
!     printf ("%*d,%s", field_width, values[i], ++i % COL_WIDTH ? " " : "\n  ");
        
    printf ("\n};\n\n");
  }
--- 335,342 ----
            max_number < MAX_SIGNED_CHAR ? "char" : max_number < MAX_SIGNED_SHORT ? "short" : "int",
            compressed_len + 1);
        
!   for (i = 0; i <= compressed_len; i++ )
!     printf ("%*d,%s", field_width, values[i], (i+1) % COL_WIDTH ? " " : "\n  ");
        
    printf ("\n};\n\n");
  }

-- 
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: gs4t@virginia.edu (Gnanasekaran  Swaminathan)
Subject: Local type names bug in g++ 2.3.3
Organization: University of Virginia
Distribution: gnu
Date: Wed, 30 Dec 1992 20:38:07 GMT

g++ 2.3.3 accepts the code below without any problem.
c++ -v -c tlocaltypes.cc
gcc version 2.3.3
 /home/gs4t/bin/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 tlocaltypes.cc /usr/tmp/cca03002.i
GNU CPP version 2.3.3 (sparc)
 /home/gs4t/bin/lib/gcc-lib/sun4/2.3.3/cc1plus /usr/tmp/cca03002.i -quiet -dumpbase tlocaltypes.cc -version -o /usr/tmp/cca03002.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.2.2.
 as -o tlocaltypes.o /usr/tmp/cca03002.s

Compilation finished at Wed Dec 30 15:23:30

typedef char* T;

struct Y {
    T a;
    typedef long T; // error. See ARM p189-191 for details
    T b;
};


Is anybody working on the name hiding bugs of g++?

Newsgroups: gnu.g++.bug
From: dlong@cse.ucsc.EDU (Dean R. E. Long)
Subject: conversion operator bug?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 3 Jan 1993 10:17:20 GMT

Should '(B &)a' behave differently than 'a.operator B&()' in the
example below?

dl
-------------
moria /tmp [91] % cat a.c
#include <iostream.h>

class B {};

class A {
    B *p;
public:
    A() { p = 0; }
    operator B * () { cout << "Called B*\n"; return p; }
    operator B & () { cout << "Called B&\n"; return *p; }
};

main()
{
    A a;
    B &b = (B &)a;
    B *bp = (B *)a;
    B &br = a.operator B&();
    cout.form("&a = %x\n", &a);
    cout.form("&b = %x\n", &b);
    cout.form("bp = %x\n", bp);
    cout.form("&br = %x\n", &br);
}
moria /tmp [92] % g++ a.c
moria /tmp [93] % a.out
Called B*
Called B&
&a = f7fff9b8
&b = f7fff9b8
bp = 0
&br = 0

Newsgroups: gnu.g++.bug
From: shap@halifax.syncomas.com
Subject: DWARF -g still broken
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 22:08:00 GMT

When compiling libg++ using any g++ 2.0 or later, targeting DWARF object
format, with -g enabled, the resulting .s files do not assemble.
The assembler diagnostics complain about a variety of missing jump target
labels.

The specific configuration I am seeing this under is:

	g++ 2.3.3
	libg++ 2.3

both configured with:

	configure i386v4

I am aware that the library can be built without -g.

This problem has been reproducible for over a year now.  Since SVR4 has not
been a crucial platform to g++ users, it hasn't been very important to fix
it.  In light of the fact that Solaris 2.1 uses DWARF, it seemed appropriate
to reraise it.

If someone knows of a patch, could you please send it to me?  If there is a
patch that hasn't been included for lack of testability, I'll be happy to
help test it.  If you have a patch for a non-386 DWARF system that needs to be
tested on another platform, I'll be happy to try that.

Thanks for your help.


Jonathan S. Shapiro
Synergistic Computing Associates
shap@halifax.syncomas.com

Newsgroups: gnu.g++.bug
From: shap@halifax.syncomas.com
Subject: Bug (incomplete feature) in cpp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 05:34:00 GMT

Appears in GCC versions 2.0 and later

Gcc recognizes that .cxx files are C++ source.  The -M option to cpp,
however, does not, with the result that foo.cxx files end up as
foo.cxx.o in the -M output.  I'ld appreciate it if in future releases
you would include something equivalent to the following patch, which
repairs the problem:


Jonathan S. Shapiro
Synergistic Computing Associates


*** cccp.c~	Tue Dec 15 23:25:36 1992
--- cccp.c	Fri Jan  1 00:22:35 1993
***************
*** 1687,1692 ****
--- 1687,1697 ----
  	       && p[len - 2] == 'c'
  	       && p[len - 1] == 'c')
  	deps_output (p, len - 3);
+       else if (p[len - 4] == '.'
+ 	       && p[len - 3] == 'c'
+ 	       && p[len - 2] == 'x'
+ 	       && p[len - 1] == 'x')
+ 	deps_output (p, len - 4);
        else if (p[len - 2] == '.' && p[len - 1] == 's')
  	deps_output (p, len - 2);
        else if (p[len - 2] == '.' && p[len - 1] == 'S')

Newsgroups: gnu.g++.bug
From: dir@lookout.IT.USwc.USwest.COM (Daniel I. Rosenblatt)
Subject: Problem building InterViews 3.1 w/gcc-2.3.3 and libg++-2.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 02:59:44 GMT

This is on a Sun Sparc w/SunOS 4.1.2 - standard configuration.
This is also on a Mips and SCO ODT - both standard configuration.
The package is InterViews 3.1.

I get undefined symbol __vt$7istream$3ios when attempting to link
several sample InterViews programs (ibuild, iclass).

The reference to this is in src/lib/Unidraw/catalog.c .

The closest definition in libg++.a is in iostream.o:'D __vt$istream$3ios'.
Note that in libg++.a in iostream.o, there is also 'D __vt$7ostream$3ios'.

My guess is that somehow the name mangleing was inconsistent.

Any suggestions?

Dan Rosenblatt
dir@lookout.uswest.com
Newsgroups: gnu.g++.help
Subject: fatal signal 11 compiling libg++
From: R.A.Rayner@massey.ac.nz (R.A. Rayner)
Date: Mon, 21 Dec 92 21:58:06 GMT
Organization: Massey University, Palmerston North, New Zealand
Keywords: fatal signal 11, Rational.o, libg++
Summary: fatal signal 11 compiling libg++
X-Reader: NETNEWS/PC Version 2c

	I've installed gcc/g++ on our SPARC 1+ version 2.3.1. But when I try to
make ver 2.3 of libg++ I get
	gcc:Internal compiler error: Program cc1plus got fatal signal 11
	*** Error code 1
	make: Fatal error : Command failed for target 'Rational.o'

any ideas ?

Richard Rayner
Massey Uni

-- 
------------------------------------------------------------------------------
TYPE	god = INTEGER ;
VAR	EricClapton : god ;
------------------------------------------------------------------------------
From: cilibrar@ugcs.caltech.edu (Rudi L. Cilibrasi)
Newsgroups: gnu.g++.help
Subject: Wanted: Example Code using Container Classes
Date: 3 Jan 1993 11:05:17 GMT
Organization: Caltech Undergraduate Computer Science
NNTP-Posting-Host: heckle.ugcs.caltech.edu

Does anyone know of any ftp sites that have example C++ code that uses
the g++ container-classes?  If so, could you please tell me where they
are?  Please email to: cilibrar@ugcs.caltech.edu

Thanks in advance for any help.

-Rudi
Xref: sparky gnu.g++.help:1612 comp.lang.c++:18311
From: singhal@cs.utexas.edu (Vivek P. Singhal)
Newsgroups: gnu.g++.help,comp.lang.c++
Subject: Looking for a G++ grammar (w/ symbol table)
Followup-To: gnu.g++.help
Date: 22 Dec 92 11:19:20
Organization: Univ. of Texas at Austin, CS Dept.
Distribution: world
NNTP-Posting-Host: twins.cs.utexas.edu

I'm planning to write a program which will need to parse C++.  I've
looked at Jim Roskind's grammar (which is mentioned in the
comp.lang.c++ FAQ), but it lacks a symbol table (and the appropriate
actions which insert symbols into the table).  I'm considering using
the grammar of the G++ compiler instead; presumably, all I'd need to
do is strip out the code generation stuff, leaving behind only the
actions related to parsing.

Before I begin this task, however, I was wondering if anyone has
already done this (i.e. built a stand-alone G++ grammar), and if they
are willing to share the code.  Thanks,
--


Vivek

------------------------------------------------------------------------------
E-mail: singhal@cs.utexas.edu     Phone: (512) 471-9711     Office: TAY 3.104C
USmail: CS Dept. TAY 2.124 \n Univ. of Texas @ Austin \n Austin, TX 78712-1188
To: gnu-groff-bug@uunet.uu.net
Distribution: world
Approved: info-gnu@prep.ai.mit.edu