HDTenEightyP/NetNews huggingface dataset:
From: rjc@cognet.ucla.edu (Robert Collins)
Subject: 2.1 bug - bad error and loops - sun4/4.1.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 19:15:43 GMT

configure sun4 on sun4/330 running SunOS4.1.2.

This is a pared down version of some code that I (and previous versions
of g++) think is correct.  2.1 loops, generating an incorrect error
message.  For some reason, it loses its mind about the CM_geometry
class.  I am very anxious for a fix, if someone happens upon the
bug.

Thanks,
rob collins
rjc@cs.ucla.edu

1 castor/cm++ $ cat foo.cc
typedef int CM_geometry_id_t;
typedef int CM_vp_set_id_t;
class CM_vp_set;

class CM_geometry {
  public:
    CM_geometry(const CM_geometry&);
    operator CM_geometry_id_t() const;
};

class CM_storage {
  public:
    CM_storage(const CM_vp_set* vp, const unsigned max = 64);
};

class CM_vp_set : public CM_geometry, public CM_storage {
    const CM_vp_set_id_t the_vp_set_id_t;
  public:
    CM_vp_set(const CM_geometry& g,
	      const CM_vp_set_id_t v,
	      const unsigned max = 64);
};

CM_vp_set::CM_vp_set(const CM_geometry& g,
		     const CM_vp_set_id_t v,
		     const unsigned max) :
    CM_geometry(g),
    CM_storage(this, max),
    the_vp_set_id_t(v)
{   
}
2 castor/cm++ $ gcc -v foo.cc
Reading specs from /usr/local/gnu/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /usr/local/gnu/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 foo.cc /usr/tmp/cca06276.i
GNU CPP version 2.1 (sparc)
 /usr/local/gnu/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca06276.i -quiet -dumpbase foo.cc -version -o /usr/tmp/cca06276.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.0.
foo.cc: In method `CM_vp_set::CM_vp_set (const class CM_geometry&, int, unsigned int (=  64 ))':
foo.cc:30: bad argument 0 for function `CM_geometry::CM_geometry (const class CM_geometry&)' (type was int )
foo.cc:30: in conversion to type `CM_geometry'
foo.cc:30: bad argument 0 for function `CM_geometry::CM_geometry (const class CM_geometry&)' (type was int )
foo.cc:30: in conversion to type `CM_geometry'
foo.cc:30: bad argument 0 for function `CM_geometry::CM_geometry (const class CM_geometry&)' (type was int )

[ killed with ^C ]

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Must already have been reported but...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 22:00:15 GMT

This appears to be a problem with libg++, please report it to the
	bug-g++-lib@prep.ai.mit.edu
mailing list.

> Message-Id: <9204141612.AA03057@life.ai.mit.edu>
> To: bug-g++@prep.ai.mit.edu
> Subject: Must already have been reported but...
> Date: Tue, 14 Apr 92 17:10:42 +0100
> From: Russel Winder <R.Winder@cs.ucl.ac.uk>

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

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ 2.1 on a sun3 dumps core on assigment to static member
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 19:43:17 GMT

This problem should be fixed in the next release of gcc.

> Newsgroups: gnu.g++.bug
> From: earl@jade.ab.ca (Earl Locken)
> Message-Id: <EARL.92Apr10092454@jsi-bwd.jade.ab.ca>
> Organization: Jade Simulations International, Inc., Calgary, AB, Canada
> Date: Fri, 10 Apr 1992 16:24:54 GMT
> To: bug-g++@prep.ai.mit.edu
> Subject: g++ 2.1 on a sun3 dumps core on assigment to static member

>     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 

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Nested types cause seg fault
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 21:48:27 GMT

This problem should be fixed in the next version of gcc.

> Newsgroups: gnu.g++.bug
> From: Jason Merrill <jason@jarthur.claremont.edu>
> Subject: Nested types cause seg fault
> Message-Id: <1992Apr12.070734.17107@muddcs.claremont.edu>
> Organization: Harvey Mudd College
> Date: Sun, 12 Apr 1992 07:07:34 GMT
> Apparently-To: bug-g++@prep.ai.mit.edu
> To: bug-g++@prep.ai.mit.edu

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

