HDTenEightyP/NetNews huggingface dataset:
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU C's -mshort, and documentation
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 10 Jan 1993 14:29:26 GMT

Hi, James.  Copy to bug-gcc, because this report is not completely
specific to 386's.

   The documentation is wrong: there is no such [-mshort] option.

There probably had been one in the past.  I hardly believe that
someone distributed a product, having `gcc -mshort' in the Makefile,
without ever trying it...

   I don't see any easy way to make such a thing work.  It's easy to
   set ints to be 16 bits within gcc, but I doubt it would work.

The matter is not important to me.  Would the description of -mshort
be removed from GNU C documentation, I would consider that the bug
disappeared :-).

Here is the original message, for reference.

---------------------------------------------------------------------->
I'm using GNU C 1.41 under COFF encapsulation on this 386/ix 2.0.2
system.  The GNU C documentation says:

    `-mshort'
          Consider type `int' to be 16 bits wide, like `short int'.

But experience says otherwise:

   gcc -ansi -Di386 -O -DSYSV=1 -mshort -c arc.c
   gcc-cc1: Invalid option `short'

By the way, gcc.info does not confirm which version of GNU C it
pertains to.  The GNU standards dictate:

      The title page of the manual should state the version of the
   program which the manual applies to.  The Top node of the manual
   should also contain this information.
----------------------------------------------------------------------<

-- 
Franc,ois Pinard       ``Happy GNU Year!''      pinard@iro.umontreal.ca
(514) 588-4656                                   ...!uunet!iros1!pinard
About the League for Programming Freedom?  Email me or lpf@uunet.uu.net

Newsgroups: gnu.gcc.bug
From: dic5340@hertz.njit.edu (David Charlap)
Subject: Re: Bug in gcc's rand() function.
Organization: New Jersey Institute of Technology, Newark, N.J.
Distribution: gnu
Date: Tue, 5 Jan 1993 21:42:31 GMT

In article <1993Jan4.210729.28287@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
>When the stdlib.h rand() function is called, the sequence is
>repeatable, mod 8.
>
>For example, the following code:
>
	[deleted]
>
>always produces the following repeating sequence:
>
>	6   7   4   5   2   3   0   1
>
>I have tested it on the OS/2 2.0 port of gcc and the Dec-Ultrix
>version, and I get the same result in both cases.

Thanks to all those who responded - you can stop the e-mail now!

To summarize, the problem isn't in gcc, but in the C library.  Since I
work primarilly with OS/2, I am used to the non-Unix convention of
shipping the library with the compiler, so I assumed both to be the
same.  The OS/2 port of gcc includes a port of the library, and I
mistakenly thought that this was a part of the gcc distribution.

Fortunately, in addition to porting the rand() bug, the author also
ported the random() function which avoids the bug.  So there's to
further problem.

Thanks to everyone who responded for helping me figure this out.
-- 
  |)  David Charlap          | .signature confiscated by FBI due to
 /|_  dic5340@hertz.njit.edu | an ongoing investigation into the
((|,)                        | source of these .signature virusses
 ~|~

Newsgroups: gnu.gcc.bug
From: gml4410@ggr.co.UK (Lack Mr G M)
Subject: gcc-2.3.3 - bug on SUN for (char *) within a struct
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 14:47:43 GMT

     I wish to report a bug in gcc-2.3.3 on a SUN.
     
     I  have  built  gcc-2.3.3 on a Sun Sparcstation at SunOS4.1.1.  The
configure option was "sparc-sun-sunos4.1" and I  used  CFLAGS=-O  during
the makeing, which completed with no errors.

     The  following  simple  program dies with a segmentation fault.  It
runs correctly with gcc-2.3.3 on an SG Indigo, with Suns own cc compiler
(and with other c compilers on other platforms). 

     It  appears  that the address of the "string-within-a-structure" is
not calculated correctly.  I append the source and the assembler listing
produced by gcc -S. 


====================  Begin test source ====================
#include <stdio.h>
#include <string.h>

struct button {
         char *str ;
         int  opdisp ;
} ;

struct button buttons[2] = {
     { "ab00", 0, },
     { "ab01", 1, },
};
     
void main()
{
 
   printf("Strings are %s and %s\n", buttons[0].str, buttons[1].str);
   strcpy(buttons[0].str, "zz00");
   strcpy(buttons[1].str, "zz01");
   printf("Strings become %s and %s\n", buttons[0].str, buttons[1].str);
   return;
}
==================== End test source ====================

==================== Begin assembler listing ====================
gcc2_compiled.:
	.global _buttons
.text
	.align 8
LC0:
	.ascii "ab00\0"
	.align 8
LC1:
	.ascii "ab01\0"
.data
	.align 4
_buttons:
	.word	LC0
	.word	0
	.word	LC1
	.word	1
.text
	.align 8
LC2:
	.ascii "Strings are %s and %s\12\0"
	.align 8
LC3:
	.ascii "zz00\0"
	.align 8
LC4:
	.ascii "zz01\0"
	.align 8
LC5:
	.ascii "Strings become %s and %s\12\0"
	.align 4
	.global _main
	.proc	020
_main:
	!#PROLOGUE# 0
	save %sp,-136,%sp
	!#PROLOGUE# 1
	call ___main,0
	nop
	sethi %hi(_buttons),%o1
	sethi %hi(_buttons+8),%o2
	sethi %hi(LC2),%o3
	or %o3,%lo(LC2),%o0
	ld [%o1+%lo(_buttons)],%o1
	ld [%o2+%lo(_buttons+8)],%o2
	call _printf,0
	nop
	sethi %hi(_buttons),%o1
	ld [%o1+%lo(_buttons)],%o0
	sethi %hi(LC3),%o2
	or %o2,%lo(LC3),%o1
	call _strcpy,0
	nop
	sethi %hi(_buttons+8),%o1
	ld [%o1+%lo(_buttons+8)],%o0
	sethi %hi(LC4),%o2
	or %o2,%lo(LC4),%o1
	call _strcpy,0
	nop
	sethi %hi(_buttons),%o1
	sethi %hi(_buttons+8),%o2
	sethi %hi(LC5),%o3
	or %o3,%lo(LC5),%o0
	ld [%o1+%lo(_buttons)],%o1
	ld [%o2+%lo(_buttons+8)],%o2
	call _printf,0
	nop
	b L1
	nop
L1:
	ret
	restore
==================== End assembler listing ====================




-------------------------- Gordon Lack ----------------------------------
The contents of this message *may* reflect my personal opinion.  They are
*not* intended to reflect those of my employer, or anyone else.

Newsgroups: gnu.gcc.bug
From: shap@halifax.syncomas.com
Subject: Bug in xm-svr4.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 07:05:00 GMT

svr4.h should probably include the line

	#define sys_siglist _sys_siglist

Without this, the build of gcc fails in the cross-build case.


Jonathan S. Shapiro

Newsgroups: gnu.gcc.bug
From: tap@src.honeywell.com (Thomas A Peterson)
Subject: code with mixed pointer types fails to compile
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 17:18:41 GMT

Program: gcc
Version: 2.3.3
Machine: SPARCstation IPX
OS: SunOS4.1.1
Description:

  The following code fails to compile.

aristotle: cat GNU_FAIL.c
main()
{
  int a;
  char *dest;
  unsigned char *d;

  a = dest - d;
}
aristotle: /src/packages/gnu/gcc/gcc-2.3.3/xgcc -B/src/packages/gnu/gcc/gcc-2.3.3/ -c GNU_FAIL.c
GNU_FAIL.c: In function `main':
GNU_FAIL.c:7: invalid operands to binary -
aristotle: 

