HDTenEightyP/NetNews huggingface dataset:
From: miniussi@mistral.greco-prog.fr (Alain MINIUSSI [91-92])
Newsgroups: gnu.g++.bug
Subject: bug report
Date: 25 Jan 1993 20:13:46 -0500
Organization: GNUs Not Usenet
Distribution: gnu

I think that the following code is legal:

----------

#include <stream.h>

template <class T>
class C {
  class B<T>; 
friend B<T>;  

public: 
  C() {};
  ~C() {};
};

main()
{
  C<int> ;
}

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

The compiler output is:

geocub>CC : g++ truc.cc -c -v
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 -D
sparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix truc.cc /usr/tmp/cca05
965.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sun4/2.3.3/cc1plus /usr/tmp/cca05965.i -quiet -dumpbase truc.cc -version -o /
usr/tmp/cca05965.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
truc.cc:7: parse error before `<'
truc.cc:8: Internal compiler error.
truc.cc:8: Please report this to `bug-g++@prep.ai.mit.edu'.
geocub>CC :

Alain

------------------------------------------------------------------------------
Alain Miniussi                       | Je distingue les genies doues et les 
(avec le "i" avant le "u")           | genies pas doues, "le genie est une 
e-mail: miniussi@labri.greco-prog.fr | longue patience", c'est une reflexion
LaBRI, Univ. BORDEAUX I              | de genie pas doue.     B. Vian
351, cours de la Liberation          | 
33405 TALENCE Cedex                  | (D'ailleurs, c'est souvent une longue
FRANCE                               |  patience de la part des autres) Id
------------------------------------------------------------------------------
From: truman@zabriskie.berkeley.edu
Newsgroups: gnu.g++.bug
Subject: Bug: Temporaries destroyed prematurely
Date: 25 Jan 1993 21:16:48 -0500
Organization: GNUs Not Usenet
Distribution: gnu

I believe I have found a bug in the way g++ handles destruction of temporaries.
Below, is the code and the output obtained by running the program.

Notice in the 3rd output line, the sentence has been truncated -- what
it looks like to me is that whenever a typecast is used on a temporary
object, the destructor is for the object is involed prematurely.  In
my code (below), the line

example C( (const char*) B.PrintName() );

should do some like this:
    1] call B.PrintName(), which returns a String temporary
    2] call String::operator char*() on the temporary
    3] invoke example::example(const char*)
    4] call the destructor for the temporary

however, what actually happens is that the 4th and 3rd step become interchanged.

Here is the output of compilation:

>>>>>
yosemite[149]> g++ -v -ggdb test.cc
Reading specs from /users/truman/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /users/truman/gnu/bin/cpp -lang-c++ -v -iprefix /users/truman/gnu/bin/sparc-sun-sunos4.1/2.3.3/ -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -ggdb test.cc /usr/tmp/cca04318.i
 GNU CPP version 2.3.3 (sparc)
  /users/truman/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca04318.i -quiet -dumpbase test.cc -ggdb -version -o /usr/tmp/cca04318.s
  GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
   as -o /usr/tmp/cca043181.o /usr/tmp/cca04318.s
    /users/truman/gnu/bin/ld -e start -dc -dp /lib/crt0.o -L/users/truman/gnu/lib -L/users/truman/gnu/bin -L/users/truman/gnu/lib -L/users/truman/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3 -L/users/truman/gnu/lib /usr/tmp/cca043181.o -lg++ -lgcc -lc -lgcc
 
>>>>>>>>>>>>

here is the program output:

yosemite[150]> a.out
A.name = one-long-testing-name-
B.name = one-long-testing-name-

C.name = one-long-testing-nam
                            ^ 
____________________________|

note the truncation

>>>>>>>>>>>>>>

//
// test.cc
//
//

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


class example
{
    char*	name;

public:
    example(const char* n) 	{ name = new char[ strlen(n) + 1];
				  strcpy(name,n);
				}

    example(String& s)		{ name = new char[ s.length() + 1];
				  strcpy(name,(char*)s);
				}

    String PrintName()		{ return String(name); }

    ~example()			{ delete name; }

};

