HDTenEightyP/NetNews huggingface dataset:
From: dougm@cs.rice.edu (Doug Moore)
Subject: pragma interface blocks inlining new-with-placement
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 12 Apr 1992 06:17:12 GMT

The following program

-------cut here---------
#include <new.h>

class foo
{
public:
  int baz;
  foo(int b): baz(b) {}
};

main()
{
  foo* foop = (foo*) malloc(sizeof(foo));
  foop = new {foop} foo(4);
}
-------cut here---------

where new.h comes from libg++-2.0,
does not link successfully.

-------cut here---------
cd /marsh/comp212/.jnkk/
c++ -g -Wall -v bug.cc
Reading specs from /marsh/comp212/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /marsh/comp212/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 -g -Wall bug.cc /usr/tmp/cca14672.i
GNU CPP version 2.1 (sparc)
 /marsh/comp212/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca14672.i -quiet -dumpbase bug.cc -g -Wall -version -o /usr/tmp/cca14672.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o bug.o /usr/tmp/cca14672.s
 /marsh/comp212/lib/gcc-lib/sun4/2.1/ld -e start -dc -dp /lib/crt0.o -L/marsh/comp212/lib/gcc-lib/sun4/2.1/ -L/marsh/comp212/lib/ bug.o -lg++ -lm -lgcc -lc -lg -lgcc
ld: Undefined symbol 
   ___nw__FiPv 
collect: /usr/bin/ld returned 2 exit status

Compilation exited abnormally with code 1 at Sun Apr 12 01:05:36
-------cut here---------

However, when I comment out the #pragma interface line of new.h, it
does link successfully.  The file new.h includes an inline static
definition of the function that is claimed to be undefined.

I am not making the same complaint as the gentleman who complained
that nm showed a particular symbol to be undefined.  I am complaining
that inlining does not happen in the presence of #pragma interface, at
least for operator new with placement syntax.

That is why I'm sending this to g++.bug, not to libg++.bug.

Sparc 2.  Sunos 4.1.  Gcc 2.1, with Tiemann and Stump patches.

Doug Moore
(dougm@cs.rice.edu)


Newsgroups: gnu.g++.bug
From: ang@theory.lcs.mit.edu (William Ang)
Subject: initialization bug
Organization: MIT Lab for Computer Science
Distribution: gnu
Date: Thu, 16 Apr 1992 16:59:00 GMT

g++ version 2.1 running on SunOS 4.1.1.  The initialization of variable
is not correct.

----------------------------------------------------
int main(int argc);
/* here is the problem */
double toprand = pow(2,31) - 1;
/* */
int main(int argc)
{
  cout << "toprand = " << toprand << "\n";
  cout << "toprand = " << pow(2,31) - 1 << "\n";
  return(1);
} 

===========================================================================
RUN

osprey% g++ -O -o testx testx.cc -lm
osprey% testx
toprand = 0                 <--- it should be 2.14748e+09
toprand = 2.14748e+09

Moving the variable declaration inside main() seems to help.


Newsgroups: gnu.g++.bug
From: earl@jade.ab.CA (Earl Locken)
Subject: g++ 2.1 on a sun3 dumps core on assigment to static member
Organization: Jade Simulations International, Inc., Calgary, AB, Canada
Distribution: gnu
Date: Fri, 10 Apr 1992 16:24:54 GMT

    G++ dumps core when trying to compile the following code.  The
