HDTenEightyP/NetNews huggingface dataset:
From: solomon@cs.wisc.edu (Marvin Solomon)
Subject: user-defined conversion used when not needed.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 04:40:40 GMT

[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)
// 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);
}
[gjetost:~/persist/CCversion] g++ -v bug.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 -D__LANGUAGE_C__ -D__LANGUAGE_C -DLA
NGUAGE_C bug.c /usr/tmp/cca22845.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/cca22845.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca22845.s
GNU C++ version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by GNU C version 2.2.2.
 as -nocpp -EL -v -o bug.o /usr/tmp/cca22845.s
/usr/lib/cmplrs/cc/as0 -v -G 8 -EL -g0 -O1 /usr/tmp/cca22845.s -o /tmp/ctmaa22856 -t /tmp/ctmsta22856 
as0: __4Basei __7Derivedi __opR4Base__7Derived f__FR4Base main 
0.0u 0.1s 0:01 8% 63+67k 0+8io 6pf+0w
/usr/lib/cmplrs/cc/as1 -v -G 8 -p0 -EL -g0 -O1 /tmp/ctmaa22856 -o bug.o -t /tmp/ctmsta22856 
as1: __4Basei __7Derivedi __opR4Base__7Derived f__FR4Base main 
0.0u 0.1s 0:00 17% 91+76k 1+1io 8pf+0w
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/mips-tfile -v -o bug.o /usr/tmp/cca22845.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 bug.o -lg++ -lgcc -lc -lgcc
[gjetost:~/persist/CCversion] a.out
Derived 99 -> Base
f(9900)
[gjetost:~/persist/CCversion] exit

script done on Mon Sep 14 09:38:10 1992

Newsgroups: gnu.g++.bug
From: kondo@akane.mech.ibaraki.ac.JP
Subject: argument matching depending on the def order
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 08:41:05 GMT

I'm not sure this is reported before or not, but here it goes. 
The following program compiled with g++-2.2.2 produces

A(int*)
B(double*)

I believe this is not a feature of C++.

Ryou Kondo (kondo@mech.ibaraki.ac.jp)
Dept of Mech Eng
Ibaraki Univ
--------------------------------------------------
#include <iostream.h>
//  check the order of declarations
class A {
public:
    void f(double* p) { cout << "A(double*)\n"; }
    void f(int* p) { cout << "A(int*)\n"; }
};

class B {
public:
    void f(int* p) { cout << "B(int*)\n"; }
    void f(double* p) { cout << "B(double*)\n"; }
};

main()
{
    A a;
    B b;

    a.f(0); 
    b.f(0);
}
--------------------------------------------------

Newsgroups: gnu.g++.bug
From: dak@pool.INformatik.rwth-aachen.DE
Subject: member pointer addressing compiled wrong in g++-2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Sep 1992 16:23:29 GMT

The following code produces a core dump when executed. Reason: the
compiler takes the structure offset passed in y, TRIES TO ACCESS
that memory address as if it were a pointer, and uses the value
from there as the offset. Memory fault, core dumped.

struct V {
	int x;
} X;

typedef int V::* Vptr;

int test(Vptr y)
{
	return X.*y;
}

main() {
	X.x = 5;
	return test(&V::x);
}

This produces the following assembly code with the following g++:

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/cca01000.i
GNU CPP version 2.2.2 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/i386-isc-isc/2.2.2/cc1plus /usr/tmp/cca01000.i -quiet -dumpbase bug.cc -version -o bug.s
GNU C++ version 2.2.2 (80386, ATT syntax) compiled by GNU C version 2.2.2.

	.file	"bug.cc"
gcc2_compiled.:
.text
	.align 4
.globl test__FPO1V_i
test__FPO1V_i:
	pushl %ebp
	movl %esp,%ebp
	movl 8(%ebp),%eax
---->	movl (%eax),%edx ; wrong, wrong, wrong!!!!!!
	addl $X,%edx
	movl (%edx),%eax
	jmp .L1
	.align 4
	jmp .L1
	.align 4
	jmp .L2
	.align 4
	jmp .L1
	.align 4
.L2:
.L1:
	leave
	ret
	.align 4
.globl main
main:
	pushl %ebp
	movl %esp,%ebp
	movl $5,X
	pushl $0
	call test__FPO1V_i
	addl $4,%esp
	movl %eax,%eax
	jmp .L3
	.align 4
	jmp .L3
	.align 4
	xorl %eax,%eax
	jmp .L3
	.align 4
	jmp .L3
	.align 4
.L3:
	leave
	ret
.comm X,4

Newsgroups: gnu.g++.bug
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: bug in GNU C++ 2.2.2 (template bug)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 00:52:56 GMT

GNU C++ 2.2.2 fails on the following template class definition (which
is legal according to BS):

	template <class K,K x>
	struct Foo {
		K y;
		Foo() { y = x; }
	};

arolla$ gcc -g -v -c foo.cc
Reading specs from /sym/gnu/lib/gcc-lib/sparc/2.2.2/specs
gcc version 2.2.2
 /sym/gnu/lib/gcc-lib/sparc/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 -g foo.cc /local/tmp/cca06301.i
GNU CPP version 2.2.2 (sparc)
 /sym/gnu/lib/gcc-lib/sparc/2.2.2/cc1plus /local/tmp/cca06301.i -quiet -dumpbase foo.cc -g -version -o /local/tmp/cca06301.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
foo.cc:1: parse error before `x'
foo.cc:4: syntax error before `{'
arolla$ 

Newsgroups: gnu.g++.bug
From: solomon@cs.wisc.edu (Marvin Solomon)
Subject: g++ 2.2.2 does not catch missing targets of gotos
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 12 Sep 1992 12:47:06 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.

Script started on Sat Sep 12 07:30:42 1992
$ cat bug.c
main() {
        if (1) goto found;
}
$ g++ -v bug.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__S> YSTYPE_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 -D__LANGUAGE_C__ -D__LANGUAGE_C -D
L> ANGUAGE_C bug.c /usr/tmp/cca12346.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/cca12346.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca12346.s
GNU C++ version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by GNU C version 2.2.2.
 as -nocpp -EL -v -o bug.o /usr/tmp/cca12346.s
/usr/lib/cmplrs/cc/as0 -v -G 8 -EL -g0 -O1 /usr/tmp/cca12346.s -o /tmp/ctmaa12357 -t /tmp/ctmsta12357 
as0: main 
0.0u 0.0s 0:00 15% 54+51k 0+8io 6pf+0w
/usr/lib/cmplrs/cc/as1 -v -G 8 -p0 -EL -g0 -O1 /tmp/ctmaa12357 -o bug.o -t /tmp/ctmsta12357 
as1: main 
0.0u 0.0s 0:00 20% 70+59k 1+1io 8pf+0w
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/mips-tfile -v -o bug.o /usr/tmp/cca12346.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 bug.o -lg++ -lgcc -lc -lgcc
ld:
Undefined:
$L3
collect: /usr/bin/ld returned 1 exit status
$ ^D
script done on Sat Sep 12 07:31:29 1992

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Bugs in GCC 2.1 (sun4/sunOS4.1.1)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 01:18:21 GMT

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

> Date: Thu, 2 Apr 92 17:37:05 +0200
> Message-Id: <9204021537.AA00212@larsen.chorus.fr>
> From: ev@chorus.fr (Eric Valette)
> To: bug-g++@prep.ai.mit.edu

> /*
> GCC version: 2.1
> Hardware :  sun4
> OS : sunOS 4.1.1

> this program crash gcc2.1. 
> -------------------------------------------------------------------
> */


> class myClass {
>     unsigned long nbWords;
> public:
> 	myClass(unsigned long = 0);
> 	~myClass();
> };

> inline myClass::myClass(unsigned long val) {nbWords = val;}
> inline myClass::~myClass() {}

> // Ok next line is badly written but the compiler should not crash!!!
> myClass a = myClass(1);

> ---------------------------------------------------------------------
> gcc -v -c ex.cxx
> gcc: Internal compiler error: program cc1plus got fatal signal 11
From: rajive@manhattan.cat.rpi.edu (Rajive Joshi)
Newsgroups: gnu.g++.bug
Subject: g++ 2.2.2 bug: program cc1plus gets fatal signal 11
Date: 9 Sep 92 05:15:32 GMT
Distribution: gnu
Organization: Rensselaer Polytechnic Institute, Troy NY

Hello!

The following code segment crashes the g++ 2.2.2 compiler--the program
cc1plus gets a fatal signal 11.  However it compiles perfectly with
the AT&T's CC compiler.  

-------------- sig11bug.cc --------
class A;
class B;

class A {
    static const int c;    // line A
public:
    B foo();
};

class B {
    static const double c; // line B
public:
    friend B A::foo();
};
------------------------------------

Furthermore, what is bizzare is that it compiles perfectly when the
name of the constants in lines A or B are different. But it crashes
when the names are the same, as is the case here. Can someone look
into this.

Thanks,

-Rajive



Script started on Wed Sep  9 00:52:24 1992

% g++ -v -sun4 -c sig11bug.cc


Reading specs from /depot/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs

gcc version 2.2.2

 /depot/gnu/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 sig11bug.cc /usr/tmp/cca25359.i

GNU CPP version 2.2.2 (sparc)

 /depot/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca25359.i -quiet -dumpbase sig11bug.cc -version -o /usr/tmp/cca25359.s

GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.

/depot/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11

% exit


script done on Wed Sep  9 00:54:06 1992
-- 
 ======================================================================
 Rajive Joshi              rajive@cat.rpi.edu               CII 8005
 Center for Advanced Technology    |  Rensselaer Polytechnic Institute
 in Automation & Robotics          |  Troy, NY 12180    (518) 276-3045
Newsgroups: gnu.g++.bug
From: anhaeupl@late.e-technik.uni-erlangen.DE (Bernd Anhaeupl)
Subject: gcc 2.2.2 calls wrong overloaded function
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 19:41:02 GMT

Systems:	1.)hp9000/720 (hpux 8.07)
		2.)Sequent386 (UNIX System V Release 3.2.0 i386 - DYNIX/ptx V1.3.1)
Config:  	1.)hp720-hpux --gas (with some patches)
		2.)???? (80386, BSD syntax)
compiler input:
test.cc:
----------------------- cut here --------------------------
extern double pow(double,int*);

extern "C" {
  extern int    printf(char*,...);
  extern double pow(double, double);
}

int main()
{
        printf("pow:%g\n",pow(2.0,3.0));
        return 0;
}
----------------------- cut here --------------------------
compiler output:
1.)
-------------------------------
$ gcc -v test.cc
Reading specs from /local/cross/share/gcc-sequent386_ptx-lib/specs
gcc version 2.2.2
 /local/cross/sequent386_ptx/lib/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -Di387 -D_SEQUENT_ -D__unix__ -D__i386__ -D__i387__ -D___SEQUENT___ -D__unix -D__i386 -D__i387 -D___SEQUENT_ test.cc /usr/tmp/cca08578.i
GNU CPP version 2.2.2 (80386, BSD syntax)
 /local/cross/sequent386_ptx/lib/cc1plus /usr/tmp/cca08578.i -quiet -dumpbase test.cc -version -o /usr/tmp/cca08578.s
GNU C++ version 2.2.2 (80386, BSD syntax) compiled by GNU C version 2.2.2.
test.cc: In function `int  main ()':
test.cc:10: incompatible types in argument passing
--------------------------------------

2.)
-------------------------------------
Reading specs from /users/late/gnu/lib/gcc-lib/hp720-hpux/2.2.2/specs
gcc version 2.2.2
 /users/late/gnu/lib/gcc-lib/hp720-hpux/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D_HPUX_SOURCE -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D___HPUX_SOURCE__ -D__hppa -D__hp9000s800 -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -D___HPUX_SOURCE test.cc /usr/tmp/cca26858.i
GNU CPP version 2.2.2 (hp9000s800)
 /users/late/gnu/lib/gcc-lib/hp720-hpux/2.2.2/cc1plus /usr/tmp/cca26858.i -quiet -dumpbase test.cc -version -o /usr/tmp/cca26858.s
GNU C++ version 2.2.2 (hp9000s800) compiled by GNU C version 2.2.2.
test.cc: In function `int  main ()':
test.cc:10: incompatible types in argument passing
--------------------------------------


It seems that the compiler wants to call pow(double,int*) instead of pow(double,double).

The bug disappears, if you move the "extern "C"{...}" block in front of the other prototype.

If somebody knows a patch for this problem please send it to me (via email!)

Bernd Anhdupl
(anhaeupl@late.e-technik.uni-erlangen.de)

Newsgroups: gnu.g++.bug
From: brendan@cygnus.com (Brendan Kehoe)
Subject: GCC 2.2.2: no error messages for uninitialized const's
Reply-To: brendan@cygnus.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 6 Sep 1992 02:56:51 GMT

The next release of the compiler will report them properly:

	foo.C:2: uninitialized const `o'
	foo.C:3: uninitialized const `i'
	foo.C:4: uninitialized const `p'

> Given the class declaration
> 
> 	class c { public: int foo (void); };
> 
> the declaration
> 
> 	const c o;
> 
> produces the error message
> 
> 	stdin:2: uninitialized const `o'
> 
> I would expect similar behavior for the declarations
> 
> 	const int i;
> 	c * const p;
> 
> but both pass without an error message.

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Palo Alto, CA                                  +1 415 322 3811

Newsgroups: gnu.g++.bug
From: gie@charon.er.usgs.gov (Gerald I. Evenden)
Subject: libg++ compilation problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 13:05:31 GMT

							BUG REPORT

I ran into some problems when trying to install libg++-2.2 library on a:

	Dell 433DE(33Mhz 486 processor), w/ 16Mb ram, 600+Mb disk,
	Dell SVR4, issue 2.2 Unix.

I had previously installed gcc 2.2.2 with the configuration of:
	i486-sysv4
and everything appeared to perform flawlessly and passed the stage3
compare test.

Installation of libg++ proceeded as follows:

$ configure i386-sysv4   ## (((note that i486 fails for this configure)))
Created "Makefile" in /home/gnu/libg++-2.2 using "config/mh-sysv4"
$ make
echo "# !Automatically generated from ./functions.def" "- DO NOT EDIT!" >needed2.awk
grep '^DEFVAR(' < ./functions.def | sed -e '/DEFVAR/s|DEFVAR.\([^,]*\).*|/\1/ { printf \"#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|' >>needed2.awk
grep '^DEFFUNC(' < ./functions.def | sed -e '/DEFFUNC/s|DEFFUNC.\([^,]*\).*|/\1/ { printf \"#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|' >>needed2.awk
cc -c -g -I. -I./../include -DUSG -DUSGr4 ./dummy.c
(cc  dummy.o  ) >errors 2>&1 || true
rm -f a.out dummy.o
echo "/* !Automatically generated from ./functions.def" "- DO NOT EDIT! */" >config.h
awk -f needed2.awk <errors >>config.h
cc -c -g -I. -I./../include -DUSG -DUSGr4 basename.c
          << LINES DELETED >>
cc -c -g -I. -I./../include -DUSG -DUSGr4 strsignal.c
echo "# !Automatically generated from ./functions.def" "- DO NOT EDIT!" >needed.awk
grep '^DEF(' < ./functions.def | sed -e '/DEF/s|DEF.\([^,]*\).*|/\1/ { printf \"\1\.o " }|' >>needed.awk
awk -f needed.awk <errors >needed-list
echo  >>needed-list
cc -c -g -I. -I./../include -DUSG -DUSGr4 index.c
          << LINES DELETED >>
cc -c -g -I. -I./../include -DUSG -DUSGr4 rindex.c
rm -rf libiberty.a
ar cq libiberty.a basename.o getopt.o getopt1.o obstack.o spaces.o concat.o fdmatch.o argv.o strerror.o strsignal.o index.o sigsetmask.o alloca.o getpagesize.o bcmp.o bzero.o bcopy.o random.o index.o rindex.o 
true libiberty.a
rootme=`pwd` ; export rootme; CC="gcc `if [ -f ${rootme}/../gcc/gcc ] ; then echo -I${rootme}/../gcc/include ; else echo ; fi`"; export CC; ./utils/gen-params  >tmp-params.h
mv tmp-params.h _G_config.h
gcc -g -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
(EOF):undefined name: .L_B5_e: Not a typewriter
(EOF):undefined name: .L_B5
make[2]: *** [AllocRing.o] Error 1
make[1]: *** [in-src] Error 1
make: *** [all-libg++] Error 1

Note that the C code appears to compile OK, but the C++ code fails.

Is there a patch?

Is there anything I can do to further assist or supply additional
information?

Thank-you.

Ciao. (Jerry)

Newsgroups: gnu.g++.bug
From: gs4t@virginia.edu (Gnanasekaran  Swaminathan)
Subject: Re: compiler warning, link problems
Reply-To: gs4t@virginia.edu (Gnanasekaran  Swaminathan)
Organization: University of Virginia
Distribution: gnu
Date: Sat, 12 Sep 1992 18:11:24 GMT

keister@poincare.phys.cmu.edu (Bradley D. Keister) writes:
: % 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

Try
	g++ -o trash trash.c -lg++ -lm
From: jbuck@ohm.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.bug
Subject: Re: bug in GNU C++ 2.2.2 (template bug)
Date: 9 Sep 92 05:02:06 GMT
Distribution: gnu
Organization: U. C. Berkeley

In article <9209082052.AA10566@idiap.ch> tmb@idiap.CH (Thomas M. Breuel) writes:
>GNU C++ 2.2.2 fails on the following template class definition (which
>is legal according to BS):
>
>	template <class K,K x>
>	struct Foo {
>		K y;
>		Foo() { y = x; }
>	};

Yes, Dr. Stroustrup said it's legal, but I'll be damned if I can find out
where in the ARM it says that (assuming no definition for K precedes this
line).  Has the ANSI committee cleaned this stuff up yet?  We need more of
a standard than "see what cfront does" or "ask Bjarne".

For this to be legal, the declaration of the first argument would need to
introduce a scope that includes the second argument, and matching
templates will get really fun .

I'm not just being a pain here -- I want to see a specification for
templates that is far more complete than the existing one.  One of the
main reasons for the problems with g++ templates, I've been told, is the
extreme vagueness of the specification.


--
Joe Buck	jbuck@ohm.berkeley.edu
From: dak@pool.INformatik.rwth-aachen.DE (David Kastrup)
Subject: template <class T, T ...> important!
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 20:17:51 GMT

There was some discussion going on whether the above construction
was legal.
Although it is not explicitly stated in ARM, it is a very important
construction, because:
Templates cannot be nested. Suppose you have a sort template that
should work as fast as possible on linked lists. It would look something
like:
template <class T, T * T::*link>
You could modify the link parameter to be a parameter for the
subroutine, but then you are replacing a compile time constant
by a variable which would usually assume one value anyhow.

Consider defining a Fourier transform working on arbitrary fields
with roots of 1.

Then you could use something like
template <class Field, unsigned N, Field * Nthroot>
and use it something like
Complex const NR = exp(2*pi*Complex(0,1)/N);
fft<Complex, 1024, &NR>.transform(...
or
Modular<64513> NR = 9; //Value is wrong
fft<Modular<64513>, 1024, &NR>.transform(...

Although it would work with complex numbers just as fast as usual,
it would without modification work even faster with other fields
as a base.

Other classes and functions might need other information
necessarily not included in the basic type, but being constant.

PLEASE let the template scopes begin immediately after their declaration,
not after the closing >.

Newsgroups: gnu.g++.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU C++ 1.41.0 installation report (2)
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 01:55:08 GMT

Let me comment on the installation of GNU C++ 1.41.0, together with
GNU C 1.41.0, on this 386/ix 2.0.2 system (waiting for Hurd :-).  I
will make these comments in a few bunches.  Here is the second.

* There is a spurious newline in HINTS which concatenates two
messages, so the 13th may be missed.  Here is a diff, in which I
rewrote the control characters ^_ and ^L as two characters each:

----->
--- 1.1	1992/09/10 23:33:03
+++ HINTS	1992/09/10 23:33:14
@@ -500,8 +500,7 @@
 Paul.
 (debra@research.att.com)
 
-^_
-^L
+^_^L
 1,,
 Return-Path: <bug-g++-request@prep.ai.mit.edu>
 Received: from Sun.COM (sun-barr) by teacake.sun.com (4.0/SMI-4.0)
-----<


* In make-links.g++, the expression ${CDIR}/* gives rise to:

----->
../make-links.g++: /usr/local/gnubin/ln: arg list too long
-----<

The following modification took care of this problem:

----->
--- 1.1	1992/09/11 01:37:42
+++ make-links.g++	1992/09/11 01:47:42
@@ -64,7 +64,7 @@
   insn-output.c insn-flags.h insn-config.h insn-codes.h"
 
 $remove -f config || $remove -rf config
-$symbolic_link ${CDIR} ./config 2>/dev/null || { mkdir ./config; $hard_link ${CDIR}/* ./config; }
+$symbolic_link ${CDIR} ./config 2>/dev/null || { mkdir ./config; find ${CDIR} -type f -exec $hard_link {} ./config \; ; }
 if [ ! -r ${CDIR} ]
 then
 	echo "$progname: unable to link \`${CDIR}'."
-----<

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.g++.bug
From: pcm@cs.brown.edu (Peter C. McCluskey)
Subject: pure virtual function definition rejected
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 15:29:24 GMT

class A
{
 public:
  virtual void foo() = 0;
};
void A::foo(){}

GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
td.cc: In method `void  A::foo ()':
td.cc:6: redefinition of `void  A::foo ()'
td.cc:4: here is the previous declaration of `void  A::foo ()'

cfront considers this legal.
According to r.10.3 (p 560 of Stroustrup 2nd. ed): "A pure
virtual function need be defined only if explicitly called ...".
See also Scott Meyers Effective C++, p 47.

Newsgroups: gnu.g++.bug