HDTenEightyP/NetNews huggingface dataset:
From: sjg@melb.bull.oz.AU (Simon J. Gerraty)
Subject: name space polution bug in gcc-2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 00:11:37 GMT

The following code demonstrates a problem that appeared while
trying to build groff-1.5 with gcc-2.1 on a Bull DPX/2.
The tests below were run with gcc-2.1 on a sun4c - which gets
the same result (eliminating the possibility that a bug in my
gcc port to the DPX/2 is the problem) 

The struct foo contains a member declared as "struct proc
*pfoo".  After which it is not possible to use the name "proc" as
a member in a struct.  Of course you can subst any name you like
for "proc" and get the same result.  Without the struct foo
definition, the module compiles cleanly.

I'm reluctant to believe that this could be a "feature" of C++
as that would mean that it is impossible to write portable code.

Script started on Tue Apr  7 15:40:03 1992
/tmp
<sjg@sun0:1>$ cat foo2.cc
#ifndef FOO
struct foo
{
  struct proc *pfoo;
};
#endif

class S
{
  int i;
public:
  int f(char *cp);
  int cf(int index);
};

int S::f(char *cp) { return (i = strlen(cp)); }

int S::cf(int index)
{
  struct P
  {
    char *str;
    int (S::*proc)(char *);
  };

  static struct P Ps[] =
  {
    "0", &S::f,
    "1", &S::f
  };
  return (this->*(Ps[index].proc))("hi");
}
<sjg@sun0:2>$ gcc -DFOO -c foo2.cc
<sjg@sun0:3>$ gcc -c foo2.cc
foo2.cc: In method `int  S::cf (int)':
foo2.cc:30: initialization between incompatible pointer types
foo2.cc:30: initialization between incompatible pointer types
foo2.cc:31: structure has no member named `proc'
foo2.cc:32: warning: control reaches end of non-void function
<sjg@sun0:4>$ exit

script done on Tue Apr  7 15:41:42 1992

Simon J. Gerraty        <sjg@melb.bull.oz.au>           (work)
                        <sjg@zen.void.oz.au>            (home)

#include <disclaimer>   /* imagine something *very* witty here */

Newsgroups: gnu.g++.bug
From: dousson@vega.laas.fr (Christophe Dousson)
Subject: bug: operator delete & inline destructor
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 16:05:27 GMT

/*

Sun OS 4.1.1

Sparc station 2

g++ 2.1


The following code produces:

g++ -v -c delete_bug.C

Reading specs from /usr/local/GNU1/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /usr/local/GNU1/lib/gcc-lib/sun4/2.1/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 delete_bug.C /tmp/cca05685.i
GNU CPP version 2.1 (sparc)
 /usr/local/GNU1/lib/gcc-lib/sun4/2.1/cc1plus /tmp/cca05685.i -quiet -dumpbase delete_bug.cc -version -o /tmp/cca05685.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
delete_bug.C: In method `pipo::~pipo ()':
delete_bug.C:8: too few arguments for method `operator delete'

*/
//----------------------------------------------------------------------

#include <stddef.h>


class pipo {

  public:

    ~pipo() {}

    void* operator new     (size_t);
    void  operator delete  (void*, size_t);
};

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

// If the destructor isn't defined in class declaration, all work fine.


//          - Christophe DOUSSON -
//
//------------------------------------------------------
// LAAS-CNRS, groupe RIA
// 7, avenue du Colonel Roche, 31077 TOULOUSE Cedex
// tel: 61.33.63.54  -  e-mail: dousson@laas.laas.fr
//------------------------------------------------------


Newsgroups: gnu.g++.bug
From: stan@sabaac.mayo.edu
Subject: c++ template bugs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 07:19:32 GMT

The current version of gcc has partial support for template in c++
programs. Is there a developement group I could join and become a beta
site for the template development effort??

Andrew Staniszewski
Mayo Foundation
staniszewski@mayo.edu

Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC 2.1: bizarre error messages when returning a reference
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Fri, 10 Apr 1992 04:30:49 GMT