code compiles using Sun's C++ 2.1 compiler.

	// This may look like C code, but it is really -*- C++ -*-
	
	class base {
	      protected:
		double Sim_time;
	
	      public:
		base() { Sim_time = -1.0;};
		base(double d) { Sim_time = d;};
	
		static base ZERO;
	};
	
	base base::ZERO = base(0.0);
	
     Here are the messages from the GNU 2.1 compiler.

	g++ -v -c base.c
	Reading specs from /usr/local/lib/gcc-lib/sun3-sunos4.1.1/2.1/specs
	gcc version 2.1
	 /usr/local/lib/gcc-lib/sun3-sunos4.1.1/2.1/cpp -lang-c++ -v \
		-undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus \
		-Dmc68000 -Dsun -Dunix -D__mc68000__ -D__sun__ \
		-D__unix__ -D__mc68000 -D__sun -D__unix \
		-D__HAVE_68881__ -D__mc68020__ -Dmc68020 base.c \
		/usr/tmp/cca10731.i 
	GNU CPP version 2.1 (68k, MIT syntax)
	 /usr/local/lib/gcc-lib/sun3-sunos4.1.1/2.1/cc1plus \
		/usr/tmp/cca10731.i -quiet -dumpbase base.cc -version \
		-o /usr/tmp/cca10731.s 
	GNU C++ version 2.1 (68k, MIT syntax) compiled by GNU C version 2.1.
	/usr/local/bin/gcc: Internal compiler error: program cc1plus \
		got fatal signal 11 
-- 
Earl Locken						earl@jade.ab.ca
Jade Simulations International

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Constructor not called
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 11:34:33 GMT

Shouldn't you use gas and GNU ld or collect?  Sounds like an
installation problem to me.

> From: Ron.Sommeling@cwi.nl (Ron Sommeling)
> Newsgroups: gnu.g++.bug
> Subject: Constructor not called
> Message-Id: <5858@charon.cwi.nl>
> Date: 15 Apr 92 10:00:46 GMT
> Organization: CWI, Amsterdam
> To: bug-g++@prep.ai.mit.edu

> Machine: SPARCstation 1 running SunOS 4.1.1
> Compiler: g++ 2.1

> % cat t.C
> #include <iostream.h>

> class q {
> public:
> 	q(int i) { cout << "constructor with i = " << i << endl; }
> 	~q() { cout << "destructor" << endl; }
> };

> q a(3);

> main() {
>   q b(2);
> }
> % g++ t.C
> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/specs
> gcc version 2.1
>  /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 t3.C /usr/tmp/cca03214.i
> GNU CPP version 2.1 (sparc)
>  /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/cc1plus /usr/tmp/cca03214.i -quiet -dumpbase t3.cc -version -o /usr/tmp/cca03214.s
> GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
>  as -o t3.o /usr/tmp/cca03214.s
>  ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/ -L/usr/local/lib/ t3.o -lg++ -lgcc -lc -lgcc
> % ./a.out
> constructor with i = 2
> destructor


> Shouldn't that be:
> 	constructor with i = 3
> 	constructor with i = 2
> 	destructor
> 	destructor

Newsgroups: gnu.g++.bug
From: Ron.Sommeling@cwi.NL (Ron Sommeling)
Subject: Constructor not called
Organization: CWI, Amsterdam
Distribution: gnu
Date: Wed, 15 Apr 1992 10:00:46 GMT

Machine: SPARCstation 1 running SunOS 4.1.1
Compiler: g++ 2.1

% cat t.C
#include <iostream.h>

class q {
public:
	q(int i) { cout << "constructor with i = " << i << endl; }
	~q() { cout << "destructor" << endl; }
};

q a(3);

main() {
  q b(2);
}
% g++ t.C
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 t3.C /usr/tmp/cca03214.i
GNU CPP version 2.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/cc1plus /usr/tmp/cca03214.i -quiet -dumpbase t3.cc -version -o /usr/tmp/cca03214.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o t3.o /usr/tmp/cca03214.s
 ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/ -L/usr/local/lib/ t3.o -lg++ -lgcc -lc -lgcc
% ./a.out
constructor with i = 2
destructor


Shouldn't that be:
	constructor with i = 3
	constructor with i = 2
	destructor
	destructor

Ron Sommeling <Ron.Sommeling@cwi.nl>

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: templates in g++
Keywords: really stupid question
Organization: Harvey Mudd College
Distribution: gnu
Date: Sat, 4 Apr 1992 00:33:57 GMT

skohn@cs.ucsd.edu (Scott Kohn) writes:

> - Is there a way of getting one globally linkable instantiation
>   of a template class?

>...
>share the same code.  However, the current g++ 2.0 implementation
>generates local code only.  That is, g++ generates print() code in
>foo.o and also generates print() code in bar.o -- even though the
>code is identical (both are for an int template).

>I'm writing a large template class and I would really like to avoid
>this type of unnecessary code duplication.  Any suggestions?

My first suggestion would be to avoid writing any large template classes in
g++ until the template functionality reaches beta; it is extremely crippled
right now.

For instance, this program:

template<class T> class Bunk {
    T data;
  public:
    Bunk<T>& returnme() { return *this; }
};

main()
{
    Bunk<int> intbunk;
}

produces the compile errors:

bunk.cpp:6: parse error before `>'
bunk.cpp: In method `int & Bunk<int>::returnme ()':
bunk.cpp:6: cannot convert to a reference type
bunk.cpp:6: warning: control reaches end of non-void function

under G++ 2.1.

Failing that, my suggestion would be to look into using the #pragma
interface and #pragma implementation directives.  They may or may not have
any bearing on templates; I don't know much about them.

My next suggestion would be to put the function definitions in a .cc file
together with the declarations of all the instantiations you're going to be
using, and link that in with your program.

Borland C++'s linker is smart enough to see that the template
instantiations are duplicated and merge duplicates, but most UNIX boxes
don't have linkers that know about C++...

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Clarification of constructor/operator= problem
Organization: Harvey Mudd College
Distribution: gnu
Date: Sun, 12 Apr 1992 11:36:35 GMT

This code demonstrates the bug:

-----
class Bunk {
    int d;
  public:
    Bunk(int i) { d = i; }
};

main() {
    Bunk b(1);			// works (calls Bunk(int))
    Bunk a(b);			// works (copies b into a w/o fn call)
    Bunk* ap = new Bunk(b);	// ERROR: tries to call Bunk(int) with b
    a = b;			// works
    a.operator=(b);		// ERROR: can't find operator=(Bunk&)
    return 0;
}
-----

Errors:

test.cc: In function `int  main ()':
test.cc:10: bad argument 0 for function `Bunk::Bunk (int)' (type was class
Bunk) 
test.cc:12: no member function `Bunk::operator ='

So the most obvious uses of the copy constructor and operator= are covered.
However, the use of T* = new T(T&) is rather common...

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Copy constructor/operator= again
Organization: Harvey Mudd College
Distribution: gnu
Date: Sun, 12 Apr 1992 10:07:01 GMT

In an earlier post I said that the bug wherein g++ doesn't generate the
copy constructor and operator= properly could be avoided simply by
declaring them.

I was wrong; g++ still doesn't generate the code.  Silly me.

Is this bug fixed in 2.2?

--
Jason Merrill
jason@jarthur.claremont.edu


Newsgroups: gnu.g++.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: bottomless recursion in stream output
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 22:49:13 GMT

Consider the following program:
---- cut here ---------
#include <iostream.h>

main()
{
  for(int i = 0 ; i < 396 ; i++)
    {
      cerr << "i = " << i << "\n";
      cerr << "AAAAAAAAAAAA\n";
    }
}
---- cut here ---------

Seems innocent, doesn't it?

Well, if one compiles it with g++2.1*, using a version of libg++-2.0
compiled with g++2.1* on a sparc2, sunos 4.1, Sun loader, collect2,
and one runs it, it dies with a bottomless recursion.  The last thing printed is

i = 395

and the death occurs in the attempt to print the newline at the end of
that line.  Significantly, that newline happens to be the 8193rd
character of output produced by this program.

The bottomless recursion has the following (partial) backtrace as it
begins its descent into the void:

#0  filebuf::overflow (this=0x1a5f8, c=10) at filebuf.C:213
#1  0x11674 in streambuf::sputc (this=0x1a5f8, c=10)
    at /marsh/comp212/gnu/libg++-2.0/libg++/iostream/streambuf.h:278
#2  0x5718 in filebuf::overflow (this=0x1a5f8, c=10) at filebuf.C:261
#3  0x11674 in streambuf::sputc (this=0x1a5f8, c=10)
    at /marsh/comp212/gnu/libg++-2.0/libg++/iostream/streambuf.h:278
#4  0x5718 in filebuf::overflow (this=0x1a5f8, c=10) at filebuf.C:261
#5  0x1199c in streambuf::sputn (this=0x1a5f8, s=0x2299 "", n=1) at streambuf.C:46
#6  0x68d0 in filebuf::sputn (this=0x1a5f8, s=0x2298 "\n", n=1) at filebuf.C:546
#7  0xa98c in operator<< (stream=@0x1a694, s=0x2298 "\n") at iostream.C:506
#8  0x2310 in main () at bug.cc:7

and here is the (routine) compiler output from compiling the program:

c++ -g -Wall -v bug.cc
Reading specs from /marsh/comp212/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /marsh/comp212/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 -g -Wall bug.cc /usr/tmp/cca25242.i
GNU CPP version 2.1 (sparc)
 /marsh/comp212/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca25242.i -quiet -dumpbase bug.cc -g -Wall -version -o /usr/tmp/cca25242.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o bug.o /usr/tmp/cca25242.s
 /marsh/comp212/lib/gcc-lib/sun4/2.1/ld -e start -dc -dp /lib/crt0.o -L/marsh/comp212/lib/gcc-lib/sun4/2.1/ -L/marsh/comp212/lib/ bug.o -lg++ -lm -lgcc -lc -lg -lgcc

Compilation finished at Mon Apr 13 17:48:29


I wish I could suggest a patch, but the code is too opaque for me.

Doug Moore (dougm@cs.rice.edu)

* with Tiemann and Stump patches applied


Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Copy constructor/operator= generation not done
Organization: Harvey Mudd College
Distribution: gnu
Date: Sun, 12 Apr 1992 06:19:17 GMT

Situation #1:

If some constructors are defined and the copy constructor isn't, g++
assumes that it doesn't exist, such that the call 

new classname(*this);

generates an error such as

Dictionary.c: In method `class Object* Dictionary::shallowCopy ()const ':
Dictionary.c:43: bad argument 0 for function `Dictionary::Dictionary
  (unsigned int (=  DEFAULT_CAPACITY ))' (type was class Dictionary)

(The code that produced this error is in the NIHCL v3.0, Object.h and
Dictionary.[ch]; I can send it to you on request)

Solution:  Declare classname(classname&) explicitly.

Situation #2:

If operator= is not defined for class A and class B calls A::operator=, an
error such as

Dictionary.c: In method `void  Dictionary::operator = (const class
  Dictionary&)':