Newsgroups: gnu.g++.bug
From: laun@alcatel.co.AT (Wolfgang Laun)
Subject: GNU C++ bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 10:56:12 GMT

#! /bin/sh
# Bug report for GNU C++

# This is how I compiled:
cat <<XXX >wlbug.log

g++ version 1.37.1 (based on GCC 1.37)
 /usr/local/gnu/sun4/lib/gcc-cpp -+ -v -I/usr/local/gnu/sun4/lib/g++-include -undef -D__GNUC__ -D__GNUG__ -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ bug1.cc /usr/tmp/cca04454.cpp
 GNU CPP version 1.37.1
 /usr/local/gnu/sun4/lib/gcc-cc1plus /usr/tmp/cca04454.cpp -quiet
-dumpbase bug1.cc -version -o /usr/tmp/cca04454.s
GNU C++ version 1.37.1 (based on GCC 1.37) (sparc) compiled by GNU C
version 1.37.1.
default target switches: -mfpu -mepilogue
 /usr/local/gnu/sun4/lib/gcc-as -o bug1.o /usr/tmp/cca04454.s
 /usr/local/gnu/sun4/lib/gcc-ld -o bug1 -e start -dc -dp /lib/crt0.o -L/usr/local/gnu/sun4/lib bug1.o -lg++ -lg++ /usr/local/gnu/sun4/lib/gcc-gnulib -lc

XXX
# This is the complete source file:
cat <<XXX >wlbug.cc
#include <ostream.h>

class Rational {
  int E, D;
public:
  Rational() {};
  Rational( int enu, int den = 1 ): E(enu), D(den) {}
  operator double(){ return (double)E/D; }
  friend Rational operator +( Rational r1, Rational r2 );
  friend ostream& operator <<( ostream& s, Rational r );
};

Rational operator +( Rational r1, Rational r2 ){
  return Rational( r1.E*r2.D + r1.D*r2.E, r1.D*r2.D );
}

ostream& operator <<( ostream& s, Rational r ){
  return s << r.E << "/" << r.D;
}

int main() {
  Rational a(2), b(1,2), c;
  c = a + b;
  cout << a << " + " << b << " = " << c << "\n";
}
XXX

# Operating System is SunOS 4.xx
# Sparc Station

# Description of error:
cat <<XXX >wlbug.description
Depending on the presence of the conversion operator "double" in
class Rational, default assignment (together with the default copy
constructor?) appears to select a weird way:
a) convert rhs to double
b) convert rhs to int
c) construct a Rational from this int, using default for den
d) assign rhs to lhs

Defining a Rational& operator =( Rational r ) and the copy constructor
will also bypass the problem.
XXX
exit
--
           V             Wolfgang Laun         C=AT;A=ADA;P=Alcatel-W01 (X.400)
+---------------------+  Software Trainer                  <laun@alcatel.co.at>
| A  L  C  A  T  E  L |  Alcatel Austria AG               DVAX01::ED_LAUN (ANS)
+---------------------+  Scheydgasse 41                  +43-1-27722-2662 (tel)
     A U S T R I A       A-1210 Vienna, Austria/Europe   +43-1-27722-188  (fax)

Newsgroups: gnu.g++.bug
From: laf4@uhura.cc.rochester.edu (Lawrence Fried)
Subject: Libg++2.0 iostream overflow() crashes -- a workaround
Keywords: libg++2.0 iostream
Organization: University of Rochester (Rochester, NY)
Distribution: gnu
Date: Tue, 7 Apr 1992 05:53:14 GMT

	I experienced a problem with libg++2.0 compiled under GCC 2.0 
