HDTenEightyP/NetNews huggingface dataset:
From: baentsch@informatik.uni-kl.DE (Michael Baentsch)
Subject: A Bug-Report - what else...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 23 Dec 1992 09:06:15 GMT

Hello (whatever you might be :-),
   I happened to find a bug within gcc-2.3.2, which is really only
the compiler's disability to point to a missing declaration:

   The following happened:

   .ProcessG.cc: In function `class Genotype* make_ProcessG_exemplar ()':
   .ProcessG.cc:98: Internal compiler error.
   .ProcessG.cc:98: Please report this to `bug-g++@prep.ai.mit.edu'.

, when I tried to compile '.ProcessG.h' (which I can send you on request
in its full length); this is an code extract from the crucial places:

The Header-File:
----------------
class Exemplar;
class Genotype {
	public:
		Genotype(char*, Boolean, char*);
		Genotype(Exemplar);
		virtual Genotype* make(char*, Boolean);
		virtual ~Genotype();
		char    *type() { return classname; };
	private:
		char    *savefile;
		char    *classname;
		Boolean save_me;
		Base    *proxy;
};

extern Genotype* processGenotype;
Genotype* make_ProcessG_exemplar();

class ProcessG : public Genotype {
	friend class Process;
	public:
******		ProcessG(Exemplar); <-- formerly missing declaration
		ProcessG(char*, Boolean, char*);
		Genotype        *make(char*, Boolean);
	private:
		int     test;
};

--------------------------------------------
The Body:
---------
Genotype* processGenotype;

Genotype* make_ProcessG_exemplar() {
	processGenotype = new ProcessG(Exemplar()); <-- crucial line
	return processGenotype;
}

/////////////////////////////

ProcessG::ProcessG(
	Exemplar        a
):Genotype(a)
{
}

...


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   These are the essential sources, that produced the error:
'g++' always finished to work with the above mentioned message, when it
tried to compile the 'crucial line' (see above).
   At the time the error occured, I had forgotten to enter the
'*****'-line and thus, I had not declared the constructor 
'ProcessG(Exemplar)' (although I had defined it in the '.cc'-File)

   The problem is - as far as I can judge it - that the compiler
wasn't able to detect that no contructor of the above mentioned form
has been declared; it would have been much more easy to detect my
fault (the missing declaration) if the compiler had found the mistake,
so I think it is something which should be corrected in later releases
of this really good compiler.

   After this quite long message, I'd like to wish anybody reading
this stuff a Merry Christmas and a Happy New Year (in case you are 
still working ;-)

Michael

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

Michael Baentsch		baentsch@informatik.uni-kl.de
AG Systemsoftware
University of Kaiserslautern

Bahnhofstr. 37			06894/51350
D-6670 St.Ingbert-Rb.

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

Newsgroups: gnu.g++.bug
From: stein-c@eng.buffalo.edu (Craig Steinberger)
Subject: Possible GCC-2.3.3 bug for SGI IRIS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 08:19:01 GMT

I am trying to use gcc v.2.3.3 on an SGI Iris running IRIX
4.0.5, and the 3.10 SGI compiler suite. GCC compiled with no problems,
when set up with configure --target iris4d. The problem comes when I try
to compile the libg++-2.3 library. 

There is a point in the compilation where the program utils/gen-params
generates a dummy C++ program to test the compiler. For reference, here
is the file dummy.C:

  struct filebuf {
      virtual int foo();
  };
  filebuf ff;
  extern "C" int FUNC(int);
  int FUNC(int i) { return i+10; }

When the script tries to compile this (or when it is done manually via
g++ dummy.C), the following results:

% gcc dummy.C
gcc: Internal compiler error: program cc1plus got fatal signal 11

and cc1plus dumps core.

Some poking around with a debugger indicates this is a segmentation
fault. The traceback looks like:

 0 init_lex() ["cp-lex.c":756, 0x43b16c]
 1 compile_file(name = 0x7fffc840 = "") ["toplev.c":1535, 0x46cae8]
 2 main(argc = 7, argv = 0x7fffc744, envp = 0x65) ["toplev.c":3285, 0x46fcec]

In the file cp-lex.c, I think the error corresponds to the line:

UNSET_RESERVED_WORD ("exception");

At this point I am clueless. Any help, suggestions, or corrections 
would be welcome.

Craig Steinberger
stein-c@eng.buffalo.edu

Newsgroups: gnu.g++.bug
From: hugh@sivs.COM (Hugh Daschbach)
Subject: Floating point exception during 2.3.1/2.3.2 build (i386-sysv3)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 27 Dec 1992 01:01:46 GMT

Just tried upgrading an i386-sysv3 (ESIX SysV R3.2) from 2.2.2 to
2.3.2 using patches downloaded from ftp.uu.net.  At the end of the
phase 1 build, "enquire" fails leaving the error message "***
Unexpected signal at point 19" at the tail of float.h.

I backed off to 2.3.1.  Same result.  I tried compiling with pcc
instead of the 2.2.2 gcc.  Same result.

Here's the compile of enquire.o:

./xgcc -B./  -DIN_GCC   -g     -DNO_MEM -DNO_STDDEF -DNO_LONG_DOUBLE_IO -O0 -I. -c ./enquire.c

Enclosed is a bt from running enquire under gdb:

$ gdb enquire
GDB 3.5, Copyright (C) 1989 Free Software Foundation, Inc.
There is ABSOLUTELY NO WARRANTY for GDB; type "info warranty" for details.
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "info copying" to see the conditions.
Reading symbol data from /u/gnu/gcc-2.2.2/enquire...done.
Function abort not defined.
Type "help" for a list of commands.
(gdb) r -f
Starting program: /u/gnu/gcc-2.2.2/enquire -f
/* float.h */
#ifndef _FLOAT_H___
#define _FLOAT_H___
/* Produced by enquire version 4.3, CWI, Amsterdam */

   /* Radix of exponent representation */
#define FLT_RADIX 2
   /* Number of base-FLT_RADIX digits in the significand of a float */
#define FLT_MANT_DIG 1
   /* Number of decimal digits of precision in a float */
#define FLT_DIG 0

Program received signal 8, SIGFPE
0x2d74 in fDiff (a=-2, b=0.375) (enquire.c line 2117)
2117	Number Diff ARGS2(Number, a, Number, b){Number r; Store(a-b, &r); return (r); }
(gdb) bt
#0  0x2d74 in fDiff (a=-2, b=0.375) (enquire.c line 2117)
#1  0x4201 in fprop (bits_per_byte=8) (enquire.c line 2327)
#2  0x7bf in main (argc=2, argv=(char **) 0x7ffffea4) (enquire.c line 730)
(gdb) c
Continuing.
*** Unexpected signal at point 19

/* For hints on dealing with the problem above
   see the section 'TROUBLESHOOTING' in the file ./enquire.c */

Program exited with code 01.
(gdb) q


I haven't a clue as to where to start looking for the problem.  If you
need any more documentation, please let me know.
__
Hugh Daschbach                  hugh@sivs.com
Member of the League for Programming Freedom
 -- write to league@prep.ai.mit.edu

Newsgroups: gnu.g++.bug
From: peta@thunder.mcrcim.mcgill.edu (Peter Whaite)
Subject: friend operator= declaration bug.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 2 Jan 1993 10:47:13 GMT

Weird things happen when a friend operator= function is declared within a
class.  See code comments below....

cd /home/tectum/peta/src/g++-bugs/
make -k bug10-report
uname -a
SunOS Thunder.McRCIM.McGill.EDU 4.1.2 1 sun4
cat bug10.cc
// -*- C++ -*-
//
// The first declaration of a friend operator= function is used as the
// default operator= declaration in any class that doesnt define its
// own.

class FooA
{
    friend FooA& operator=(FooA&,FooA&);
};

class FooB
{
    friend FooB& operator=(FooB&, FooB&);
};

class Foo
{
  public:
    // Declaring is enough to prevent the bug but it needs to be
    // implemented for ld (of course)
//    Foo& operator=(Foo&);
};

main ()
{
    Foo f1,f2;
    f1 = f2;
}
g++ -Wall -v -o bug10  bug10.cc
Reading specs from /local/gnu/lib/gcc-lib/sun4/2.3.3/specs
gcc version 2.3.3
 /local/gnu/lib/gcc-lib/sun4/2.3.3/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -Wall bug10.cc /usr/tmp/cca27698.i
GNU CPP version 2.3.3 (sparc)
 /local/gnu/lib/gcc-lib/sun4/2.3.3/cc1plus /usr/tmp/cca27698.i -quiet -dumpbase bug10.cc -Wall -version -o /usr/tmp/cca27698.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
bug10.cc: In function `int  main ()':
bug10.cc:28: bad argument 0 for function `operator = (class FooA&, class FooA&)' (type was class Foo)
make: *** [bug10-report] Error 1

Compilation exited abnormally with code 1 at Sat Jan  2 15:40:59


Newsgroups: gnu.g++.bug
From: tmcconne@sedona.intel.com (Tom McConnell~)
Subject: gcc-2.3.2 / libg++-2.3 / AIX-3.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 20 Dec 1992 10:07:11 GMT

  Howdy.

  Environment: IBM RS/6000, AIX-3.2.2
               gcc-2.3.2
               libg++-2.3

  I have finally gotten gcc-2.3.2 and libg++-2.3 up under AIX-3.2. For the
most part everything works fine. However, when running "make check" the
./iostream/test tFile generates a core dump:

gmake[6]: Entering directory `/a/stor/gnu/src/libg++-2.3/libg++/iostream/test'
./tFile < ./tFile.inp > tFile.out 2>&1
/bin/sh: 23589 Abort - core dumped
gmake[6]: [check-tFile-regular] Error 134 (ignored)


  Also, tformat "Encountered 1399 errors in 3988 tests.", and tiformat
"Encountered 335 errors in 5006 tests." These seem to be gcc-2.3.2 problems,
not libg++-2.3 errors.

  Just thought you'd like to know :)

    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: jw@peanuts.informatik.uni-tuebingen.de (Joerg Wedeck)
Subject: bug in g++ 2.3.2 ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 21 Dec 1992 16:20:05 GMT

Hi,

i probably have found a bug in g++ 2.3.2. Please look at the
following program (in the following named test.C):


#include <stream.h>

extern "C" int rand();

class test {
  int a, b;
public:
  test() {a=b=0;}
  test(int i) {a=b=i;}
};

main()
{
  test a,b;
  int r;

  r = rand();
  a = (test) r;		// this works fine
  b = (test) rand(); 	// this line causes the problem
}

Compilation of this program results in following error message:

snoopy% g++ -v test.C
Reading specs from /usr/local/gnu/lib/gcc-lib/sun4os4/2.3.2/specs
gcc version 2.3.2
 /usr/local/gnu/lib/gcc-lib/sun4os4/2.3.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 test.C /usr/tmp/cca14760.i
GNU CPP version 2.3.2 (sparc)
 /usr/local/gnu/lib/gcc-lib/sun4os4/2.3.2/cc1plus /usr/tmp/cca14760.i -quiet -dumpbase test.cc -version -o /usr/tmp/cca14760.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
test.C: In function `int  main ()':
test.C:19: Internal compiler error.
test.C:19: Please report this to `bug-g++@prep.ai.mit.edu'.
snoopy%


Regards,

	Joerg

--
--------------------------------+-------------------------------------
Joerg Wedeck                    | E-Mail: jw@peanuts.informatik\
Universitaet Tuebingen          |               .uni-tuebingen.de
Lehrstuhl fuer Techn. Informatik|
Sand 13                         |
7400 Tuebingen                  |
Germany                         |
--------------------------------+-------------------------------------


Newsgroups: gnu.g++.bug
From: allen@golem.ssc.gov (Michael Allen)
Subject: gcc internal compiler error
Reply-To: allen@ssc.gov
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Dec 1992 03:58:05 GMT

I am using gcc, version 2.2.2 on both a sun4c, sunos 4.1.1; and a
decstation 5000/120 runing ultrix 4.2.  The following gives an
internal compiler error:
cp-decl.c:2631: failed assertion `b != global_binding_level || TREE_PERMANENT (x)'
gcc: Internal compiler error: program cc1plus got fatal signal 4


Here are the details:
$ cat show-error.cc
template<class T> class Foo;

template<class T>
class Foo<T>
{
};

int
a_func ()
{
  Foo<int> fl;
  return 0;
}
$ gcc -v -c show-error.cc
Reading specs from /usr/local/lib/gcc-lib/decstation-ultrix4.2/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/decstation-ultrix4.2/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_PLUS_PLUS
__ -D__LANGUAGE_C_PLUS_PLUS -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C show-error.cc /usr/tmp/cca15416.i
GNU CPP version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix
 /usr/local/lib/gcc-lib/decstation-ultrix4.2/2.2.2/cc1plus /usr/tmp/cca15416.i -quiet -dumpbase show-error.cc -version -o /usr/tmp/cca15416.s
GNU C++ version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by GNU C version 2.2.2.
cp-decl.c:2631: failed assertion `b != global_binding_level || TREE_PERMANENT (x)'
gcc: Internal compiler error: program cc1plus got fatal signal 4

/*********************************************************************/
***  WARNING  WARNING  WARNING  WARNING  WARNING  WARNING  WARNING
***  The following text is inserted for entertainment purposes only.
***  It is not intended to persuade, insult, or offend anyone.  It is,
***  however, something that I found to be humorous and/or witty.  I
***  fully understand that not everyone would agree with my opinion.
***  I therefore ask that you either refrain from reading further, or
***  judge me favorably and accept the message in the spirit in which
***  it was sent.  The opinions expressed herein do not necessarily
***  represent those of my employer, my countrymen, or my people.
/*********************************************************************/

What they really mean by family values is: Watch more Television
                  --- Homer Simpson


Newsgroups: gnu.g++.bug
From: mnl@dtro.e-technik.TH-darmstadt.DE (Michael N. Lipp)
Subject: virtual function resolution bug in gcc-2.3.3
Organization: TH-Darmstadt
Distribution: gnu
Date: Sat, 2 Jan 1993 16:15:53 GMT

Compiling this program (using gcc-2.3.3 and Sparc/SunOS or
PC/Linux) results in the faulty output "M::F1". If you remove F1 and
F2 from class M (or declare GetC as first method) you get the correct
output T::GetC.

--------------------------------------------------
// -*- c++ -*-
#include <iostream.h>

class C
{
public:
  int i;
};


class M
{
private:
  C* c;

public:
  virtual void F1 ();
  virtual void F2 ();
  virtual C* GetC () = 0;
};

void M::F1 ()
{
  cout << "M::F1\n";
}

void M::F2 ()
{
  cout << "M::F2\n";
}

class F
{
private:
  C* c;

public:
  virtual C* GetC () = 0;
};

class T : public M, public F
{
private:
  C* c;

public:
  virtual C* GetC ();
};

C* T::GetC ()
{
  cout << "T::GetC\n";
  return c;
}


main ()
{
  T o;
  T* op = &o;
  op->GetC ();
}
--------------------------------------------------

Michael

--
-----------------,------------------------------,------------------------------
Michael N. Lipp  !  Institut fuer Datentechnik  !  Phone: 49-6151-163776
                 !  Merckstr. 25     ,----------'  Fax:   49-6151-164976
                 !  D-6100 Darmstadt ! E-Mail:
                 !  (Germany)        !     mnl@dtro.e-technik.th-darmstadt.de
-----------------'-------------------'-----------------------------------------

Newsgroups: gnu.g++.bug
From: R.A.Rayner@massey.ac.NZ (R.A. Rayner)
Subject: More on libg++ make failure for SPARC/SunOS 4.11 Rational.cc
Summary: problem lines in Rational.cc file
Keywords: Rational.cc,SPARC,SunOS4.1.1,libg++
Organization: Massey University, Palmerston North, New Zealand
Distribution: gnu
Date: Mon, 21 Dec 1992 23:03:18 GMT

Further to my Bug report about libg++ not making it on SPARC SunOS 4.1.1

Fatal compiler error 11 the offending lines in Rational.cc seem to be these
from the end of the file


int
Rational::fits_in_float() const
{
    return FLT_MIN <= *this && *this <= FLT_MAX;
}

int
Rational::fits_in_double() const
{
    return DBL_MIN <= *this && *this <= DBL_MAX;
}


Richard Rayner
Massey University

-- 
------------------------------------------------------------------------------
TYPE	god = INTEGER ;
VAR	EricClapton : god ;
------------------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: dov@ds20.dmi.stevens-tech.edu (Dov Kruger)
Subject: Your template bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 06:51:50 GMT

As of 2.3.1, nested templates as per my example were still not working,
although there may be another way to get the compiler to accept it.

> template <class T> class A {
> public:
>   T* _data;
>   class Iter {
>     T* _data;
>   };
> };


> main()
> {
>   A<int> x;
>   A<int>::Iter y;
> }


Newsgroups: gnu.g++.bug
From: tjm@hrt213.brooks.af.mil (Tim Miller)
Subject: Undefined symbol error
Organization: AL/HRTI, Brooks AFB
Distribution: gnu
Date: Tue, 29 Dec 1992 18:15:57 GMT

	I've been working on compiling RogueWave's Tools.h++ library
using g++; the lib compiled flawlessly under gcc 2.3.3, with libg++-2.3.
However, when linking a test program, I get the following:

ld: Undefined symbol 
   __vt$10ostrstream$3ios 
collect: /usr/bin/ld returned 2 exit status
*** Error code 1

	I called RogueWave and confirmed it's not a symbol in their
library.  Tech support was able to confirm that they use calls to ios
which should be supplied by libg++, so it's something wrong with
libg++-2.3.  Anyone have any insight, or (hopefully) a fix?

-- Cerebus <tjm@hrt213.brooks.af.mil>
"Learning C++ as I go..."


Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  [dave@hiauly1.hia.nrc.ca: gcc-2.1]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 21 Dec 1992 21:48:58 GMT

These problems has been fixed, and should not exist in the next
release of gcc.

> Date: Sun, 3 May 92 17:19:23 -0400
> From: John David Anglin <dave@hiauly1.hia.nrc.ca>

> I have been trying to get groff-1.05 and libg++-2.0 going on hp9000s730
> running hpux 8.07.  I am enclosing a context diff for gcc-2.1 which resolve
> several problems:

> 1)  Changes need to be made to collect2.c to make vprintf argument types
>     correct for hpux.  Further, collect2 must be compiled with CC=cc so
>     that system varargs is used rather than gcc varargs.  The va_list types
>     are incompatible.  This incompatibility prevents use of hpux varargs
>     routines with gcc.  It also causes problems in building libg++ because
>     the struct type used with gcc can't be cast to a pointer type.

Has been fixed (varargs are compatable now).

> 2)  ON_EXIT defined for hpux runs destructors on program termination.

Fixed.

> 3)  Bug fix to assemble_external fixes undefined reference problem in
>     #pragma interface code (inline routines) and makes the virtual function
>     table global.  This is needed for filebuf initialization in libg++.

Fixed.

> There are several other problems in the c++ mode which I am aware of but
> have no solution:

> 4)  -O generates bad code and should not be used at the moment.

Fixed.

> 5)  There are problems with const.  E.g., "extern const struct a;"
>     generates a code space reference.  Also, don't try to multiply a
>     long const with a long.

Fixed.

> 6)  Function arguments which in turn call other functions are not
>     always handled properly.  In one dump I examined, the primary
>     function was called before its arguments were evaluated.  The
>     argument evaluation then trashed the stack.  In other cases,
>     improperly aligned offsets are generated for storage of
>     temporary variables on the stack.  Several cases of this problem
>     exist in the gtroff program.  I eventually got gtroff to work by
>     explicitly defining intermediate variables wherever I
>     encountered a problem.

Fixed.

Newsgroups: gnu.g++.bug
From: picone@csc000.CSc.ti.COM (Joe Picone)
Subject: Warning message: control reaches end of non-void function
Organization: Tsukuba Research and Development Center
Distribution: gnu
Date: Sat, 26 Dec 1992 10:42:35 GMT

This code:

#include <stdlib.h>

class foo {
private:
  int x;
public:
  foo() {};
  int check(int i);
  volatile void exit_handler() {exit(-1);}
};

int foo::check(int i) {
  if (i > 0)
    {exit_handler();}
  else
    {return 0;}
}

volatile void foo1() {exit(1);}

int foo2 (int argc) {
  if (argc > 2)
    {foo1();}
  else
    {return 0;}
}


produces the following warning message when compiled with 
"gcc -c -Wall foo.C":

	warning: control reaches end of non-void function

Note that this only occurs with the member function version of this
example. The function version, included above, doesn't produce a
warning message.

This is no doubt the result of some compiler magic going on behind the
scenes, but here is my question:

Shouldn't the declaration of the member function as volatile void
prevent such a warning message from occurring?

Volatile is supposed to be used when the function might never return,
so why doesn't the compiler turn off the warning message in this case?


Newsgroups: gnu.g++.bug
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: mailer/gateway problem
Reply-To: tmb@idiap.ch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 3 Jan 1993 13:00:40 GMT

I sent the letter reproduced below to "bug-g++@ai.mit.edu". First, it
got gatewayed to "gnu.g++.help" and "comp.lang.c++".  That is not what
I wanted. It definitely shouldn't have ended up in either of these
newsgroups. I also don't think it is a good idea to gateway _any_ g++
related traffic to "comp.lang.c++".

Please check your mail aliases, and please forward the message to
the appropriate mailing list.

				Thanks,
					Thomas.


To: bug-g++@ai.mit.edu
Subject: gcc (C++) 2.3.2 generates bad assembly language output (redefined symbol)


gcc -v -c foo.cc
Reading specs from /sym/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
gcc version 2.3.2
 /sym/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.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 foo.cc /local/tmp/cca11717.i
GNU CPP version 2.3.2 (sparc)
 /sym/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/cc1plus /local/tmp/cca11717.i -quiet -dumpbase foo.cc -version -o /local/tmp/cca11717.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
 as -o foo.o /local/tmp/cca11717.s
as: "/local/tmp/cca11717.s", line 96: error: redefinition of symbol "_lookup"
gcc: foo.o: No such file or directory

== foo.cc ======================================================
#include <std.h>

template <class Y>
struct NameValuePair {
	char *name;
	Y y;
};

template <class Y>
inline Y lookup(NameValuePair<Y> *data,char *name) {
	while(data->name) {
		if(!strcmp(data->name,name)) return data->y;
		data++;
	}
	abort();
	return data->y;		// to keep GCC happy
}

template <class T>
void swap(T &x,T &y) {
	T temp = x;
	x = y;
	y = temp;
}

typedef char (*canonicalizer)(char &,float *);

NameValuePair<canonicalizer> canonicalizers[] = {
	{0,0}
};

typedef float (*extractor)(float &image,float g=2.0);

NameValuePair<extractor> extractors[] = {
	{0,0}
};

void foo() {
	canonicalizer canonicalize = lookup(canonicalizers,(char*)"foo");
	extractor extract = lookup(extractors,(char*)"bar");
}

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



Newsgroups: gnu.g++.bug