Newsgroups: gnu.gcc.bug
From: petcher@ebenezer.wustl.edu (Donald N. Petcher)
Subject: Thanks for help on RS6000 assembler bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 18:14:22 GMT

I thank (many of) you for your prompt help in setting me straight on the
RS6000 assembler bug, that I can't even compile with the -g flag on. I now
have gcc/g++ happily running on the 6000, (albeit without debugging
capabilities) and will petition our systems person to get the assembler
upgrade.

Cheers,
Don Petcher                                petcher@wuphys.wustl.edu
Physics Department
Washington University
Saint Louis, MO 63130

Newsgroups: gnu.gcc.bug
From: tiller@solace.me.uiuc.edu (Mike Tiller)
Subject: Possible Bug gcc-2.3.3 [Additional]
Organization: University of Illinois at Urbana
Distribution: gnu
Date: Sat, 9 Jan 1993 00:09:43 GMT

Ok, I'm moron for not including this my post 2 seconds ago.  I
meant to include (honestly).

If I change

int done = 0;

to 

int volatile done = 0;

everything works.  Is this mandatory for this case (in other
words do I have to tell the compiler done is volatile?)

Thanks

Michael Tiller



Newsgroups: gnu.gcc.bug
From: Joseph.FRancis@ircam.FR (Joseph Francis)
Subject: semiserious Bug in gcc-2.X for i860 target
Organization: IRCAM, Paris (France)
Distribution: gnu
Date: Fri, 8 Jan 1993 18:23:14 GMT