Given the following little test program in C++:

	class Object {
	public:
		virtual ~Object();
	};

	class OutputStream : public Object {
	public:
		OutputStream( Object & );
		virtual int foo (void) = 0;
		virtual operator int();
	};

	OutputStream &
	flush( OutputStream & stream )
	{
		return (stream);
	}

GCC 2.1 produces the error message

	stdin: In function `class OutputStream& flush (class OutputStream&)':
	stdin:14: cannot allocate an object of type `OutputStream'
	stdin:14: since the following virtual functions are abstract:
	stdin:8: int  OutputStream::foo ()
	stdin:8: int  OutputStream::foo ()
	stdin:14: in conversion to type `OutputStream'

and then dumps core (memory fault).  The compiler does not notice that
the idea is to convert to type `OutputStream &' and not to `OutputStream'.

If the member function declaration

		virtual operator int();

is deleted from class OutputStream, then everything works fine.  There is
no error message and no core dump.

If the constructor OutputStream::OutputStream is omitted instead, we
get the error message

	stdin: In function `class OutputStream& flush (class OutputStream&)':
	stdin:15: conversion to non-scalar type requested

followed by a core dump (memory fault).  If we omit the abstract member
function OutputStream::foo, the compiler says:

	stdin: In function `class OutputStream& flush (class OutputStream&)':
	stdin:15: bad argument 0 for function
		  `OutputStream::OutputStream (class Object&)' (type was int )
	stdin:15: in conversion to type `OutputStream'

followed by the usual core dump.

Now we leave class OutputStream untouched, but we remove the virtual
destructor of class Object.  That is class Object becomes

	class Object { };

Instead of a core dump, the result is an endless loop of error messages:

	stdin: In function `class OutputStream& flush (class OutputStream&)':
	stdin:14: cannot allocate an object of type `OutputStream'
	stdin:14: since the following virtual functions are abstract:
	stdin:7: int  OutputStream::foo ()
	stdin:14: in conversion to type `OutputStream'
	stdin:14: cannot allocate an object of type `OutputStream'
	stdin:14: since type `OutputStream' has abstract virtual functions
	stdin:14: in conversion to type `OutputStream'
	stdin:14: cannot allocate an object of type `OutputStream'
	stdin:14: since type `OutputStream' has abstract virtual functions
	stdin:14: in conversion to type `OutputStream'
	stdin:14: ...

--Gerald

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  #pragma interface -- whose bug is it anyway?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 07:26:42 GMT

> Date: Mon, 6 Apr 92 18:37:48 EDT
> From: purtill%idacrd@uunet.uu.net (Mark Purtill)
> Message-Id: <9204062237.AA05389@>

This is a bug with libg++, it sounds like.  The behavior you site, is
correct.  Another possibility, is that you are just using libg++
incorrectly.

> On a Sparcstation 2 (which is not connected to the outside;  I'm
> typing this in from a printed transcript, so I might err).
> % gcc -v
> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/specs
> gcc version 2.1
> % more /etc/motd
> SunOS Release 4.1.1 (CARS_2) #3: Thu Aug 15 10:35:49 EDT 1991
> % cat >A.h
> #pragma interface
> struct A {
>     A() ;
>     };
> inline A::A() {}
> ^D
> % cat > B.C
> #include "A.h"

> struct B {
>     A* _copy(A* t);
>     };

> A* B::_copy(A* t) {
>     A* x = new A();
>   return 0 ;
>     }
> ^D
> % gcc -c B.C	
> 	And now if you examine B.o with nm, you should find A::A() as
> an undefined global.  Removing the "#pragma interface" causes the
> problem to go away.
> 	Now, "#pragma interface" does not seem to be documented, so
> maybe this is correct behaviour for gcc.  If so, then this is a libg++
> bug, which occurs in (at least) int SplayBag s.



Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Nested types cause seg fault
Organization: Harvey Mudd College
Distribution: gnu
Date: Sun, 12 Apr 1992 07:07:34 GMT

Trying to compile this file:

-----
class Bunk {
    typedef unsigned short bunkTy;
}
-----

causes a segmentation fault in cc1plus.  Somehow I don't think this is
intended.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: joe@dharna.UUCP (Joe Linoff)
Subject: gcc-2.1 collect2 problem (AND fix)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 22:22:01 GMT

* VERSION: g++ version 2.1

* SOURCE FILE: collect2.c (from the distribution)

    =======================================================================
    ORIGINAL VERSION (savestring() #line 393)
        /* Make a copy of a string INPUT with size SIZE.  */

        char *
        savestring (input, size)
             char *input;
             int size;
        {
          char *output = (char *) xmalloc (size + 1);
-         strcpy (output, input);
          return output;
        }


    CORRECTED VERSION (savestring() #line 393)
        /* Make a copy of a string INPUT with size SIZE.  */

        char *
        savestring (input, size)
             char *input;
             int size;
        {
          char *output = (char *) xmalloc (size + 1);
+         strncpy (output, input, size); /* no NULL terminator in input */
+         output[size]=0;
          return output;
        }
    =======================================================================

* DESCRIPTION OF INCORRECT BEHAVIOR:

    Collect2 overwrites the heap and generates a segment violation
    when a -f.. or -m... switch is used because input does not have
    a NULL terminator and too many bytes are copied.  The fix is
    shown above.



Newsgroups: gnu.g++.bug
From: c9524@rrzc1.rz.uni-regensburg.de (Ulrich Windl)
Subject: Incorrect 'conversion to reference of read-only variable' error
Reply-To: c9524@rrzc1.rz.uni-regensburg.de
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 12:05:08 GMT

>   Arraychar.c:291: conversion to reference of read-only variable `nil'
>
>   Here g++ should quietly cast away nil's const-ness.
I think it should NOT, because there's a good reason:
If you tell the compiler that a variable (nil) is to be const.
In most cases it is an error if you cast away const-ness.
Furthermore it make the code optimizer less efficient.
Maybe the compiler should warn, but what's a constant, if you can change it?