on an SGI 4-D system running Irix 4.0.1. 
filebuf::overflow(int) would go into an infinite recursive loop.
This problem would occur unpredictably in programs that did a moderate
amount of output (over 100 lines) to cout or cerr.  After a lot of poking
around, I noticed that do_flush() in filebuf.C would change the status of
the output stream from is_reading() == 0 to is_reading() == 1.  Since that
seemed illogical, I changed do_flush() so that it doesn't modify the 
is_reading() status.  I had 5 or 6 programs that crashed at various points; 
all the crashes went away after making this change.  Also, libg++ compiled with
this patch passed the I/O tests supplied with libg++.

	Since I don't fully understand the iostream code, I would use the
below patch with caution.  If you're experiencing nasty iostream
crashes, try the patch (you're probably desperate anyway). 

	To the developers of libg++ :: The new iostream is great. It
adds important functionality to the old stream class.  
HOWEVER, its maddening to use an I/O utility in all of your programs 
that crashes a lot.  Could you supply an "official" patch to the 
overflow() problem ?  This problem is too serious to wait a few months for 
the next version of libg++.

	Another note:  I found that cout was not always flushed after the
program finished (with or without my patch).  A quick fix that I used was 
to set the flag ios::unitbuf in the definition of cout.  
Does anybody else have a better fix ?

*** filebuf.C.old	Tue Apr  7 01:14:38 1992
--- filebuf.C	Fri Apr  3 00:41:12 1992
***************
*** 388,394 ****
  	to_do -= count;
  	ptr += count;
      }
!     setg(base(), pptr(), pptr());	
      setp(base(), base());
      return 0;
  }
--- 388,398 ----
  	to_do -= count;
  	ptr += count;
      }
!     if ( is_reading() ) {
! 	 setg(base(), pptr(), pptr());
!     } else {  // All pointers should be equal in put mode (LEF) 
! 	 setg(base(), base(), base() ) ;
!     }
      setp(base(), base());
      return 0;
  }

-------------------------------------------------------------------------------
	Larry Fried (larry@liouville.chem.rochester.edu)
	University of Rochester

Newsgroups: gnu.g++.bug
From: tll@cco.caltech.edu (Tal Lewis Lancaster)
Subject: Re: c++ template bugs
Organization: California Institute of Technology, Pasadena
Distribution: gnu
Date: Wed, 8 Apr 1992 23:47:51 GMT

stan@sabaac.mayo.edu writes:

>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??

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.

>Andrew Staniszewski
>Mayo Foundation
>staniszewski@mayo.edu

Tal Lancaster


Newsgroups: gnu.g++.bug
From: peter@csg.uwaterloo.ca (Peter Bumbulis)
Subject: sgetn bug
Organization: University of Waterloo
Distribution: gnu
Date: Mon, 13 Apr 1992 17:06:16 GMT

The following program
	#include <iostream.h>
	
	main(){
	    char buf[100];
	    cout.write(buf, cin.rdbuf()->sgetn(buf, sizeof(buf)));
	}

when given input
	#include <stdlib.h>

produces
	##include <stdlib.h>

i.e., the first character is duplicated.  (I'm not sure which version of
the library this is;  it was installed with gcc-2.1.)

Peter

Newsgroups: gnu.g++.bug
From: burton@heurikon.UUCP (Kevin Burton)
Subject: Undeclared variables inside an array index call to "new"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 19:34:45 GMT

OS: SunOS 4.0
Compiler: gcc/g++ 2.1 (using GNU ld 1.9, GNU as, 1.38)
Machine: Sun3/260

This bug has been reported already for gcc-1.40 but it still exists
for 2.1 so I am re-posting it.

Undeclared variables inside an array index in a call to "new" can generate
internal compiler errors.  The following code

struct foo
{
    int a;
    foo() : a(0) {}
};

struct bar
{
    foo * x,y;
    bar() 
    {
	x = new foo[(n+1)*(m+1)];
	y = new foo[(n+1)*(m+1)];
    }
};

Gives the following output:

