HDTenEightyP/NetNews huggingface dataset:
From: kramer@cs.toronto.edu (Bryan M Kramer)
Subject: cout and output redirection
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 11:00:48 GMT

I'm using g++2.2.2. I have a program that writes to standard output
using cout << ...; This works fine in a terminal window. When it comes
to output redirection, nothing happens:

prog | more 

prints nothing and

prog > /tmp/foo

results in an empty file. Any clues?

|Bryan M. Kramer, Ph.D.	      416-978-7330, fax 416-978-1455|
|Department of Computer Science, University of Toronto      |
|6 King's College Road, Room 283E			    |
|Toronto, Ontario, Canada      M5S 1A4                      |
From: tmcconne@sedona.intel.com (Tom McConnell~)
Subject: Re:  g++ 2.2.2 runs constructor even if operator new() returns 0 - gnu.g++.bug #2467
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 07:45:04 GMT

In article <18lnbdINN1no@agate.berkeley.edu>, jbuck@forney.berkeley.edu (Joe Buck) writes:
> The history so far: the issue is the fact that g++ does not generate
> a test for operator new() returning 0 before invoking the constructor
> in an expression
> 
> 	new Foo
> 
> where Foo has a constructor.  The reason for this is to generate more
> efficient code; the new_handler function can be used to trap on
> out-of-memory conditions for the common case where all you can do when
> memory runs out is quit.

  <stuff deleted>

> I think that a good interim solution, until the language has exceptions
> or the ANSI committee decides the issue, is to make the generation of the
> test conditional; if the user supplies
> 
> 	-ftest-new
> 
> then the compiler will generate code to test the result of operator new;
> if not, the test will be omitted.

  <stuff deleted>

>  This would imply that "-fno-test-new"
> would turn the flag off.
> 

> --
> Joe Buck	jbuck@ohm.berkeley.edu
> 

  This sounds like a good start. The nice part of this is that it will be easier
to identify problems with the new operator.

    Cheers,

    Tom McConnell

 Tom McConnell          |     Internet: tmcconne@sedona.intel.com
 Intel, Corp. C3-91     |     Phone: (602)-554-8229
 5000 W. Chandler Blvd. | The opinions expressed are my own. No one in 
 Chandler, AZ  85226    | their right mind would claim them.

Newsgroups: gnu.g++.bug
From: pcm@cs.brown.edu (Peter C. McCluskey)
Subject: cc1plus got fatal signal 6
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 15:16:31 GMT

The following fails on a Sun 4/60:

extern  double DAT_EMPTY;
class DVector;
class Vector_Vtable
{
 public:
   virtual  DVector& operator-=(DVector& v1, DVector& v2) ;
   Vector_Vtable(){} 
};
class DVector
{
 public:
   double& operator[](int n)  { return v[n]; }
   DVector& operator-=( DVector& v2){return vtable->operator-=(*this,v2);}
   double *v;
   Vector_Vtable* vtable;
   class Vtable
   {
    public:
      virtual  DVector& operator+=(DVector& v1, DVector& v2)
      {
	 for(int i = 0; i < 1; ++i)
	 {
	    double t1 = v1[i];
	    double t2 = v2[i];
	    v1[i] = (t1 == DAT_EMPTY ? t2 : (t2 == DAT_EMPTY ? t1 : t1 + t2));
	 }
	 return v1;
      }
      Vtable() {}
   };
   DVector(int size);
};


kato% g++ -v t1.cc
Reading specs from /cs/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /cs/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/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 t1.cc /usr/tmp/cca29378.i
GNU CPP version 2.2.2 (sparc)
 /cs/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca29378.i -quiet -dumpbase t1.cc -version -o /usr/tmp/cca29378.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/cs/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

Newsgroups: gnu.g++.bug
From: solomon@cs.wisc.edu (Marvin Solomon)
Subject: g++ 2.2.2 seems to be forgetting a "const"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 05:09:58 GMT