----------------------------------------
Ulrich Windl
Universitaet Regensburg
Rechenzentrum
D-W8400 Regensburg
---
X.400: windl@vax1.informatik.fh-regensburg.dbp.de   (VAX/VMS soon invalid)
(Maybe you'll have to leave out ".dbp")
SMTP:  c9524@rrzc1.rz.uni-regensburg.de	            (Sun, my favorite)
SMTP:  uw@ngate.rzi.uni-regensburg.de		    (PC, Pegasus Mail)

Newsgroups: gnu.g++.bug
From: joe@dharna.UUCP (Joe Linoff)
Subject: invalid function refs generated
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 22:43:04 GMT

* VERSION: g++ version 2.1

* SOURCE FILE: problem.cc

    =======================================================================
    #include <stdio.h>

    typedef void (*fp_one_args)(const char*);
    typedef void (*fp_two_args)(const char*, const char*);

    struct callbackSpec {
	fp_one_args f1;
	fp_two_args f2;
    };

    static void callback1(const char*) {}
    static void callback2(const char*, const char*) {}

    callbackSpec bad = { &callback1, &callback2, };
    callbackSpec ok = { callback1, callback2, };

    int main() {
	printf(
	    "bad.f1 == 0x%x, bad.f2 == 0x%x, ok.f1 == 0x%x, ok.f2 == 0x%x\n",
	    bad.f1, bad.f2, ok.f1, ok.f2);
	return !(bad.f1 && bad.f2 && ok.f1 && ok.f2);
    }
    =======================================================================

* COMMAND ARGUMENTS:

	g++ -c -g problem.cc
	g++ -o problem problem.o

*  tm.h and md

	tm.h -> ./config/tm-sparc.h
	md -> ./config/sparc.md

* MACHINE TYPE and O/S

	SPARCstation 2
	4.1.1

* DESCRIPTION OF INCORRECT BEHAVIOR:

    The compiler generates bad address information for the bad variable.
    When I ran it the result was:
	bad.f1 == 0x0, bad.f2 == 0x0, ok.f1 == 0x2290, ok.f2 == 0x22a8


Newsgroups: gnu.g++.bug
From: bard@cutter.ssd.loral.com (James Woodyatt)
Subject: My previous message
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 02:59:16 GMT

There is an inconsequential error in the code I provided in the bug
report about template classes and incomplete classes. The line that
reads:

	Foo f;

in function main() should read:

	Foo<Bar> f& = foo;

This does not affect the bug report in that cc1plus crashes before it
even reaches that line.

Sorry about the confusion.

--James

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re: c++ template bugs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 01:46:33 GMT

> Newsgroups: gnu.g++.bug
> From: tll@cco.caltech.edu (Tal Lewis Lancaster)
> Message-Id: <1992Apr8.234751.14662@cco.caltech.edu>
> Organization: California Institute of Technology, Pasadena
> References: <gnusenet9204071719.AA24111@sabaac.mayo.edu>
> Date: Wed, 8 Apr 1992 23:47:51 GMT

> Could somebody please list what is supported with g++'s templates?
> I have some examples that work fine under ATT 3.0 but the g++'s
> parser get's very confused and segments.

You aren't going to like my answer, but in short, nothing is supported
in terms of g++ templates.  There are somethings that work however.

Offhand, I do know know what.

Newsgroups: gnu.g++.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: sign bug in stream.C: itoa
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 02:24:07 GMT

The use of the itoa function in stream.C, as via dec(), places the minus
sign for negative numbers after the number, rather than before it.
The following patch fixes the problem.

Doug Moore (dougm@cs.rice.edu)


*** stream.C~	Mon Apr 13 21:08:54 1992
--- stream.C	Mon Apr 13 21:18:20 1992
***************
*** 44,51 ****
      if (needed < (2+neg) || ptr > EndBuffer)
  	return NULL;
      *--ptr = 0;
-     if (neg)
- 	*--ptr = '-';
      
      if (i == 0)
  	*--ptr = '0';
--- 44,49 ----
***************
*** 58,63 ****
--- 56,63 ----
  	    ch += '0';
  	*--ptr = ch;
      }