main()
{
    example A("one-long-testing-name-");
    example B( A.PrintName() );
    example C( (const char*)B.PrintName() );

    cout << "A.name = " << A.PrintName();
    cout << "\nB.name = " << B.PrintName() << "\n";
    cout << "\nC.name = " << C.PrintName() << "\n";

}
From: draves@mermaid.micro.umn.edu (Christy Marie Draves)
Newsgroups: gnu.g++.bug
Subject: Internal Compiler error
Date: 21 Jan 1993 18:15:23 -0500
Organization: GNUs Not Usenet
Distribution: gnu

The computer said Internal compiler error 307
From: fritz@mtl.mit.edu
Newsgroups: gnu.g++.bug
Subject: Internal compiler error 346.
Date: 21 Jan 1993 18:25:47 -0500
Organization: MIT Microsystems Technology Laboratories
Distribution: gnu
Reply-To: fritz@mtl.mit.edu

This is to report a bug with destructors of nested classes.

We run gcc on two platforms:
  Reading specs from /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
  gcc version 2.3.3
  Reading specs from /usr/local/gnu/lib/gcc-lib/mips-dec-ultrix4.2/2.3.3/specs
  gcc version 2.3.3

Here's the problem:

  g++ doesn't like destructors of nested classes defined outside the
  class definition.  Code below gives:

	% g++ bugnest.cc
	bugnest.cc:8: Internal compiler error 346.
	bugnest.cc:8: Please report this to `bug-g++@prep.ai.mit.edu'.

  No problem if the destructor is declared as an inline inside the class
  definition.

Here's the code:

	class S {
	  struct R {
	    R() {}
	    ~R();
	  };
	};

	S :: R :: ~R() {}

Thanks, 
	- Fritz
	  fritz@mtl.mit.edu
From: kuhlins@anne.wifo.uni-mannheim.de (Stefan Kuhlins)
Newsgroups: gnu.g++.bug
Subject: overloaded-function-bug
Date: 26 Jan 1993 22:01:29 -0500
Organization: GNUs Not Usenet
Distribution: gnu

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 0

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: gnubug.C
X-Sun-Content-Lines: 42

// This programm contains 2 errors, which g++ 2.3.1 does not detect.

#include <iostream.h>
 
void h (float)  { cout << "h1" << endl; }
void h (double) { cout << "h2" << endl; }

void f ()        { cout << "f1" << endl; }
void f (int = 1) { cout << "f2" << endl; }

int main()
{
  h(3);       // error 1, g++ calls h1()
  f();        // error 2, g++ calls f1()
  return 0;
}

/*
error 1: ambiguous call: h ( int )
  choice of h()s:
     h(float );
     h(double );

error 2: ambiguous call: f ()
  choice of f()s:
     f();
     f(int );


g++ output:

# g++ -v gnubug.C
Reading specs from /vol/lang/gcc/lib/gcc-lib/sparc-sun-sunos4.1.2/2.3.1/specs
gcc version 2.3.1
 /vol/lang/gcc/lib/gcc-lib/sparc-sun-sunos4.1.2/2.3.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 gnubug.C /usr/tmp/cca10574.i
GNU CPP version 2.3.1 (sparc)
 /vol/lang/gcc/lib/gcc-lib/sparc-sun-sunos4.1.2/2.3.1/cc1plus /usr/tmp/cca10574.i -quiet -dumpbase gnubug.cc -version -o /usr/tmp/cca10574.s
GNU C++ version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
 as -o /usr/tmp/cca105741.o /usr/tmp/cca10574.s
 /vol/lang/gcc/lib/gcc-lib/sparc-sun-sunos4.1.2/2.3.1/ld -e start -dc -dp /lib/crt0.o -L/vol/lang/gcc/lib/gcc-lib/sparc-sun-sunos4.1.2/2.3.1 -L/vol/lang/gcc/lib /usr/tmp/cca105741.o -lg++ -lgcc -lc -lgcc

*/
From: djb@babypuss.mitre.org (David J. Braunegg)
Newsgroups: gnu.g++.bug
Subject: (none)
Date: 22 Jan 1993 21:49:39 -0500
Organization: GNUs Not Usenet
Distribution: gnu

This is a bug report for g++ (gcc) version 2.3.3, running on a Sun
Sparcstation, OS 4.1.


Your declaration of

        ostream& operator<<(void *p);

in iostream.h is in error.  Unless you have truly defined operator<<
on void* pointers so that it modifies the pointer, the declaration
should instead be

        ostream& operator<<(const void *p);



For example, the following program should *not* issue the const
violation warning that it does.



#include <iostream.h>

int main()
{
  const char *foo = "stuff";

  cout << (const void *)foo << endl;

  return 0;
}




djb@bambam>g++ -g -Wall test.cc
test.cc: In function `int  main ()':
test.cc:7: warning: argument passing of non-`const *' pointer from `const *'
test.cc:7: warning: argument passing of non-`const *' pointer from `const *'