burton@inno$ gcc -v -c bug2.cc
Reading specs from /usr/local/lib/gcc-lib/sun3os4/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/sun3os4/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 bug2.cc /usr/tmp/cca07263.i
GNU CPP version 2.1 (68k, MIT syntax)
 /usr/local/lib/gcc-lib/sun3os4/2.1/cc1plus /usr/tmp/cca07263.i -quiet -dumpbase bug2.cc -version -o /usr/tmp/cca07263.s
GNU C++ version 2.1 (68k, MIT syntax) compiled by GNU C version 2.1.
bug2.cc: In method `bar::bar ()':
bug2.cc:13: `n' undeclared (first use this function)
bug2.cc:13: (Each undeclared identifier is reported only once
bug2.cc:13: for each function it appears in.)
bug2.cc:13: `m' undeclared (first use this function)
gcc: Internal compiler error: program cc1plus got fatal signal 11

--
Kevin Burton                                mail: burton@inno.heurikon.com
Innovision Corporation                      uucp: heurikon!inno!burton
8000 Excelsior Drive Suite #304, Madison WI 53717 at&t: 608/831-4441

Newsgroups: gnu.g++.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: new.cc does not include new.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 22:13:26 GMT

In fact, no libg++ source file includes new.h, so that, with #pragma
interface being the way it is, sometimes a program that uses alternate
placement syntax for new fails to link.

Dougm


Newsgroups: gnu.g++.bug
From: geirp@ulrik.uio.no (Geir Pedersen)
Subject: g++/ndbm problem on Sparc (only ?)
Organization: Center for Information Technology Services, University of Oslo, Norway
Distribution: gnu
Date: Mon, 13 Apr 1992 20:19:29 GMT

I am having a problem with ndbm when being used by a g++ compiled
program on a sparc. It works fine on a Sun3, but gives a segmentation
violation on a sparc.

It works with 
   g++ version 1.40.3 (based on GCC 1.40)
on a Sun3, but fails with either of
   g++ version 1.39.0 beta (based on GCC 1.39)
   g++ version 1.40.3 (based on GCC 1.40)
on a sparc.

A small program to examplify follows below. The program will crash
with a segmentation violation in dbm_store().

As I need to get this working (:-), workarounds or fixes will be most
appreciated.

Thanks,

Geir Pedersen

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

#include <stdio.h>
#include <fcntl.h>

extern "C" {
#include <ndbm.h>
}

DBM		*ndbm;

main () 
{
   datum		key, content;
   long			ndbm_key;
   int 			res;
   char			*foo = strdup ( "Fritjof" );
   
   if ( !(ndbm = dbm_open ( "junk-ndbm", O_RDWR|O_CREAT, 0664 )) )
   {
      printf ( "Failed to open ndbm-file" );
      exit ( 1 );
   }
   
   content.dptr = foo;
   content.dsize = strlen(foo);
   
   ndbm_key = 4711;
   key.dptr = (char *) &ndbm_key;
   key.dsize = 4;
   
   res = dbm_store ( ndbm, key, content, DBM_INSERT );
   printf ( "dbm_store()=%d\n", res );
}

Newsgroups: gnu.g++.bug
From: bard@cutter.ssd.loral.com (James Woodyatt)
Subject: Template classes and incomplete classes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 02:50:24 GMT

The following code causes gcc-2.1's cc1plus to die and dump core inside
globalize_nested_type(). I'm trying to grok the code, but have so far
failed.

The code I've written here might be invalid, but I'm not sure -- no
one's answered my question about it on comp.std.c++ yet, and I couldn't
find anything in Stroustrup that said that I'm doing something patently
illegal...


My setup:

	./configure sun4

	non-standard directory tree

	Michael Tiemann's patch to cp-cvt.c to fix infinite loop
	    in type converision to reference.


Here is the code:

//-------------------------- foo.cc ---------------------------
template<class T>
class Foo
{
  public:
    typedef void (T::*Method)();

    Method method;

    void foo() { (*method)(); }

    Foo(Method m) : method(m)  { }
};


class Bar
{
  public:
    static Foo<Bar> foo;

    void alpha()  { }
    void beta()   { }
};

Bar::foo(&Bar::alpha);


int main()
{
    Foo f;

    f.foo();
    return 0;
}

//-------------------------- End of foo.cc ---------------------------------


Here is the compiler invocation:

g++ -v -O  -Wall -Wno-implicit -fpcc-struct-return  -I. -I/p2/proj.istc/src/h -c foo.cc
Reading specs from /share2/projects/proj.gnu/sun4/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /share2/projects/proj.gnu/sun4/lib/gcc-lib/sun4/2.1/cpp -lang-c++ -v -I. -I/p2/proj.istc/src/h -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -D__OPTIMIZE__ -Wall -Wno-implicit foo.cc /usr/tmp/cca01590.i
GNU CPP version 2.1 (sparc)
 /share2/projects/proj.gnu/sun4/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca01590.i -quiet -dumpbase foo.cc -O -Wall -Wno-implicit -version -fpcc-struct-return -o /usr/tmp/cca01590.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
NFS server kazoo not responding still trying
/share2/projects/proj.gnu/sun4/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11

Newsgroups: gnu.g++.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Incorrect 'type conversion required' error
Organization: Harvey Mudd College
Distribution: gnu
Date: Fri, 3 Apr 1992 09:15:32 GMT

This code:

void THIS::printOn(ostream& strm) const
{
    strm.fill('0');
    strm.width(2);
    strm << hex;
	for (register unsigned i=0; i<sz; i++) {
		if (i > 0) strm << "  ";
 		strm << "0x" << ((unsigned int)(unsigned char)v[i]);
	}
	strm << dec;
}

produces the errors

Arraychar.c:121: type conversion required for type `ostream'
Arraychar.c:126: type conversion required for type `ostream'

for the strm << {hex,dec} statements.

hex is declared as ios& hex(ios&); shouldn't g++ be able to convert
ostream& to ios& automatically?

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: constructors not called on new'ed array elements
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 12 Apr 1992 03:53:35 GMT

GNU C++ compiler version 2.1, with Tiemann and Stump patches.  Sunos
4.1. Sparc 2.  The program below prints

i = 1 (should be 5).

It demonstrates a bug.  The foo constructor is called only on the
first element of the array foo::array, not on all the elements as it
should be.

Thanks to Mark Wells for isolating this bug nicely.

Doug Moore
(dougm@cs.rice.edu)

Compiler output:
c++ -g -v -Wall wells.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 wells.cc /usr/tmp/cca06635.i
GNU CPP version 2.1 (sparc)
 /marsh/comp212/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca06635.i -quiet -dumpbase wells.cc -g -Wall -version -o /usr/tmp/cca06635.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o wells.o /usr/tmp/cca06635.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/ wells.o -lg++ -lm -lgcc -lc -lg -lgcc

Compilation finished at Sat Apr 11 22:47:49

Source code:
----------------cut here--------------------------------------------
#include <stream.h>

int i = 0;

class foo
{
private:
  static foo *array;
public:
  foo()
    {
      i++;
    }
};

foo* foo::array = new foo [5];

main()
{
  cerr << "i = " << i << " (should be 5).\n";
}


Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  pragma interface blocks inlining new-with-placement
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 21:53:57 GMT

I hate to give you the run around, but it IS a problem with libg++.
It sounds like there is a #pragma interface in new.h but there is no
corresponding #pragma implementation of that file.

Feel free to submit it again, over there in 
	bug-lib-g++@prep.ai.mit.edu

> Date: Sun, 12 Apr 92 01:17:12 CDT
> From: dougm@cs.rice.edu (Doug Moore)
> Sender: gnulists@ai.mit.edu
> Message-Id: <9204120617.AA07200@cs.rice.edu>
> To: bug-g++@prep.ai.mit.edu
> Subject: pragma interface blocks inlining new-with-placement

> 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