+     if (neg)
+ 	*--ptr = '-';
      if (size == 0)
  	return ptr;
      while (ptr > buf)



Newsgroups: gnu.g++.bug
From: R.Winder@cs.ucl.ac.uk (Russel Winder)
Subject: Must already have been reported but...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 18:10:42 GMT

I don't believe the following can be correct, the code is:

#include <std.h>
#include <iostream.h>

main()
{
    cout << oct << 16 << endl ;
}

The message is:

g++ trial.cc
trial.cc: In function `int  main ()':
trial.cc:6: type conversion required for type `ostream'

Compilation exited abnormally with code 1 at Tue Apr 14 17:07:24

Using g++ configered with ./configure --target=sparc-sun-sunos4.1

Russel.

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

Dr Russel Winder		(InterNet: R.Winder@cs.ucl.ac.uk)
Department of Computer Science	(UUCP: {...mcsun!ukc!}ucl-cs!R.Winder)
University College London	(JANet: R.Winder@uk.ac.ucl.cs)
Gower Street
London WC1E 6BT
England

Phone: +44 (0)71 380 7293
Fax: +44 (0)71 387 1397

Xref: sparky gnu.g++.bug:518 gnu.g++.lib.bug:152
From: purtill%idacrd@uunet.uu.net (Mark Purtill)
Newsgroups: gnu.g++.bug,gnu.g++.lib.bug
Subject: #pragma interface -- whose bug is it anyway?
Date: 6 Apr 92 22:37:48 GMT
Article-I.D.: .9204062237.AA05389
Followup-To: gnu.g++.bug,gnu.g++.lib.bug
To: bug-gcc@prep.ai.mit.edu, bug-lib-g++@prep.ai.mit.edu

On a Sparcstation 2 (which is not connected to the outside;  I'm
typing this in from a printed transcript, so I might err).
% gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/specs
gcc version 2.1
% more /etc/motd
SunOS Release 4.1.1 (CARS_2) #3: Thu Aug 15 10:35:49 EDT 1991
% cat >A.h
#pragma interface
struct A {
    A() ;
    };
inline A::A() {}
^D
% cat > B.C
#include "A.h"

struct B {
    A* _copy(A* t);
    };

A* B::_copy(A* t) {
    A* x = new A();
  return 0 ;
    }
^D
% gcc -c B.C	
	And now if you examine B.o with nm, you should find A::A() as
an undefined global.  Removing the "#pragma interface" causes the
problem to go away.
	Now, "#pragma interface" does not seem to be documented, so
maybe this is correct behaviour for gcc.  If so, then this is a libg++
bug, which occurs in (at least) int SplayBag s.

^.-.^ Mark Purtill, IDA/CCR-P, Thanet Road, Princeton NJ  08540; (609)924-4600.
((")) Email: purtill%idacrd@princeton.edu; uunet!idacrd!purtill. (609)497-0526.
Newsgroups: gnu.g++.bug
From: marab@warwick.ac.UK (Mr I D Redfern)
Subject: g++ 2.1 SEGV/infinite loop
Organization: Computing Services, Warwick University, UK
Distribution: gnu
Date: Sat, 11 Apr 1992 18:56:03 GMT

The following code produces an error message at the line `return s;' followed
by a fatal signal 11 (Segmentation fault) on a Sun4 running SunOS 4.1.2 during
compilation under g++ 2.1. While cutting it down, I discovered that it can
also cause an infinite loop. Cfront 3.0 compiles it without complaint.


---Start
// test.cc		(This is -*- C++ -*-)

//#define INF_LOOP
//#define SEGV

class state;

class automaton
{
public:
    state new_state();
};

class state
{
    automaton& my_aut;
    int state_num;
    state(const automaton& a, int i);
public:
    state(const state& s);

#ifndef INF_LOOP
    ~state();
#endif
#if defined(SEGV) || defined(INF_LOOP)
    operator int() const { return state_num; }
#endif
    friend automaton;
};

// Make a new state
state automaton::new_state()
{
    state s(*this, 0);
    return s;
}
// End.
----End

clover% g++ -v -c -DSEGV test.cc
Reading specs from /usr/local/lib/gnu/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /usr/local/lib/gnu/gcc-lib/sun4/2.1/cpp -lang-c++ -v -DSEGV -I/usr/local/lib/g++-include -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/cca16553.i
GNU CPP version 2.1 (sparc)
 /usr/local/lib/gnu/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca16553.i -quiet -dumpbase test.cc -version -o /usr/tmp/cca16553.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
test.cc: In method `class state automaton::new_state ()':
test.cc:35: bad argument 0 for function `state::state (const class state&)' (type was int )
test.cc:35: in conversion to type `state'
/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11


clover% g++ -v -c -DINF_LOOP test.cc
Reading specs from /usr/local/lib/gnu/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /usr/local/lib/gnu/gcc-lib/sun4/2.1/cpp -lang-c++ -v -DINF_LOOP -I/usr/local/lib/g++-include -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/cca16560.i
GNU CPP version 2.1 (sparc)
 /usr/local/lib/gnu/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca16560.i -quiet -dumpbase test.cc -version -o /usr/tmp/cca16560.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
test.cc: In method `class state automaton::new_state ()':
test.cc:35: bad argument 0 for function `state::state (const class state&)' (type was int )
test.cc:35: in conversion to type `state'
test.cc:35: bad argument 0 for function `state::state (const class state&)' (type was int )
test.cc:35: in conversion to type `state'

... and repeats


If you need any more information, please let me know.
Thanks,
Ian Redfern (marab@dcs.warwick.ac.uk)

Newsgroups: gnu.g++.bug
From: abed@venus.wustl.edu (Abed M. Hammoud)
Subject: Re: templates
Organization: Washington University, ESSRL
Distribution: gnu
Date: Thu, 16 Apr 1992 16:32:00 GMT

In article <ALLEN.92Apr16092129@golem.ssc.gov> Michael_Allen@ssc.gov writes:
>I am trying to use templates and am pretty thoroughly confused.  In
>particular, I am confued about which code can be compiled into a
>library and which has to be included into the source.  Can judicious
>use of "#pragma interface" and "#pragma implementation" help?  Are
>there good references on this?  (I have read the relevent ARM sections
>a few times, so...)
>
>-Thanks,
> Michael
>--
>===============================================================================
>	German Chancellor Helmut Kohl, on the inauguration of Germany's first
>Holocaust memorial, saying Germans must never forget Nazi atrocities:
>	``(We) owe it to our children and grandchildren. We must pass on to
>them the realization that it is not at all self-evident that one should
>be allowed to live in peace and freedom.''


Could you please post a summery. I am also intersted in this.
Are you having a lot of problems with template and not much help...as
its the case with me.

thanks, 
+-------------------------------------------------+-----------------------+
|Abed M. Hammoud (KB0INX)			  | abed@saturn.wustl.edu |
|Washington University.				  | Office:               |
|Electronic Systems & Signals Research Laboratory.| -Voice:(314) 935-7547 |
|Department of Electrical/Biomedical Engineering. | -FAX:  (314) 935-4842 |
|Campus Box 1161, One Brookings Drive.		  |			  |
|St. Louis, MO , 63130 USA			  |                       |
+-------------------------------------------------+-----------------------+
From: skohn@cs.ucsd.edu (Scott Kohn)
Newsgroups: gnu.g++.help
Subject: g++ 2.1 and libg++ 2.0 on iPSC/860
Keywords: installation of i860 cross-compiler
Date: 10 Apr 92 18:03:57 GMT
Followup-To: gnu.g++.help
Distribution: usa
Organization: UC-San Diego CSE Department


Has anyone been able to install g++-2.1/libg++-2.0 as a cross compiler
for the iPSC/i860 (using a Sparc as a host)?  I am currently trying to
install g++/libg++ and am (hopefully) almost finished.  I would like to talk
to anyone who has already been successful.

Also - a question.  Is this a bug in cp-decl.c or just my misunderstanding
of the compiler:  In order to do varargs stuff on an i860, we need to define
__builtin_args_info as a built-in function so that the compiler can expand
the call.  However, __builtin_args_info is only defined in c-decl.c and not
in cp-decl.c.  Without this declaration, it would seem that every i860 C++
program which used varargs (libg++, in particular) would die at link time since
__builtin_args_info had not been defined.

Furthermore, libg++ seems to be doing some questionable things with
casting datatypes to va_list and back.  As it is now, libg++ doesn't
compile with the i860 stdarg definitions.  This can be fixed by changing
libg++ to use less questionable calling styles, but I find it hard to believe
that I'm the first one to come across this problem...

Thanks.

-- Scott Kohn
From: glipton@ajax.intel.com (Gary Lipton)
Newsgroups: gnu.g++.help
Subject: implicit member-wise assignment
Date: 9 Apr 92 05:46:54 GMT
Organization: Intel Corp, Chandler, AZ

I am just learning C++.  My references tell me that "=" is
implicitly defined as member-wise assignment between operands
of a given class.

That is, if I have a class "Foo", then the code

   Foo foo1, foo2;

   foo1 = foo2;

is legal, and will copy the members of foo1 into foo2, without
an explicit declaration of "=".

But I find that using g++, I would need the statement

  Foo operator=(Foo);

in my Class declaration for this code to compile.

Is there a way to get g++ to provide implicit assignment?  Or
am I on the wrong track entirely?
From: edwin@maui.cs.ucla.edu (Edwin Tisdale)
Newsgroups: gnu.g++.help
Subject: Manuals
Keywords: manuals documentation
Date: 14 Apr 92 22:54:43 GMT
Distribution: gnu
Organization: UCLA Computer Science Department
Originator: edwin@maui.cs.ucla.edu

When will the documentation for the latest versions of GNU C++, GNU CC
and the GNU C++ Library be available?
My copy of the User's Guide to the C++ Library was last updated 19 February
1991 for version 1.39.0.  My copy of the User's Guide to GNU C++ was last
updated 1 March 1990 for version 1.37.1.  My copy of Using GNU CC was last
updated 15 February 1992 for version 2.0.  Thanks in advance, Bob Tisdale
(edwin@cs.ucla.edu)