The following code:

:::

#define MAXARG 15
void nullfn();

static char *a = "test";
static double b[MAXARG];

foo()
{
  nullfn( b[0]);
}

:::
compiles to
:::
	.file	"m_mess.c"
gcc2_compiled.:
.text
.LC0:
	.ascii "test\0"
.data
	.align 4
_a:
	.long .LC0
.text
	.align 8
	.align 4
	.long	.ep._foo-_foo+0xc8000000
.globl _foo
_foo:
	addu -16,sp,sp
	st.l fp,0(sp)
	addu 0,sp,fp
	st.l r15,8(fp)
	st.l r1,4(fp)
.ep._foo:
	shl r0,r28,r15
	shl r0,sp,r30
	orh ha%_b,r0,r31
	fld.d l%_b(r31),f8
	call _nullfn
	nop
.L1:
	ld.l 8(fp),r15
	adds 16,fp,r31
	ld.l 4(fp),r1
	ld.l 0(fp),fp
	bri r1
	mov r31,sp
.data
	.align 4
_b:
	.set .,.+128

;;;

this will produce the following error by gas-1.38 when compiled:

test.c:unknown: 16-bit immediate 8-byte alignment error: 0x00000054

My configuration is:
host=m68k-next-bsd target=i860-unknown-sysv3 build=m68k-next-bsd
gcc-2.2.2, 2.3.1 (same problem, both systems, and probably for 2.3.3 also)

The problem is of course that the double needs to be 8-byte aligned,
and gcc isn't doing that. If anyone has seen this, can they notify
me of a fix before I delve into the compiler? It would be a great
help. Definitely a naughty bug, but can be gotten around.



-- 
| Le Jojo: Fresh 'n' Clean, speaking out to the way you want to live
| today; American - All American; doing, a bit so, and even more so.

Newsgroups: gnu.gcc.bug
From: petcher@ebenezer.wustl.edu (Donald N. Petcher)
Subject: Bug in gcc on RS6000 ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 20:03:51 GMT

When trying to 'make LANGUAGES=c' on an IBM RS6000 running AIX, I got the 
following output:

> make LANGUAGES=c
>         rm -f tmplibgcc2.a
>         set -e; \
> 
>          for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 \
>               _negdi2 _lshrdi3 _lshldi3 _ashldi3 _ashrdi3 _udiv_w_sdiv \
>               _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf \
>               _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi \
>               _fixsfdi __gc c_bcmp _varargs _eprintf _builtin_new \
>               _caps_New _builtin_del _bb _shtab _clear_cache _trampoline \
>               __main _exit _ctors; \
> 
>                 do \
>                   echo ${name}; \
>                   ./xgcc -B./ -O2  -DIN_GCC   -g  -g1 -I. -I. -I./config -c 
>                   -DL${name} ./libgcc2.c -o ${name}.o; \
>                   if [ $? -eq 0 ] ; then true; else exit 1; fi; \
>                   ar rc tmplibgcc2.a ${name}.o; \
>                   rm -f ${name}.o; \
>                 done
> _muldi3
> Assembler:
> /tmp/ccG20Crx.s: line 33: 1252-142 Syntax error.
> make: 1254-004 The error code from the last command is 1.
> 
> Make Quitting.

Is this related to the bug mentioned in in the AIX assembler that is
mentioned in the README.RS6000 file, or is it a bug in the compiler? Since
the README file only mentioned that the bug would occur when debugging code
compiled by gcc, I assumed that the compiler would compile itself whether I
have the patch or not (I don't know yet whether we do have the patch but I
suspect not). Please help. I would badly like to have gcc running on our
RS6000's. Thanks,

Cheers,                                         petcher@wuphys.wustl.edu
Don Petcher
Physics Department
Washington University
Saint Louis, MO 63130

Newsgroups: gnu.gcc.bug
From: apm@kikka.hut.fi (Antti Miettinen)
Subject: gcc-2.3.3, IRIX 4.0.1, <limits.h> vs <float.h>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 06:11:24 GMT

This is not exactly a bug report. This is just an observation of a
peculiar situation that might require fixing (propably not).

The IRIX-system header limits.h unconditionally defines for example
DBL_MAX. So does gcc's float.h but it undef's old definitions before
defining. If a program includes float.h before limits.h (like for
example Integer.cc in libg++-2.3 does) one gets a lot of warnings.
This may not be serious but the constants in system limits.h (and
system float.h) are also a bit different from the ones in gcc's
float.h.



Newsgroups: gnu.gcc.bug
From: alex.ZAtsman@analog.COM (Alex Zatsman)
Subject: Unending Warnings about '-Wid-clash-..'
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 21:03:55 GMT

Calling "gcc -Wid-clash-LEN <file name>" sends cc1 into infinite loop
in which it prints 

	cc1: error: Invalid option `-Wid-clash-LEN'

on each iteration. The bad code is in toplev.c (line 2848):

		  while (*endp)
		    {
		      if (*endp >= '0' && *endp <= '9')
			endp++;
		      else
			error ("Invalid option `%s'", argv[i]);
		    }

A less verbose code could look like this:

		  while (*endp)
		    {
		      if (*endp >= '0' && *endp <= '9')
			endp++;
		      else
			{	
			   error ("Invalid option `%s'", argv[i]);
			   break;
			}
		    }


Alex Zatsman
Analog Devices, Inc.

Newsgroups: gnu.gcc.bug
From: cjd@brb.dmt.csiro.au (Cameron Davidson)
Subject: apparent bug in GCC 2.2.2 with optimised 486 code.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 01:52:50 GMT

GCC 2.2.2 version for DOS (DJGPP ver 1.08, and, I am told, 1.09 also)
GAS 1.38
MS-DOS V5.0 (HIMEM.SYS, no EMM )

The sample program below appears to work as expected when not optimised,
or when optimised with -O, but fails when compiled with -O2.
Failure is either:
	1. segmentation fault during assignment of 1.0 when lact == 1, or
	2. the check of initialised data (in verify) reveals that only
matrix elements [0][0] and [1][0] to [1][2] have been set to 1.0,
the remainder still being 0.0.
You should be able to reproduce either form by adding 376 to PADDING
(that value is ( 2 * MAXDIM + 1 ) * sizeof double )

I realise the code loop is eccentric to say the least, but I think it comes
from larger code reduced to the simplest form.

The cause of the problem appears to be due to the fact that the stack
starts just below 0x80000000 and the matrix begins at around 7fffb600. When
-O2 is used, the pointer value stored in %edi to check for the end of
final row in the loop:

	for ( lm=...

will eventually exceed 0x80000000. Either than or edi will be close to
0x7fffff?? and ecx will be incremented from equal to edi to > 0x80000000.
The test for end of loop is:
	cmpl %edi,%ecx
	jle  L27
which I believe is a signed comparison.
By changing the generated assembler source to use JBE instead of JLE the
code then worked.



/*--------------------------  Example code  -----------------------------*/
/*  Compile with                                                   */
/*  gcc -O2 test.c -lm                                             */

#include <stdio.h>

#ifndef PADDING
#	define PADDING 1
#endif

#ifndef MAXDIM
#	define MAXDIM 23
#endif

typedef double matrix[2*MAXDIM+1][2*MAXDIM+1];

void    verify( matrix morg ),
	runtest( void );


void main (argc,argv)

int argc;
char **argv;

   {
   char stack_padding[ PADDING ];

   runtest();
   }

void runtest( void )
   {
   matrix morg;
   int lact, lm, ln;

   printf( "\n matrix starts at %x and is %d(%x) bytes long\n",
		&morg, sizeof morg, sizeof morg );

   for (lact=0; lact <= MAXDIM; ++lact)
	{
	printf("\rlact=%5d ",lact); fflush(stdout);

	for (lm=0; lm <= 2*lact; ++lm)
		for (ln=0; ln <= 2*lact; ++ln)
			morg[lm][ln] = 1.0;
       }
   verify( morg );
   }

void     verify( matrix morg )
   {
   int lm, ln, errcount = 0;

   printf( "\ntesting results!\n" );

	for (lm=0; lm <= 2*MAXDIM; ++lm)
	 {
         for (ln=0; ln <= 2*MAXDIM; ++ln)
	   {
           if ( morg[lm][ln] != 1.0)
		{
		printf( "\nmatrix[%3d][%3d] had %.3g ", lm, ln, morg[lm][ln] );
		if ( ++errcount > 10 )
			{
			printf( " I give up\n" );
			return;
			}
		}

	   }
	}
   }

/* --------------  end of example ---------------------------------------*/


Cameron Davidson,
CSIRO Division of Manufacturing Technology,   Telephone: +61 7 212 4535
Qld Centre for Advanced Technologies,         Facsimile: +61 7 212 4681
2643 Moggill Rd, Pinjarra Hills, Qld, 4069.   Internet:  cjd@brb.dmt.csiro.au

Newsgroups: gnu.gcc.bug
From: teutsch@sirius.ffm-iw.DEgussa.DE (Holger Teutsch)
Subject: gcc 2.3.3's combine.c and BYTE_LOADS_SIGN_EXTEND
Reply-To: teutsch@star.ffm-iw.degussa.de
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 17:50:26 GMT

Im currently working on a port of gcc 2.3.3 to Intergraph's clipper
processor. This processors uses BYTE_LOADS_SIGN_EXTEND.
Combine.c replaces 'subregs' by 'zero_extend' for BYTE_LOADS_ZERO_EXTEND.
I think 'parallel' code for BYTE_LOADS_SIGN_EXTEND must be added to combine.c.


#ifdef BYTE_LOADS_ZERO_EXTEND
      /* If we have (set FOO (subreg:M (mem:N BAR) 0)) with
	 M wider than N, this would require a paradoxical subreg.
	 Replace the subreg with a zero_extend to avoid the reload that
	 would otherwise be required. */
      if (GET_CODE (SET_SRC (x)) == SUBREG
	  && subreg_lowpart_p (SET_SRC (x))
	  && SUBREG_WORD (SET_SRC (x)) == 0
	  && (GET_MODE_SIZE (GET_MODE (SET_SRC (x)))
	      > GET_MODE_SIZE (GET_MODE (SUBREG_REG (SET_SRC (x)))))
	  && GET_CODE (SUBREG_REG (SET_SRC (x))) == MEM)
	SUBST (SET_SRC (x), gen_rtx_combine (ZERO_EXTEND,
					     GET_MODE (SET_SRC (x)),
					     XEXP (SET_SRC (x), 0)));
#endif

/*** added by me ***/
#ifdef BYTE_LOADS_SIGN_EXTEND
      /* If we have (set FOO (subreg:M (mem:N BAR) 0)) with
	 M wider than N, this would require a paradoxical subreg.
	 Replace the subreg with a sign_extend to avoid the reload that
	 would otherwise be required. */
      if (GET_CODE (SET_SRC (x)) == SUBREG
	  && subreg_lowpart_p (SET_SRC (x))
	  && SUBREG_WORD (SET_SRC (x)) == 0
	  && (GET_MODE_SIZE (GET_MODE (SET_SRC (x)))
	      > GET_MODE_SIZE (GET_MODE (SUBREG_REG (SET_SRC (x)))))
	  && GET_CODE (SUBREG_REG (SET_SRC (x))) == MEM)
	SUBST (SET_SRC (x), gen_rtx_combine (SIGN_EXTEND,
					     GET_MODE (SET_SRC (x)),
					     XEXP (SET_SRC (x), 0)));
#endif

- Holger

--------------------------------------------------------------------------------
Holger Teutsch, Degussa AG, Abt. IW-AC, Weissfrauenstr.9, D-6000 Frankfurt 11

Tel: +4969218-2316                E-Mail       : teutsch@ffm-iw.Degussa.DE
Fax:         -2616                VMS PSI-Mail : 4569002366::TEUTSCH

Newsgroups: gnu.gcc.bug
From: mitch@clsi.UUCP (Mitchell Perilstein)
Subject: Mismatched function storage class not reported--OK?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 17:07:43 GMT

If this file

  static int foo();

  int foo() 
  {
	return 1;
  }

is compiled -Wall -c, no warning is issued regarding mismatched storage
class between the declaration and the definition.  The function is taken
to be static, as shown by nm on the result (`t' indicates static symbol
in SunOS nm):

  00000000 t _foo
  00000000 t gcc2_compiled.

Taking foo as static is OK, since the first external declaration
specifies static.  The Standard describes how the types must all match
up, but what does it say about storage classes? Should a warning be
issued? 

This is gcc 2.1 on Sun4 SunOS 4.1.2.
---
 Mitchell N. Perilstein   CAD Language Systems, Inc.   410-992-5700 x225 
 Member, League for Programming Freedom.  Mail lpf@uunet.uu.net for info.

Newsgroups: gnu.gcc.bug
From: brendan@cygnus.com (Brendan Kehoe)
Subject: [jbg@qualcomm.com: Core dump now internal error]
Reply-To: brendan@cygnus.com (Brendan Kehoe)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 6 Jan 1993 03:12:46 GMT

I think this is a back-end problem.  `-O -g -funroll-loops' is what
triggers it.

------- Start of forwarded message -------
From: Jeff Gehlhaar <jbg@qualcomm.com>
Subject: Core dump now internal error
To: bug-g++@prep.ai.mit.edu
Date: Mon, 4 Jan 1993 09:19:11 -0700
X-Sender: jbg@wizard.qualcomm.com

// This program used to cause G++ to dump core.  It now causes an internal
// compiler error.

// All of this, both code and options, seem to be necessary to tickle
// the bug.  Don't ask _me_ why; I don't see how they are related....

// The result of ``g++ -v -c -O -g -funroll-loops bug006.cc'' is attached below.

// -- Greg

#include <iostream.h>
#define SHOW(x)    do { cout << x << endl; } while (0)

class List
{
public:
        List(void) { list = 0; }
        class List *list;
};

class Class
{
public:
        Class(char *param);
        List queue;
};

Class::Class(char *param)
{
        SHOW("Display some text");
}

/* Compiler output follows:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/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 -D__OPTIMIZE__ -g bug006.cc
/usr/tmp/cca29841.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus
/usr/tmp/cca29841.i -quiet -dumpbase bug006.cc -g -O -version
- -funroll-loops -o /usr/tmp/cca29841.s
GNU C++ version 2.3.3 (sparc) compiled by CC.
bug006.cc: In method `Class::Class (char *)':
bug006.cc:31: Internal compiler error.
bug006.cc:31: Please report this to `bug-g++@prep.ai.mit.edu'.
Compiler output above */


======================================================
Jeff Gehlhaar           Qualcomm Inc,  
jbg@qualcomm.com        San Diego, CA, USA
(619) 597-5241          "The Elegant Solution...."
======================================================


------- End of forwarded message -------

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Mountain View, CA                              +1 415 903 1400

Newsgroups: gnu.gcc.bug