I have encountered this warning frequently, because in my code I am
often writing out the address of an object to help identify it.  If
foo is `const <class> *', then I must cast it to `const void *' and
*not* to `void *' when printing its address in order to avoid a const
violation.


Please contact me if you have any further questions.

Dave
From: yates@rtsc.com (John Yates)
Newsgroups: gnu.g++.bug
Subject: Possible bug in -M option of gcc-2.3.3
Date: 22 Jan 1993 21:45:36 -0500
Organization: GNUs Not Usenet
Distribution: gnu

gcc-2.3.3 on Sun sparc os 4.1.2:

I ran gcc with the -M option and got:

	$ gcc -M Name.cxx
	Name.cxx.o : Name.cxx rd.h /usr/local/include/rw/cstring.h ....

It seems to me that it should be:

	$ gcc -M Name.cxx
	Name.o : Name.cxx rd.h /usr/local/include/rw/cstring.h ....

The "Name.cxx.o" doesn't seem right.

John Yates
 Republic Telcom Systems Corporation
 6150 Lookout Road
 Boulder, CO 80301
 (303)530-8736
 yates@rtsc.com
From: dcb@us-es.SEl.DE (David Binderman 3841)
Newsgroups: gnu.g++.bug
Subject: Section 10.10C of the ARM & GNU G++ 2.3.3
Date: 21 Jan 1993 18:24:45 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Hello there,

I have GNU G++ 2.2.2 and GNU G++ 2.3.3 on a Sun 4 SPARC. I have tried out
both compilers with the code from Section 10.10C of the ARM page 233

2.2.2 produced the following

BW:f()
MW:g()
BMW::h()
BW:f()

2.3.3 produced the following 

W::f()
W::g()
BMW::h()
BW:f()

It seems that 2.2.2 is correct, but 2.3.3 is not.

The following memory layout seems to be used by both 2.3.3 and 2.2.2

BMW::BMW()
sizeof 28
0xf7fff858 0xf7fff86c
0xf7fff85c 0x3
0xf7fff860 0xf7fff86c
0xf7fff864 0x2
0xf7fff868 0x4
0xf7fff86c 0x1
0xf7fff870 0x40b0

I note with interest only one vtbl pointer. The ARM suggests, but does
not require, that there are three vtbl pointers in a BMW class. I
checked with cfront 3.0 and another C++ compiler, and they both agreed
that there can be three vtbl pointers in a BMW.

While I accept and recognise that different implementation strategies
of language features are permitted, it is not clear to me that two missing
vtbl pointers is a feature or a bug. I would appreciate your opinion.

Regards

David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841
From: solomon@cs.wisc.edu (Marvin Solomon)
Newsgroups: gnu.g++.bug
Subject: mysterious error message
Date: 26 Jan 1993 22:00:59 -0500
Organization: GNUs Not Usenet
Distribution: gnu

With g++ 2.3.3, the following program:
	int main(int, char**) {
		goto L;
		int i=0;
	L: return 0;
	}
generates the following error messages (and no others):
	bug14.c: In function `int  main (int, char **)':
	bug14.c:3: crosses initialization of `i'

In this simple test, it is clear that the word "goto" is omitted from
the message, but I had a heck of a time figuring out what was wrong when
this came up in a big program and both the goto and the label were
far from the line affected (the "3" in the message is the line number of
the initialization).
From: gparker@world.std.com (Glenn P Parker)
Newsgroups: gnu.g++.bug
Subject: gcc bug
Date: 25 Jan 1993 21:29:34 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: <gparker@world.std.com> (Glenn Parker)

Submitted on behalf of Nickolay Yatsenko at Software Emancipation
Technology, Inc., Waltham, MA.

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 fn_call2.C /usr/tmp/cca25955.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca25955.i -quiet -dumpbase fn_call2.cc -version -o /usr/tmp/cca25955.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
fn_call2.C: In function `int  main ()':
fn_call2.C:33: bad argument 0 for function `T::T (int)' (type was struct U)

// From ARM 5.2.2: 
// Assignments to non-const reference parameter where the 
// actual arg required a conversion.

struct T {
	int a;
	T(int aa) : a(aa) {}
};

struct U {
	int a;
	U(int aa) : a(aa) {}
	operator T() { return T(a); }
};

void f_constT(const T & t)
{
  int i = t.a + 1;
}

int main(void)
{
  U u(0);
  f_constT(u);  // g++ cannot compile it, though cfront 2.1 and 3.0 can.

  return 0;
}
From: hogend@nlr.NL (hogendoorn r.a.)
Newsgroups: gnu.g++.bug
Subject: gcc-2.3.3 prototyping bug on MIPS
Date: 25 Jan 1993 21:01:12 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Consider the following simple program:
-------------------------------------------------------------
				// Chapter 9 - Program 6
#include <ostream.h>

template<class ANY_TYPE>
ANY_TYPE maximum(ANY_TYPE a, ANY_TYPE b)
{
   return (a > b) ? a : b;
}

int
main (void) {
   int x = 12;
   int y = -7;
   float z = 3.1415;
   char ch = 'A';

   cout << maximum(x, y) << endl;
   cout << maximum(-34, y) << endl;
   cout << maximum(z, float(y)) << endl;
   cout << maximum(z, float(x)) << endl;
   cout << maximum(ch, 'X') << endl;
}


// Result of execution

//       12
//       -7
//    3.141
//   12.000
// X
-----------------------------------------------------------
This compiles and runs fine with gcc-2.2.2.
With gcc-2.3.3 this generates the following errors:

~rdps/bin/g++ -v -save-temps templat1.C -o tt
...... cpp stuff omitted
 /home/nlr/rdps/lib/gcc-lib/mips-sysv/2.3.3/cc1plus templat1.i -quiet -dumpbase templat1.cc -version -o templat1.s
GNU C++ version 2.3.3 [AL 1.1, MM 33] RISC-OS System V Mips compiled by GNU C version 2.3.3.
 as -nocpp -EB -v -o templat1.o templat1.s
/usr/lib/cmplrs/cc/as0 -v -G 8 -EB -g0 -O1 templat1.s -o /tmp/hogend/ctmaa27274 -t /tmp/hogend/ctmsta27274 
as0: main maximum maximum 
as0: Error: templat1.C, line 6: .ent must precede the definition of the symbol maximum
as0: Error: templat1.C, line 6: Conflicting definition of symbol maximum
maximum 
as0: Error: templat1.C, line 6: .ent must precede the definition of the symbol maximum
as0: Error: templat1.C, line 6: Conflicting definition of symbol maximum

0.02u 0.12s 0:00.7 20%

Upon examination of the .s files for gcc-2.2.2 and gcc-2.3.3, it appears
that gcc-2.2.2 generates three entrypoints: maximum__Fff, maximum__Fii and
maximum__Fcc, whereas gcc-2.3.3 generates three times: maximum, which is
obviously an error.
From: hilfingr@tully.cs.berkeley.edu (Paul N. Hilfinger)
Newsgroups: gnu.g++.bug
Subject: Access control error?
Date: 26 Jan 1993 21:50:31 -0500
Organization: GNUs Not Usenet
Distribution: gnu

The following program compiles without error under gcc-2.3.3.  It
should instead give an error message, since f is not accessible
through D.  Substituting the commented-out declaration of x causes gcc
to correctly identify an error.  For some reason, the extra level of
derivation makes a difference.

P. Hilfinger

Session:

% gcc-2.3.3 -v -Wall -o misc misc.C
Reading specs from /usr/sww/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/sww/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 -Wall misc.C /usr/tmp/cca04944.i
GNU CPP version 2.3.3 (sparc)
 /usr/sww/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca04944.i -quiet -dumpbase misc.cc -Wall -version -o /usr/tmp/cca04944.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
 as -o /usr/tmp/cca049441.o /usr/tmp/cca04944.s
 /usr/sww/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/ld -e start -dc -dp -o misc /lib/crt0.o -L/usr/sww/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3 -L/usr/sww/lib /usr/tmp/cca049441.o -lgcc -lc -lgcc
% 

Source: 

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

class C: public A {
private:
    void f() {  }
};

class D : public C {
};

int main()
{
    D* x = new D;
//  C* x = new C;

    x -> f();
    return 0;
}
From: gparker@world.std.com (Glenn P Parker)
Newsgroups: gnu.g++.bug
Subject: gcc bug
Date: 25 Jan 1993 21:29:33 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: <gparker@world.std.com> (Glenn Parker)

Submitted on behalf of Nickolay Yatsenko at Software Emancipation
Technology, Inc., Waltham, MA.

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 new2.C /usr/tmp/cca25900.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca25900.i -quiet -dumpbase new2.cc -version -o /usr/tmp/cca25900.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
new2.C: In function `int  main ()':
new2.C:6: warning: initializer list being treated as compound expression
new2.C:6: Internal compiler error.
new2.C:6: Please report this to `bug-g++@prep.ai.mit.edu'.

// Bug. Operator new on type of pointer to function.
typedef int (**PPF)(int);

int main(void)
{
  PPF pf2 = new (int (*) (int));     // internal compiler error on this line.

  return 0;
}
From: cote@tesecau.iro.umontreal.ca (Marcel Cote)
Newsgroups: gnu.g++.bug
Subject: Problem with increment operator
Date: 22 Jan 1993 21:08:43 -0500
Organization: Universite de Montreal, Canada
Distribution: gnu

To whom it may concern,

	This letter is to ask if you have any information concerning a discrepancy
I found while preparing data for a course.  The machine I was working on was a 
Sparc II with the operating system SunOS release 4.1.3.  There are no problems for 
compiling but at execution there is a segmentation fault.  The version of the 
compiler was gcc 2.3.3.  The fault line is indicated below.  If you omit the      
incrementation operator, the problem is corrected.  If I'm correct the syntax
is not faulty, even your debugger will permit to display the result. 

main()
{ char *a= "a";
  printf("%c\n",++a[0]);
}
From: solomon@cs.wisc.edu (Marvin Solomon)
Newsgroups: gnu.g++.bug
Subject: failure to munge template function name
Date: 22 Jan 1993 21:47:04 -0500
Organization: GNUs Not Usenet
Distribution: gnu

// Problem with template functions in  g++ version 2.3.3
// The compiler appears to be forgetting to munge the names of the functions
// it generates for version of g (they are both called "g").  Needless to say,
// the assembler is not very happy about it.  Under Ultrix, the message is
//
// as0: Error: bug3.c, line 10: .ent must precede the definition of the symbol g
// as0: Error: bug3.c, line 10: Conflicting definition of symbol g
//
// (twice).  The generated assembly code is reproduced below.  Note the
// two copies of "g": one that calls O__Fc and one that calls O__Fi.

void O(char);
void O(int);

template <class Arg>
class Template {
public:
	Arg i;
};

template <class Arg> void g(Template<Arg> &x) { O(x.i); }

void f() {
	Template<int> ti;
	Template<char> tc;
	g(ti);
	g(tc);
}

/*
	.file	1 "bug3.c"

 # GNU C++ 2.3.3 [AL 1.1, MM 33] DECstation running ultrix compiled by GNU C

 # Cc1 defaults:

 # Cc1 arguments (-G value = 8, Cpu = default, ISA = 1):
 # -quiet -dumpbase -o

gcc2_compiled.:
	.text
	.align	2
	.globl	f__Fv

	.loc	1 22
	.ent	f__Fv
f__Fv:
	.frame	$fp,32,$31		# vars= 8, regs= 2/0, args = 16, extra= 0
	.mask	0xc0000000,-4
	.fmask	0x00000000,0
	subu	$sp,$sp,32
	sw	$31,28($sp)
	sw	$fp,24($sp)
	move	$fp,$sp
	addu	$4,$fp,16
	jal	g
	addu	$2,$fp,20
	move	$4,$2
	jal	g
	j	$L2
	j	$L1
$L2:
$L1:
	move	$sp,$fp			# sp not trusted here
	lw	$31,28($sp)
	lw	$fp,24($sp)
	addu	$sp,$sp,32
	j	$31
	.end	f__Fv
	.align	2

	.loc	1 20
	.ent	g
g:
	.frame	$fp,24,$31		# vars= 0, regs= 2/0, args = 16, extra= 0
	.mask	0xc0000000,-4
	.fmask	0x00000000,0
	subu	$sp,$sp,24
	sw	$31,20($sp)
	sw	$fp,16($sp)
	move	$fp,$sp
	sw	$4,24($fp)
	lw	$2,24($fp)
	lb	$3,0($2)
	move	$4,$3
	jal	O__Fc
	j	$L4
	j	$L3
$L4:
$L3:
	move	$sp,$fp			# sp not trusted here
	lw	$31,20($sp)
	lw	$fp,16($sp)
	addu	$sp,$sp,24
	j	$31
	.end	g
	.align	2

	.loc	1 20
	.ent	g
g:
	.frame	$fp,24,$31		# vars= 0, regs= 2/0, args = 16, extra= 0
	.mask	0xc0000000,-4
	.fmask	0x00000000,0
	subu	$sp,$sp,24
	sw	$31,20($sp)
	sw	$fp,16($sp)
	move	$fp,$sp
	sw	$4,24($fp)
	lw	$2,24($fp)
	lw	$4,0($2)
	jal	O__Fi
	j	$L6
	j	$L5
$L6:
$L5:
	move	$sp,$fp			# sp not trusted here
	lw	$31,20($sp)
	lw	$fp,16($sp)
	addu	$sp,$sp,24
	j	$31
	.end	g
*/
From: gparker@world.std.com (Glenn P Parker)
Newsgroups: gnu.g++.bug
Subject: gcc bug
Date: 25 Jan 1993 21:29:11 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: <gparker@world.std.com> (Glenn Parker)

Submitted on behalf of Nickolay Yatsenko at Software Emancipation
Technology, Inc., Waltham, MA.

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 enum_9.C /usr/tmp/cca25966.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus /usr/tmp/cca25966.i -quiet -dumpbase enum_9.cc -version -o /usr/tmp/cca25966.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
enum_9.C: In method `void  X::f (enum X::S)':
enum_9.C:18: parse error before `='

// C++. From ARM 3.1c Name Spaces:
// "A name S can be declared as a type (... enum) and as a non-type (...) in
// a single scope"

// Declare a data object `E' in the same (`class  member') scope as 
// an enum type `E', and try to use it in member function.

class X {
	enum S { blue, pink };
	int S;			
public:
	void f (enum S arg) ;
};

void X::f (enum S arg)
{
	S = arg;	// g++ gives error on this line.
}
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.bug
Subject: Re: 2.3.3: premature dtor of temp?
Date: 26 Jan 1993 22:14:44 -0500
Organization: U. C. Berkeley
Distribution: gnu
Summary: it's legal (for now)

In article <9301242117.AA04053@cs.rice.edu> dougm@cs.rice.edu (Doug Moore) writes:
>The program that follows demonstrates (I think) that under some
>circumstances, g++ destroys a temporary prematurely.  The ARM is a bit
>too vague to let me say with complete confidence that this is a bug,
>but it certainly ought to be.

The g++ behavior (early destruction of temporaries) is legal according to
the ARM.  This is partly because the ARM is so permissive on this subject.
See the gnu.g++.help FAQ; also, you might take a look at recent discussion
on comp.std.c++ about what the ANSI C++ committee is doing about the
destruction of temporaries issue (they are still debating it).

Sun C++ is a port of cfront, which destroys temporaries very late (at
the end of the containing scope).  If you write a program that depends on
this behavior, you have written a non-portable program, and you'll have
problems on other compilers as well.

It appears that eventually ANSI will mandate that temporaries live
longer than they do now, but not (necessarily) as long as they do in
cfront.  When that happens, you can expect the g++ maintainers to
conform.

See the FAQ for some suggestions on how to work around problems caused
by this.  Basically, you can give the temporary a name (by using it
to initialize a reference), guaranteeing that it will live until the
end of scope of that name.


--
Joe Buck	jbuck@ohm.berkeley.edu