[gjetost:~/persist/CCversion] cat bug2.c
// g++ 2.2.2 -Wall accepts this program without complaint.  When compiled
// with -pedantic, it says
//   "warning: user-defined conversion casting away `const'"
// In fact, the user-defined conversion is *NOT* casting away the const.
// Rather, it would appear that g++ is using the conversion sequence
//   B -> B& (trivial)
//     -> const B& (trival)
//     -> const A& (user-defined)
//     -> A&  (???)
// Interestingly, the message from cfront 3.0.1 is also misleading:
//   "error: no standard conversion of const A* to A&"
// It's not clear how an A* is ever created.
// Nonetheless, at least cfront properly gives an error.
extern "C" void printf(...);

struct A {
	int i;
};

struct B {
	int i;
	operator const A&() const;
};

B::operator const A&() const {
	static A a;
	a.i = i;
	printf("convert B to A at %x\n", &a);
	return a;
}

void f(A &a) {
	printf("A at %x is %d\n", &a, a.i);
}

main() {
	B b;
	b.i = 99;
	f(b);
}
[gjetost:~/persist/CCversion] g++ -v -Wall -pedantic bug2.c
Reading specs from /usr/gnu/lib/gcc-lib/decstation/2.2.2/specs
gcc version 2.2.2
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__ANSI_COMPAT -DMIPSEL -DR3000 -DSYSTYPE_BSD -D_SYSTYPE_BSD -Dbsd4_2 -Dhost_mips -Dmips -Dultrix -Dunix -D__ANSI_COMPAT -D__MIPSEL__ -D__R3000__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__ -D__bsd4_2__ -D__host_mips__ -D__mips__ -D__ultrix__ -D__unix__ -D__ANSI_COMPAT -D__MIPSEL -D__R3000 -D__SYSTYPE_BSD -D___SYSTYPE_BSD -D__bsd4_2 -D__host_mips -D__mips -D__ultrix -D__unix -Wall -pedantic -D__LANGUAGE_C__ -D_
_LANGUAGE_C -DLANGUAGE_C bug2.c /usr/tmp/cca23102.i
GNU CPP version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/cc1plus /usr/tmp/cca23102.i -quiet -dumpbase bug2.cc -Wall -pedantic -version -o /usr/tmp/cca23102.s
GNU C++ version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by GNU C version 2.2.2.
bug2.c: In function `int  main ()':
bug2.c:39: warning: user-defined conversion casting away `const'
 as -nocpp -EL -v -o bug2.o /usr/tmp/cca23102.s
/usr/lib/cmplrs/cc/as0 -v -G 8 -EL -g0 -O1 /usr/tmp/cca23102.s -o /tmp/ctmaa23115 -t /tmp/ctmsta23115 
as0: __opRC1A__C1B f__FR1A main 
0.0u 0.1s 0:00 18% 56+56k 0+8io 6pf+0w
/usr/lib/cmplrs/cc/as1 -v -G 8 -p0 -EL -g0 -O1 /tmp/ctmaa23115 -o bug2.o -t /tmp/ctmsta23115 
as1: __opRC1A__C1B f__FR1A main 
0.0u 0.1s 0:00 18% 80+73k 1+1io 8pf+0w
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/mips-tfile -v -o bug2.o /usr/tmp/cca23102.s
mips-tfile version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/ld -EL /usr/lib/cmplrs/cc/crt0.o -L/usr/gnu/lib/gcc-lib/decstation/2.2.2 -L/usr/lib/cmplrs/cc -L/usr/lib/cmplrs/cc -L/usr/gnu/lib bug2.o -lg++ -lgcc -lc -lgcc
[gjetost:~/persist/CCversion] a.out
convert B to A at 100012c0
A at 100012c0 is 99
[gjetost:~/persist/CCversion] exit
exit

script done on Mon Sep 14 10:08:26 1992

Newsgroups: gnu.g++.bug
From: dak@pool.INformatik.rwth-aachen.DE
Subject: template class member functions never expanded inline gcc-2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 01:57:46 GMT

In template classes no inline functions are generated regardless of
optimization level. This makes the template business (specific
efficient instances for general problems) rather ineffective.
Although it does not strictly qualify as a bug, it should not
be too hard to correct (some people will kill me for that remark)
that. Take the (sad) code for the following simple piece, which
can be cleaned up remarkably by removing the template.

I would like templates just to behave as efficient than their counter-
parts. If that means not sharing code between template instantiations,
so be it. The usual application will not use more than maybe two
instances of one template.

Reading specs from /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -D__unix__ -D__i386__ -D__unix -D__i386 -D__OPTIMIZE__ mm.cc /usr/tmp/cca00819.i
GNU CPP version 2.2.2 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/cc1plus /usr/tmp/cca00819.i -quiet -dumpbase mm.cc -O -version -o mm.s
GNU C++ version 2.2.2 (80386, ATT syntax) compiled by GNU C version 2.2.2.
template <class T>
class k {
	int n;
public:
	k(const int m) {
		n = m;
	}
};

main()
{
	k<int> j(5);
	return 0;
}


	.file	"mm.cc"
gcc2_compiled.:
.text
	.align 4
.globl main
main:
	pushl %ebp
	movl %esp,%ebp
	subl $4,%esp
	pushl $5
	leal -4(%ebp),%eax
	pushl %eax
	call __t1k1Zii
	xorl %eax,%eax
	leave
	ret
	.align 4
	.align 4
__t1k1Zii:
	pushl %ebp
	movl %esp,%ebp
	movl 8(%ebp),%eax
	movl 12(%ebp),%edx
	movl %edx,(%eax)
	leave
	ret
	.align 4



Newsgroups: gnu.g++.bug
From: dak@pool.INformatik.rwth-aachen.DE
Subject: (none)
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sat, 12 Sep 1992 22:11:45 GMT

Subject: g++ 2.2.2 does not recognize member pointers in arguments
Says it all. The following yields parsing error after y in the
declaration of test:

struct V {
	int x;
};

void test(int V::* y)
{
}

Newsgroups: gnu.g++.bug
From: brendan@cygnus.com (Brendan Kehoe)
Subject: g++ 2.2.2 does not catch missing targets of gotos
Reply-To: brendan@cygnus.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Sep 1992 19:53:49 GMT

> A missing target for a goto is not caught by the compiler, but rather
> turned into an undefined symbol detected at link time.  The resulting
> error message is not very informative.

This will be fixed in the next release of the compiler.


Newsgroups: gnu.g++.bug
From: kelly@ipld01.hac.com (Keith Kelly)
Subject: Errors compiling libg++ (v2.2) using g++ (v2.2.2) on Alliant FX/2800
Organization: Hughes Aircraft Company - Canoga Park, CA
              Imaging Guidance Design Laboratory
Distribution: gnu
Date: Fri, 4 Sep 1992 22:47:09 GMT

I'm trying to build the gnu libg++ (version 2.2) library using the gnu g++
(version 2.2.2) compiler on an Alliant FX/2800.  Whenever it tries to
compile any routine with the va_start function, it complains with:

warning: implicit declaration of function `__builtin_args_info'

The libg++ library eventually builds but it has unresolved references to
__builtin_args_info.  The va-i860.h references this function in the va_start
routine but it is unclear where this function is actually defined.  Any
suggestions?  Thanks in advance.

          
-- 
Keith Kelly                    Internet   : kelly@ipla01.hac.com         
"Of all the things I've lost   UUCP       : ...!usc!!hacgate!ipla01!kelly
 I miss my mind the most"      Phone      : (818) 702-2328
From: hoelken@iml.fhg.DE
Newsgroups: gnu.g++.bug
Subject: g++-2.2.2
Date: 9 Sep 92 19:16:47 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I have just installed version 2.2.2 of GNU CC / G++, but there seems to be a bug
in  assign a "?:"-expression to a 'complex' addressed variable;

I installed gcc/g++ 2.2.2 on a Sun4/75 running SunOS 4.1.1 using 
'configure sparc', 'make bootstrap' and
'make CC="stage2/gcc -Bstage2/" CFLAGS="-g -O" install'.

The following program was compiled without any options (only saying
g++ -c <name>.cc) and produced the compiler error

	Internal compiler error: program cc1plus got fatal signal 11

The compiler works fine with a previous release of cc1plus (2.1).


--- example -----
class class_x
{
public:
    int Local_Target;
};

class class_y
{
public:
    class_x* GetElement() { return Elem; }
    class_x* Elem;
};

main()
{
    int value;
    class_x* testx = new class_x;
    class_y* testy = new class_y;
    testy->Elem = testx;

    testy->GetElement()->Local_Target = ((value)?(1):(2));
}
------ end --------


			Thanks,

			Norbert Hoelken
			FhG-IML
			Joseph-vonFraunhofer-Str. 2-4
			D-4600 Dortmund 50 (FRG)
			email: hoelken@iml.fhg.de
Newsgroups: gnu.g++.bug
From: klamer@mi.eltn.utwente.NL (Klamer Schutte)
Subject: Bug overloading new() g++ 2.2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 15:04:18 GMT

Overloading operator new() does not seem to work properly.
Here is an example from ARM, pp 282:

1 klamer@mi7 12:58 77> cat new.cc
// Get size_t by including stdlib.h
#include        <stdlib.h>

class Y {
        // ...
public:
        void *operator new(size_t size, int flag);
};

// Y*   p1 = new Y;
Y*      p2 = new(7) Y;

This did compile fine using Sun C++ 2.1 (== cfront 2.1)

Using g++ 2.2.1 results in:

0 klamer@mi7 12:58 78> gcc -v -c new.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.1/specs
gcc version 2.2.1
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.1/cpp -lang-c++ -v -undef -D__GNU
C__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__
unix__ -D__sparc -D__sun -D__unix new.cc /tmp/cca12863.i
GNU CPP version 2.2.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.1/cc1plus /tmp/cca12863.i -quiet
-dumpbase new.cc -version -o /tmp/cca12863.s
GNU C++ version 2.2.1 (sparc) compiled by GNU C version 2.2.1.
new.cc:11: parse error before `7'

So a parse error is given on legal (IMHO) code.

Klamer


Klamer Schutte			Tel: +31-53-892778	Fax: +31-53-340045
Faculty of electrical engineering -- University of Twente, The Netherlands
preferred: klamer@mi.el.utwente.nl     SMTP: klamer@utelmi01.el.utwente.nl


Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC 2.2.2, cp-typeck.c: wrong number of arguments in function calls
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Tue, 15 Sep 1992 04:29:28 GMT

In cp-typeck.c, on lines 4646, 4647, 5002, and 5020, the function
`build_unary_op' is called with 2 arguments instead of 3.

I did not check calls to `build_unary_op' from other files.

--Gerald

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  operator new with placement
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 07:59:41 GMT

The non-standard workaround is to use the new { ... } ... syntax
instead of the new ( ... ) ... syntax.

It is still a known problem, and one day will be fixed.

> From: jorgnsn@qucis.queensu.ca (John Jorgensen)
> Message-Id: <1992Sep14.212640.742@qucis.queensu.ca>
> Organization: Computing & Information Science, Queen's University at Kingston
> Date: Mon, 14 Sep 1992 21:26:40 GMT
> Apparently-To: gnu-g++-bug@watmath.uwaterloo.ca
> To: bug-g++@prep.ai.mit.edu

> Are there any known problems with g++ 2.2.2's handling of the new operator
> when it is given an explicit placement option?  While trying to understand
> a problem g++ was having with the output of a code generator, I tried
> it on the following trivial example of explicit placement, simplified

>     // example of placement argument to new, taken from Lippmann, "C++ Primer".

>     #include <iostream.h>
>     #include <new.h>

>     class Foo {
>     public:
> 	int val;
> 	Foo() {val = 0;}
>     };

>     char *buf = new char[sizeof(Foo)];

>     main() {
> 	Foo *pb = new ((void *)buf) Foo;

> 	// check that objects were placed in buf.
> 	if ( (char*)pb == buf)
> 	    cout << "Operator new worked!: pb: " << pb << " buf: " << (void*)buf << endl;

> 	return 0;
>     }

> This works with our copy of AT&T C++ 3.0, but g++ gets a syntax error:

>     g++ -v -o new new.c
>     Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
>     gcc version 2.2.2
>      /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/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 new.c /usr/tmp/cca00711.i
>      GNU CPP version 2.2.2 (sparc)
>       /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca00711.i -quiet -dumpbase new.cc -version -o /usr/tmp/cca00711.s
>       GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
>       new.c: In function `int  main ()':
>       new.c:15: parse error before `('

> I am doing something dumb?  Is there a workaround?
From: dak@pool.INformatik.rwth-aachen.DE (David Kastrup)
Newsgroups: gnu.g++.bug
Subject: g++-2.2.2 does not support label references
Date: 15 Sep 92 16:50:42 GMT
Distribution: gnu
Organization: GNUs Not Usenet

gcc has this functionality using the unary && operator. g++ hasn't.
The following does not compile under g++:
main() {
	void *p;
	gurke: p = &&gurke;
}

Reading specs from /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -D__unix__ -D__i386__ -D__unix -D__i386 bug.cc /usr/tmp/cca01653.i
GNU CPP version 2.2.2 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/cc1plus /usr/tmp/cca01653.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca01653.s
GNU C++ version 2.2.2 (80386, ATT syntax) compiled by GNU C version 2.2.2.
bug.cc: In function `int  main ()':
bug.cc:3: parse error before `&&'
Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  gcc 2.2.1 mishandles types in C++ conditionals
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 07:40:06 GMT

This problem should not exist in the next release of gcc.

> Date: Wed, 10 Jun 92 21:26:30 PDT
> From: eggert@twinsun.com (Paul Eggert)
> Message-Id: <9206110426.AA07003@farside.twinsun.com>
> To: bug-g++@prep.ai.mit.edu

> gcc 2.2.1 wrongly complains about the following program:

> 	char *d;
> 	main() { d = d ? "" : d; }

> Here's a transcript that illustrates the problem.

> 	$ gcc t.cc
> 	t.cc: In function `int  main ()':
> 	t.cc:2: assignment between incompatible pointer types

> Replacing `d ? "" : d' with the logically equivalent `!d ? d : ""'
> makes the bug vanish!

Newsgroups: gnu.g++.bug
From: dave@hiauly1.hia.nrc.ca (John David Anglin)
Subject: Problem with const on hp730 in gcc-2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 13:08:05 GMT

When I try to build groff-1.6 under hpux 8.07 on an hp730 using gcc-2.2.2,
ld doesn't find the symbol "NULL_SYMBOL" when linking troff.  I have tried to
reduce the problem to the simplest possible form.  When I compile the routine
main with gcc -c and nm main.o|grep NULL, it gives the following output:

NULL_SYMBOL         |          |undef |code   |

Why is NULL_SYMBOL in the code segment?  If I remove "const" from
the line in symbol.h, then NULL_SYMBOL switches to the data segment.  What
gives?


// symbol.h

class symbol {
  const char *s;
};

extern const symbol NULL_SYMBOL;

// main.cc
// Short main program to exhibit problem with const.

#include "symbol.h"

main()
{
   symbol s = NULL_SYMBOL;
}

Dave Anglin
National Research Council of Canada

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Bug in the : ? operator
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 07:45:26 GMT

This problem should not exist in the next release of gcc.

> From: garp@isy.liu.se (Johan Garpendahl)
> Message-Id: <garp.708856796@isy.liu.se>
> Organization: Dept of EE, University of Linkoping
> Date: 18 Jun 92 08:39:56 GMT
> Apparently-To: gnu-g++-bug@sunic.sunet.se
> To: bug-g++@prep.ai.mit.edu

> I have found something that I think is a bug in g++-2.2.2
> The gcc-2.2.2 frontend does not complain.
> Good old 1.40 (gcc & g++) does not complain.

> I have an SS1+ with SunOS 4.1.1.

> main() {
>     const char* str = "String 1";
>     
>     /* This works */     
>     if (str == 0)
> 	str = "String 2";
>     else
> 	str = str;
>     
>     /* This fails */
>     /* assignment between incompatible pointer types */
>     str = (str == 0) ? "String 2" : str;
> }

Newsgroups: gnu.g++.bug
From: keister@poincare.phys.cmu.edu (Bradley D. Keister)
Newsgroups: gnu.g++.bug
Subject: compiler warning, link problems
Date: 11 Sep 92 06:10:18 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I'm running g++ 2.2.2 on a DECstation 3100 and a Sun SPARC, and am
having trouble with the following code:

--------------
#include <stdio.h>
#include <math.h>
#include <Complex.h>

double test()
{
  Complex trash(4, 5);
//  Complex throwaway[2][2];
  return trash.real();
}

main()
{
  printf("4?: %8.2f\n", test());
  return 0;
}
--------------

If I uncomment the array declaration, then I get a compiler warning:

trash.c: In function `double  test ()':
trash.c:10: warning: control reaches end of non-void function

With the line commented out, there is no warning.

Furthermore, whether or not the array declaration is commented, the
linker either refuses to or can't find the math library (it's there -
I just built some other code which uses it extensively):

% g++ -o trash trash.c -lm
// trash.c: In function `double  test ()':
// trash.c:10: warning: control reaches end of non-void function
ld:
Undefined:
hypot
atan2
cos
sin
exp
cosh
sinh
log
pow
sqrt
collect: /usr/bin/ld returned 1 exit status

I don't know at this point what sort of code is generated alongside
the warning.

Brad Keister
Department of Physics
Carnegie Mellon University
Pittsburgh, PA 15213
(412) 268-2772 (office)
(412) 681-0648 (FAX)

internet:	keister@poincare.phys.cmu.edu
BITNET:		keister%poincare.phys.cmu.edu@CARNEGIE
Newsgroups: gnu.g++.bug
From: gs4t@virginia.edu (Gnanasekaran  Swaminathan)
Subject: Re: user-defined conversion used when not needed.
Reply-To: gs4t@virginia.edu (Gnanasekaran  Swaminathan)
Organization: University of Virginia
Distribution: gnu
Date: Tue, 15 Sep 1992 18:20:51 GMT

solomon@cs.wisc.edu (Marvin Solomon) writes:
: [gjetost:~/persist/CCversion] cat bug.c
: // Bug in g++ 2.2.2.
: // The call f(d) can be resolved either by
: //   Derived -> Derived& (trivial, ARM 13.2, p318)
: //      -> Base& (standard conversion 4.7)

Standard conversion applies only to accessible base classes
(ARM 4.7, p38).


: // or by
: //   Derived -> Base& (user-defined convertion Derived::operator Base&())
: // According to ARM 13.2, p. 318, paragraph [3]
: // "Of sequences not mentined in [2], those with only standard and
: // trivial conversions are better than all others."
: // Thus the user-defined conversion should not be used.
: 
: extern "C" void printf(...);
: 
: class Base {
: public:
: 	int i;
: 	Base(int ii) : i(ii) {};
: };
: 
: class Derived : private Base {
: public:
: 	Derived(int ii) : Base(ii) {}
: 	operator Base&();
: };
: 
: Derived::operator Base&() {
: 	printf("Derived %d -> Base\n", i);
: 	Base *b = new Base(100*i);
: 	return *b;
: }
: 
: void f(Base &b) {
: 	printf("f(%d)\n",b.i);
: }
: 
: main() {
: 	Derived d(99);
: 	f(d);

Base of d is not accessible to f(Base&) and hence, it uses
the user defined conversion.


Newsgroups: gnu.g++.bug