Dictionary.c:51: no member function `Set::operator ='

is generated.  Although operator= is not inherited exactly, it still needs
to be defined implicitly.  Rules for generating the implicit operator= can
be found in the ARM, section 12.8.

Again, declaring operator=(classname&) explicitly solves the problem.

Again, the pertinent code is in Object.h, Dictionary.[ch] and Set.h.  In
fact, the operator= that should be called eventually is the one in ArrayOb.

I see this as a serious bug, albeit one with a simple workaround.  I also
believe that the two problems have a single cause...

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Fool on a Pedestal)
Subject: Re: Incorrect 'conversion to reference of read-only variable' error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 19:22:14 GMT

>>>>> On Fri, 10 Apr 92 10:47:07 +0200, Ulrich Windl <c9524@rrzc1.rz.uni-regensburg.de> said:

> I don't know what your ARM is (the red/gold ANSI draft standard?), but
> you are right of course.

The Annotated C++ Reference Manual, by Margaret A. Ellis and Bjarne
Stroustrup.  This is the ANSI base document, and the closest thing to a C++
standard available now.

> (I wonder how you can quote that fast)

Good index.

>>   That's a philosophical issue which is not really relevant to this
>>   discussion.

> Procedural abstraction I'd call it. Is OOP worth anything if you must
> look inside every procedure (sorry, method) to find out whether the
> constants you pass are still the same afterwards.  You'll probably want
> to tell me that side-effects should be documented, but if so, why don't
> you pass a copy of it.  And if the method receiving a pointer to a
> non-const object does not modify it why aren't you using a const ?
> Besides that the ANSI draft I know tells a lot about C++ but almost
> nothing about goals of OOP. I recomment reading Bertrand Meyers's book
> about OOP and Eiffel.

No one will argue that C++ is one of the "truer" OOPLs... In this
particular instance, the at method is supposed to return an Object*&.  If
there isn't one at the index specified, what do you return?  The NIHCL
decided to return the nil object.  Unfortunately, nil isn't of type
Object*&, so it needed to be cast to the correct type.  This is not with
the intention of modifying nil (a singularly bad idea, I agree), but
allowing functions of this nature to return a consistent value.  There is
no way to return a const object from a non-const method except by casting
it to a non-const object.  libg++ just doesn't make the nil objects const.
If you have a better solution, I'd be interested to hear it...

> That's not philosophical; that's the material your programs are built
> from.

True, but I still think g++ ought to implement the C++ standard as it
stands...

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  GCC 2.1: bizarre error messages when returning a reference
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 10:26:44 GMT

This problem has been fixed.  The next release of gcc should be better.

> From: gb@cs.purdue.edu (Gerald Baumgartner)
> Newsgroups: gnu.g++.bug
> Subject: GCC 2.1: bizarre error messages when returning a reference
> Message-Id: <18392@ector.cs.purdue.edu>
> Date: 10 Apr 92 04:30:49 GMT
> Organization: Department of Computer Science, Purdue University
> To: bug-g++@prep.ai.mit.edu

> 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: ...

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re: Bug Report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 09:18:24 GMT

This problem has been fixed.  The next version of gcc should work
better.  Here are the patches if you would like to have it working
before then.

--------------
Doing diffs in cp-typeck.c.~1~:
*** cp-typeck.c.~1~	Thu Apr  2 13:38:20 1992
--- cp-typeck.c	Thu Apr  9 01:57:08 1992
***************
*** 1884,1891 ****
  	  TREE_USED (function) = 1;
  	}
  
!       function = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (function)),
! 			 function);
      }
    else
      {
--- 1884,1893 ----
  	  TREE_USED (function) = 1;
  	}
  
!       fntype = build_type_variant (TREE_TYPE (function),
! 				   TREE_READONLY (function),
! 				   TREE_THIS_VOLATILE (function));
!       function = build1 (ADDR_EXPR, build_pointer_type (fntype), function);
      }
    else
      {


> Date: Mon, 6 Apr 92 11:41:47 EDT
> From: purtill%idacrd@uunet.uu.net (Mark Purtill)
> Message-Id: <9204061541.AA24193@>
> To: bug-gcc@prep.ai.mit.edu
> Subject: Bug report
> Resent-From: bug-gcc-request@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 >bugs.C
> volatile void abort() ;
> volatile void oink() ;
>     void
> oink() {
>     abort() ;
>     }
> ^D
> % gcc -c bugs.C
> bugs.C: In function `void  oink ()':
> bugs.C:6: warning: `volatile' function does return
> %
> 	Of course, the warning is erroneous, since oink calls abort,
> which doesn't return, so `oink' doesn't either.  This problem did not
> occur on g++ 1.37.1 (I think), which we had here until recently.

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Incorrect 'conversion to reference of read-only variable' error
Organization: Harvey Mudd College
Distribution: gnu
Date: Fri, 3 Apr 1992 09:23:15 GMT

This code:

class Object {
...
	static Object* const nil;
...
}

...

Object*& Arraychar::at(int)
{
	shouldNotImplement("at");
	return (Object*&)nil;
}

produces the error

Arraychar.c:291: conversion to reference of read-only variable `nil'

Here g++ should quietly cast away nil's const-ness.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug