HDTenEightyP/NetNews huggingface dataset:
From: Mark.Bush@prg.ox.ac.UK (Mark Bush)
Subject: Re: bash 1.12 on Sun has different behavior for bkgrnd jobs and signals
Organization: Oxford University Computing Laboratory
Distribution: gnu
Date: Mon, 28 Sep 1992 15:18:17 GMT

In article <9209241935.AA24685.SM@odin.INS.CWRU.Edu> chet@po.cwru.edu writes:
#Now, after I've said all that, I think bash is being a little too zealous
#in its SIGHUP sending.  I will change the code to send SIGHUP to all
#jobs on receipt of SIGHUP only if the shell is interactive and a login
#shell, and lobby for its inclusion in the next release.

With some form of flag (shell variable) to say `I want the full SIGHUP
everything behaviour'?  Otherwise, functionality is lost.

The fact that SIGHUPs can end up killing processes that a user didn't want
to has a workaround (nohup).  By altering the behaviour of bash in the way
you mention, this workaround becomes unnecessary, but what about a
workaround the `other way'?

Please don't remove functionality just to make the default behaviour more
intuitive.

Mark

  Supporter of:
      SIGHUP being transferred to all sub-processes (even if you have
          to set a variable to do so);
      .bashrc being sourced and aliases working for non-interactive
          shells.

Newsgroups: gnu.bash.bug
From: de5@ornl.gov (Dave Sill)
Subject: New release (was Re: Exiting from .bash_profile with ctrl-c)
Organization: Oak Ridge National Lab, Oak Ridge, TN
Distribution: gnu
Date: Mon, 28 Sep 1992 14:22:51 GMT

In article <9209231535.AA28506.SM@odin.INS.CWRU.Edu>, chet@odin.ins.cwru.edu (Chet Ramey) writes:
>
>If this does not work in 1.12, never fear -- it has been fixed for 1.13.

I fear I won't live to see 1.13.  :-)

Not trying to look a gift horse in the mouth--I'd just like to see more
frequent, more predictable upgrades.  Or at least stop talking about how great
1.13 is until it's released.

-- 
Dave Sill (de5@ornl.gov)           For every Bill Joy there is a Kirk McKusick.
Martin Marietta Energy Systems     For every Bill Gates there is a Richard
Workstation Support                Stallman.                     --Paul Graham

Newsgroups: gnu.bash.bug
From: Ivan.Herman@cwi.NL (Ivan Herman)
Subject: Filename Completion
Organization: CWI, Amsterdam, The Netherlands
Distribution: gnu
Date: Mon, 28 Sep 1992 16:00:43 GMT

I am not absolutely sure whether this is a missing feature or a bug.
What I would like to have is as follows. When I use Bash for filename
completions (e.g. by using TAB) and there are more than one possibilities,
Bash makes a listing of all possible completions. What I would like to
have at that moment is to have an indication for the type of the files
listed on the screen, much like "ls" does with the flag "F". I.e.,
names for directories could be followed by a "/", symbolic links by
a "@", executables by a "*" etc.  Again, I do not know whether this
is a missing feature or it does not run properly on my environment. I
use bash version 1.12.1 on an SGI Indigo, running IRIS.

Can anyone give me a hint whether a) this feature is present but I 
overlooked something b) this feature will be present at a later stage or
c) what is the optimal way of modifying the code to achieve this?
Thanks.
Newsgroups: gnu.bash.bug
Subject: Filename Completion
Summary: 
Followup-To: 
Distribution: gnu
Organization: CWI, Amsterdam
Keywords: 


I am not absolutely sure whether this is a missing feature or a bug.
What I would like to have is as follows. When I use Bash for filename
completions (e.g. by using TAB) and there are more than one possibilities,
Bash makes a listing of all possible completions. What I would like to
have at that moment is to have an indication for the type of the files
listed on the screen, much like "ls" does with the flag "F". I.e.,
names for directories could be followed by a "/", symbolic links by
a "@", executables by a "*" etc.  Again, I do not know whether this
is a missing feature or it does not run properly on my environment. I
use bash version 1.12.1 on an SGI Indigo, running IRIS.

Can anyone give me a hint whether a) this feature is present but I 
overlooked something b) this feature will be present at a later stage or
c) what is the optimal way of modifying the code to achieve this?
Thanks.
--
Ivan Herman
             Centre for Mathematics & Computer Sciences (CWI),
             Kruislaan 413, 1098 SJ Amsterdam, The Netherlands.
             Email:ivan@cwi.nl, Tel: +31-20-592.4163

Newsgroups: gnu.bash.bug
From: greg@duke.cs.unlv.edu (Greg Wohletz)
Subject: Reactive keyboard
Reply-To: greg@duke.cs.unlv.edu (Greg Wohletz)
Organization: UNLV Computer Science and Electrical Engineering
Distribution: gnu
Date: Wed, 30 Sep 1992 15:19:29 GMT

Has there been any thought of adding the functionality of the rk  (the
reactive keyboard) to bash?   I'm being tempted back into using csh as
a result of this wonderfull little program...

					--Greg

Newsgroups: gnu.g++.bug
From: hacrat@catfish.lcs.mit.edu (Nate Osgood)
Subject: G++ gives signal 11 in template processing
Organization: MIT Laboratory for Computer Science
Distribution: gnu
Date: Mon, 28 Sep 1992 23:47:02 GMT

Hi.  I'm using g++ 2.2.2 on a Sun4 under SunOS 4.1.2

This is a report of an easy to exhibit but somewhat puzzling bug.  The
followng program causes g++ to crash as follows:

Reading specs from /usr/uns/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /usr/uns/lib/gcc-lib/sun4/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 /usr/tmp/foo.c /usr/tmp/cca26631.i
GNU CPP version 2.2.2 (sparc)
 /usr/uns/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca26631.i -quiet -dumpbase foo.cc -version -o /usr/tmp/cca26631.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/usr/tmp/foo.c: In method `int  StackBase<unsigned int>::Depth ()':
/usr/tmp/foo.c:13: warning: control reaches end of non-void function
/usr/site/gcc2: Internal compiler error: program cc1plus got fatal signal 11


The crash apparently occurs as a result of a template in the code.  It
is hard to say exactly what SINGLE THING causes the bug -- my guess is
that the ultimate cause is a discrepency between the stated return
type for a method in the prototype, and the ACTUAL return type
specified in the function template.  (i.e. rather than warning of a
mismatch in return types, g++ crashes, apparently via segmentation
fault).   on the other hand, tweaking this code in other ways can also
make the problem vanish (e.g. by removing the "depth" method below).
in any case, it's a small amount of code and a dramatic result:

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

template<class Contents> class StackBase 
{
 public:
  Contents    Pop();
  int    Depth();

};

/*  Note that the Pop function should return "Contents" but does not
	below */


template<class Contents>     StackBase<Contents>::Pop()
{
}

/* for some reason, this additioanl function must be present to exhibit
	the error	*/
template<class Contents> int    StackBase<Contents>::Depth()
{
}


/*  Now we USE the template (cause it to be instantiated) */

typedef  StackBase<unsigned int> SBB;

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




Thanks!

Nate Osgood
-- 
-------------------------------------------------------------------------------
Nate Osgood			| ARPA: hacrat@catfish.lcs.mit.edu
CS Graduate Student		| 
MIT LCS Room NE43-636		| UUCP: ...!uunet!catfish.lcs.mit.edu!hacrat

Newsgroups: gnu.g++.bug
From: dak@pool.INformatik.rwth-aachen.DE (David Kastrup)
Subject: -fansi-exceptions hangs g++-2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 3 Oct 1992 14:53:09 GMT

The simple inclusion of stream.h from libg++2.2 causes cc1plus to grow
by incredible amounts, then abort with signal 11, if you specify
-fansi-exceptions.

Newsgroups: gnu.g++.bug
From: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Subject: RTFM. Was: g++ 2.2.2 - prob in temp obj. as function argument
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Distribution: gnu
Date: Fri, 2 Oct 1992 17:12:35 GMT

In ARM it is clearly specified, that the only things you are allowed to
do with a temporary is
1) use the whole fu... thing. The moment you select a component, poof,
the rest may vanish. You could assign to a variable, i.e.
2) bind a reference to it. This is the most feasable thing. Then the
temporary is guaranteed to exist till the end of the block.

However, I would consider a warning by the compiler appropriate, where
the compiler can because of the function definition swee that such a
thing might happen.

And I would absolutely be against trying to introduce a longer life
for temporaries, because then even more difficult situations are
probable to foul up. Read ARM for your enlightenment.

Newsgroups: gnu.g++.bug
From: pfbertra@watcgl.uwaterloo.ca (Philippe F. Bertrand)
Subject: g++ 2.2.2 template syntax error
Organization: Computer Graphics Lab [CGL], University of Waterloo
Distribution: gnu
Date: Thu, 1 Oct 1992 18:42:17 GMT

In my opinion, the base class initialization is correct in version 3
but not in version 2 yet version 1 fails to compile.

VERSION 1
=========

template < int b >
class C {
     int B;
   public:
   C( int cc );
};

template < int b > C<b>::C( int cc ) {
  B = b * cc;
  printf( "%d\n", B );
}

class Foo : public C<7> {

    public:
	int X;

	Foo( int xx );
};

Foo::Foo( int xx )
 : C( 2 )
{
  X = xx;
}

void test( ) {

  Foo bar(123);

}

----------------------
junk.c: In method `Foo::Foo (int)':
junk.c:23: class `Foo' does not have any field named `C'
junk.c:24: too few arguments for constructor `C'
junk.c:24: in base initialization for class `Foo'
junk.c: In method `C<7>::C (int)':
junk.c:11: warning: implicit declaration of function `printf'


VERSION 2
=========

template < int b >
class C {
     int B;
   public:
   C( int cc );
};

template < int b > C<b>::C( int cc ) {
  B = b * cc;
  printf( "%d\n", B );
}

class Foo : public C<7> {

    public:
	int X;

	Foo( int xx );
};

Foo::Foo( int xx )
 : C<7>( 2 )
{
  X = xx;
}

void test( ) {

  Foo bar(123);

}

--------------------------
junk.c: In method `C<7>::C (int)':
junk.c:11: warning: implicit declaration of function `printf'

- Philippe F. Bertrand                          pfbertrand@watcgl.uwaterloo.ca 
Computer Graphics Lab, Department of Computer Science,
University of Waterloo, Waterloo, Canada  N2L 3G1

Newsgroups: gnu.g++.bug
From: fjh@munta.cs.mu.oz.au (Fergus James HENDERSON)
Subject: Re: Gnu C bug in '...' wild arg specification
Organization: Computer Science, University of Melbourne, Australia
Distribution: gnu
Date: Fri, 2 Oct 1992 11:17:12 GMT

In gnu.g++.bug, I wrote:

>You cannot pass objects with constructors or operator= through '...'
>(I can't find a reference to this in C++PL 2nd Ed. right now, but Cfront 2.0
>also rejects your program.)
>This is a restriction in the language, not a problem with g++.

Apparently I was wrong.
Despite the fact that Turbo C++, g++, and Cfront 2.0 all get it wrong, there
is apparently no such restriction, and Cfront 3.0 gets it right, so I am told.

That'll teach me to rely on the compilers rather than on the language
definition! ;-)

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

Newsgroups: gnu.g++.bug
From: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Apparent g++ problem
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Distribution: gnu
Date: Fri, 2 Oct 1992 17:23:35 GMT

jj00@etherm.co.UK (John Juer) writes:

>gcc version 2.2.2, on Interactive version 3.0

>It seems that when compiling without the optimiser and with debug on
>in-line functions do not get in-lined, resulting in undefined symbols
>on the final link.

>(jay)$ g++ -c -O -I../include -Di386ix prctxt.C
>(jay)$ nm prctxt.o | fgrep _12symbol_stacki
>the final link worked fine

>(jay)$ g++ -c -g -I../include -Di386ix prctxt.C
>(jay)$ nm prctxt.o | fgrep _12symbol_stacki
>__12symbol_stacki   |       0|extern|                  |      |     |

>__12symbol_stacki was undefined on the final link.

>This was an in-line function, here is an extract from the header file.

>#pragma interface
And some.

Do include the complete files in a bug report. More likely than not,
you have not included an instance of your header file once with
#pragma implementation
Since #pragma interface has the sole purpose of avoiding to generate
inline and member function instances, that is likely to be the bug.
If you use -O, inline functions are generated inline, and thus the
missing backup version does no harm, except when you want to use it in
a debugger expression.

Newsgroups: gnu.g++.bug
From: solomon@cs.wisc.edu (Marvin Solomon)
Subject: bogus warning (g++ 2.2.2)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 11:40:39 GMT

struct S {};
struct S1 {
	operator S*();
};

struct T {
	S1 p;
};

struct T1 {
	T* operator ->();
};


void f(int i) {
	S *s;
	T1 t1;
	S1 s1;
	s = i ? s1 : s1; // no warning here
	s1 = i ? t1->p : t1->p; // or here
	s = i ? t1->p : t1->p; // warning here (line 21)
}
bug1.c:21: warning: ANSI C forbids use of conditional expressions as lvalues

Newsgroups: gnu.g++.bug
From: djd@uk.ac.reading.CS.CSg (David J Dawkins)
Subject: g++2.2.2 - const template member functions
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 11:23:29 GMT

Problem with 'const' member function templates

> template<class T>
> struct A {
> 	void	foo() const;
> };
> 
> template<class T>
> void
> A<T>::foo() const
> {}
> 
> 
> main()
> {
> 	A<int>	a;
> 
> 	a.foo();
> }


The AT&T 3.0 compiler copes with this fine.

The G++ 2.2.2 compiler gives the following error:

	t.c:4: template for method `foo' doesn't match any in class `A<int>'

Without the 'const' specifier, member function specifier, both compilers cope with it fine.

 -- Compilation details -------------------------------

valhalla% g++ -v t.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 t.c /usr/tmp/cca03267.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca03267.i -quiet -dumpbase t.cc -version -o /usr/tmp/cca03267.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
t.c: In function `int  main ()':
t.c:4: template for method `foo' doesn't match any in class `A<int>'

valhalla% uname -a
SunOS valhalla 4.1.1 1 sun4c

-dave
-- 
djd@csg.cs.rdg.ac.uk
djd@csug.cs.rdg.ac.uk
davidd@integ.uucp

Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC-2.2.2, build_method_call: incorrect calculation of type info?
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Sun, 27 Sep 1992 04:46:38 GMT

In cp-call.c, build_method_call, there is the following code for
computing the type of a class instance:

    {
      /* The MAIN_VARIANT of the type that `instance_ptr' winds up being.  */
      tree inst_ptr_basetype;

      ...

	      /* @@ Should we call comp_target_types here?  */
	      inst_ptr_basetype = TREE_TYPE (TREE_TYPE (instance_ptr));
	      if (TYPE_MAIN_VARIANT (basetype) == TYPE_MAIN_VARIANT (inst_ptr_basetype))
		basetype = inst_ptr_basetype;
	      else
		{
		  instance_ptr = convert (TYPE_POINTER_TO (basetype), instance_ptr);
		  if (instance_ptr == error_mark_node)
		    return error_mark_node;
		}
	    }
	  else
	    inst_ptr_basetype = TREE_TYPE (TREE_TYPE (instance_ptr));
	}

      if (basetype_path == NULL_TREE)
	basetype_path = TYPE_BINFO (inst_ptr_basetype);

Since `inst_ptr_basetype' is supposed to be the basetype of
`instance_ptr' (according to the comment above), shouldn't it be
recomputed after `instance_ptr' is converted to
`TYPE_POINTER_TO (basetype)'?  I.e., to have

		  inst_ptr_basetype = TREE_TYPE (TREE_TYPE (instance_ptr));

after the call to `convert'?

--Gerald

Newsgroups: gnu.g++.bug
From: jody@shell.COM (Jody Winston)
Subject: cc1plus seg fault
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 20:26:38 GMT

I have a valid C++ program, well at least CFRONT 2.1 thinks it's
valid, that causes cc1plus in version 2.2.2 and the snapshot dated
920925 to seg fault (Sun OS 4.1.1).  The problem is virtuals is equal
to NULL in get_vtable_entry.  Here's the traceback for the 920925
snapshot from gdb 4.6:

GNU C++ version gcc-2.2.2-920925 (sparc) compiled by GNU C version gcc-2.2.2-920925.
Program received signal 11, Segmentation fault
0x5aaf0 in get_vtable_entry (virtuals=0x0, base_fndecl=0x490210)
    at cp-class.c:637
637         }
(gdb) 
(gdb) where
#0  0x5aaf0 in get_vtable_entry (virtuals=0x0, base_fndecl=0x490210)
    at cp-class.c:637
#1  0x5afbc in modify_vtable_entries (t=0x285f80, fndecl=0x6caf88, 
    base_fndecl=0x490210, pfn=0x6cb640) at cp-class.c:891
#2  0x5ec10 in finish_struct (t=0x285f80, list_of_fieldlists=0x285f80, 
    empty=1545216, warn_anon=0) at cp-class.c:2968
#3  0x10220 in yyparse () at cp-parse.y:2041
#4  0x7f4e8 in compile_file (name=0xf7fff686 "SpnObidManager.i")
    at toplev.c:1774
#5  0x82090 in main (argc=9, argv=0xf7fff56c, envp=0xf7fff594) at toplev.c:3256
(gdb) 

Jody Winston		jody@shell.com
..!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody
Consultant to:
Shell Development Company, Bellaire Research Center
P.O. Box 481, Room 4205, Houston, TX 77001	(Voice: 713 245-7574)


Newsgroups: gnu.g++.bug
From: ats@lems.brown.edu (Aaron T. Smith)
Subject: et2.2 and g++
Keywords: et2.2
Organization: Laboratory for Engineering Man/Machine Systems
Distribution: gnu
Date: Tue, 6 Oct 1992 13:58:28 GMT

Has anyone been able to compile et2.2 using gcc-2.2.2?  

-- 
----------------------------------------------------------------------------
Aaron Smith - ats@lems.brown.edu
			
Brown University	... I had to let go of that cow in order to see   
Providence, RI 02912	my other options ... It is not the thing that you 
			fling, but the fling that is everything ...          
			                                                  
----------------------------------------------------------------------------

Newsgroups: gnu.g++.bug
From: skdutta@ucs.ATt.COM (Saumen Dutta)
Subject: g++ bug or feature?!
Organization: AT&T Universal Card Services, Jacksonville FL
Distribution: gnu
Date: Mon, 5 Oct 1992 23:36:14 GMT

I have following problems with gcc.

While compiling the following program ( actually part of a big program
but shortened for convinience) it does'nt complain anything but while executing
it gives a BUS error. However if I interchange the position of xdisp and coord
in the definition of xwin, (i.e. class xwin: virtual public coord, virtual
public xdisp{.... ) it works fine!. Can somebody tell me what is going on.
I could not find anything from the gdb. I am using gcc2.2.2. I understand
that I didn't have to use virtual classes, but I guess it is syntactically okay!
Any feedback will be appreciated!!

 
class coord{
 public:
    double ctm[6]; 
    coord();
};

//--------------------------------------------------------

class xdisp{
  
public:
  xdisp();
};

//------------------------------------------------------------

class xwin: virtual public xdisp, virtual public coord{

public:
  xwin();

};

//----------------------------------------------------------



main()
{
        xwin tryme;
}


xwin::xwin():xdisp(), coord()
{

}


xdisp::xdisp()
{
}


coord::coord(){
        ctm[0] = (double)1.0;
        ctm[1] = ctm[2] = (double)0.0;
        ctm[4] = (double)1.0;
        ctm[5] = (double)0.0;
} 



If you decide to post the reply please send a e-mail too.

Newsgroups: gnu.g++.bug
From: pfbertra@watcgl.uwaterloo.ca (Philippe F. Bertrand)
Subject: g++ 2.2.2 template bug?
Organization: Computer Graphics Lab [CGL], University of Waterloo
Distribution: gnu
Date: Thu, 1 Oct 1992 18:36:18 GMT

Please reply directly as I normally do not read this group.  Thanks.

g++ junk.c -c junk.b
version 2.2.2

PROBLEM 1
=========

template < char * b >
class C {
     char * B;
   public:
   C( );
};

template < char * b > C<b>::C( ) {
  B = b;
  printf( "%s\n", b );
}

void test( ) {

  C<"wewe"> bar;

}

----------
junk.c: In function `void  test ()':
junk.c:16: invalid pointer constant for template parameter
 <pointer_type 1005eeb0
    type <integer_type 1005ae68 char permanent QI
        size <integer_cst 1005aee8 constant permanent 8
        align 8 symtab 0 precision 8
        min <integer_cst 1005aeb8 constant permanent -128
        max <integer_cst 1005aed0 constant permanent 127
        pointer_to_this <pointer_type 1005eeb0>
    unsigned permanent SI
    size <integer_cst 1005ae00 type <integer_type 1005ad80 int> constant permanent 32
    align 16 symtab 0
 <addr_expr 10073c48
    type <pointer_type 1004e3b8
        type <array_type 1004e338 type <integer_type 1005ae68 char>
            BLK
            size <integer_cst 1004e3a0 constant 40
            align 8 symtab 0 domain <integer_type 1004e2e8>
            pointer_to_this <pointer_type 1004e3b8>
        unsigned SI
        size <integer_cst 1005ae00 constant permanent 32
        align 16 symtab 0
    constant permanent
    arg 0 <string_cst 10073c60 type <array_type 1004e338>
        constant permanent static "wewe"
junk.c: At top level:
junk.c:6: please fix above error, and try recompiling.


PROBLEM 2 - attempt to bipass/correct passing of ptr to string
=========

template < char * b >
class C {
     char * B;
   public:
   C( );
};

template < char * b > C<b>::C( ) {
  B = b;
  printf( "%s\n", b );
}

void test( ) {

  const char *foobar = "FooBar";
  C<foobar> bar;

}

---------------------------
junk.c: In function `void  test ()':
junk.c:17: warning: initialization of non-`const *' pointer from `const *'
junk.c:17: invalid pointer constant for template parameter
junk.c:17: please fix above error, and try recompiling.

removing the 'const' still results with the 'invalid pointer' error

- Philippe F. Bertrand                          pfbertrand@watcgl.uwaterloo.ca 
Computer Graphics Lab, Department of Computer Science,
University of Waterloo, Waterloo, Canada  N2L 3G1

Newsgroups: gnu.g++.bug
From: 70441.465@compuserve.COM (Jaime Pereira)
Subject: g++ bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 23:09:35 GMT

//
// The following program produces a compiler internal error when compiled
// with gcc 2.2.2:
//
// 	argus% gcc -v
// 	Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
// 	gcc version 2.2.2
//
// 	argus% gcc -c bug5.C
//	bug5.cc: In function `int  main ()':
//	bug5.cc:42: internal compiler error 89, please report
//
// The compiler was compiled and installed under SunOS 4.1.1 without
// any special flags. 
//
// The same problem also appears when compiled with gcc under 
// Interactive Unix SVR3.2.
// 	  
// The problem seems to be related to naming a member function the
// same as a union AND using the member function.
// 
	     

union wait
	{
	int a;
	double b;
	};


class C1
	{
public:
	int	wait()	{ return 1; };
	};



int main()
	{
	C1 x;
	x.wait();
	}

//
// Regards,
//
// Jaime Pereira
// 70441.465@compuserve.com
//



Newsgroups: gnu.g++.bug