HDTenEightyP/NetNews huggingface dataset:
From: irvin@betelgeuse.dartmouth.edu (Tim Irvin)
Subject: HP9000 series 340 problem (GCC 2.1)
Reply-To: irvin@northstar.dartmouth.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 13:32:33 GMT

I get the following error when compiling GCC 2.1 on an HP 9000 series 340
running HP/UX 7.0:

        cc -Wc,-Nw2000 -Wc,-Ns2000 -Wc,-Ne700 -Wc,-Np300 -c    -g     -I. -I. -I
./config ./genattrtab.c
"./genattrtab.c", line 399: operands of + have incompatible types
"./genattrtab.c", line 419: operands of + have incompatible types
"./genattrtab.c", line 439: operands of + have incompatible types
"./genattrtab.c", line 459: operands of + have incompatible types
*** Error code 1

Stop.


The lines in question are:

399: hashcode = (code + RTL_HASH (arg0));
419: hashcode = (code + RTL_HASH (arg0) + RTL_HASH (arg1));
439: hashcode = (code + RTL_HASH (arg0));
459: hashcode = (code + RTL_HASH (arg0) + RTL_HASH (arg1));

code is declared as:     enum rtx_code code;
RTL_HASH is defined as: #define RTL_HASH(RTL) ((int) (RTL) & 0777777)

Tim Irvin
Systems Administrator
Project NORTHSTAR
Dartmouth College


Newsgroups: gnu.gcc.bug
From: wood@dg-rtp.dg.com (Tom Wood)
Subject: Re: DG AViiON gcc problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 12:48:24 GMT

Dave Greenberg writes:
   
   dg> The output from the final lines starting with the trailing parts of the
   dg> make with the *********'s appended is as follows:

The output looks just fine.  The only problem is you used the wrong commands
to compare the stage 2 and stage 3 objects.  The INSTALL file says to do this:

        On systems that use COFF object files, or an object file
     format that is a superset of COFF (such as ECOFF or XCOFF), bytes
     5 to 8 will always be different, since it is a timestamp.  On
     these systems, you can do the comparison as follows (in Bourne
     shell):

          for file in *.o; do
          tail +10c $file > foo1
          tail +10c stage2/$file > foo2
          cmp foo1 foo2 || echo $file
          done
   
##################################################

   dg> in the process of the install i.e.:
   dg> make CC=stage2/gcc install
   dg>
   dg> the following lines appear:
   dg>
   dg> cp ./byteorder.h .
   dg> cp: ./byteorder.h and ./byteorder.h are identical
   dg> *** Error code 2 (ignored)
   dg>
   dg> which do not worry me much (should they?)
   
I believe this is part of the "install-headers" step.  GNU C is already
integrated into DG/UX, so there is no need for this step.  One way to
suppress this step is to apply this change:

*** config/x-m88kdgux.orig	Tue Apr  7 17:27:28 1992
--- config/x-m88kdgux	Wed Apr 15 08:42:59 1992
***************
*** 3,4 ****
--- 3,5 ----
  INSTALL = cp
  X_CFLAGS = -D_M88KBCS_TARGET
+ INSTALL_HEADERS = 

###################################################

   dg> when I try to compile a program (which I wrote so it could be horrible,
   dg> but it compiles and runs fine under gcc 1.37 as delivered with the
   dg> AViiON and other C compilers), I get the following error:
   dg>
   dg> symbol                             in file
   dg> ___iob                              felinprp.o
   dg> ld fatal: Symbol referencing errors. No output written to a.out
   dg>
   dg> I do not reference anything called iob.  A grep -i iob *   comes up
   dg> empty.
   
You are still compiling in the m88kbcs target environment.  One of the
things you must do is to explicitly supply the -D_M88KBCS_TARGET option
when you compile.  For more on this, take a look at "Porting Applications
to the DG/UX System".

Newsgroups: gnu.gcc.bug
From: young@vlsi.ll.mit.EDU (George Young)
Subject: gcc-2.1-sparc-sun-sunos4.0.3 -fcaller-saves generates bad code
Reply-To: young@vlsi.ll.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 13:18:47 GMT

Environment: Sun 4/390 SunOS 4.0.3, gcc 2.1
When a module of a C program compiled as:
	gcc -O2 -g k.c -c
or
	gcc -O -fcaller-saves -g k.c -c
the program fails with a bus error.  When compiled as:
	gcc -O2 -fno-caller-saves -g k.c -c
or
	gcc -O -g k.c -c
it runs fine.  

Here's a script of compiling the file:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
make CFLAGS='-O2 -v -g'
gcc -O2 -v -g   -c k.c -o k.o
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.0.4/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.0.4/2.1/cpp -lang-c -v -undef -D__GNUC__
=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__un
ix -D__OPTIMIZE__ -g k.c /usr/tmp/cca06048.i
GNU CPP version 2.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.0.4/2.1/cc1 /usr/tmp/cca06048.i -quiet -
dumpbase k.c -g -O2 -version -o /usr/tmp/cca06048.s
GNU C version 2.1 (sparc) compiled by GNU C version 2.1.
In file included from j.h:54, from k.c:15:
/usr/include/memory.h:6: warning: conflicting types for built-in function `memcpy
'
 as -o k.o /usr/tmp/cca06048.s
gcc a.o ai.o ap.o au.o c.o cc.o cf.o cg.o cp.o cr.o ct.o cx.o f.o i.o io.o j.o k.
o lj.o m.o p.o pc.o pv.o r.o rt.o s.o t.o u.o ut.o v.o vb.o ve.o vg.o vh.o vi.o v
m.o vp.o vs.o vz.o w.o x.o xf.o xs.o xw.o -lm -o j

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

Stepping though with gdb seems to indicate it crashes when returning from
the function 'IfromD', but I don't know enough about function call assembler
code to pinpoint it better.

The source code for this program is ~260 kbytes, so I have not included it here.
I have made it available via anonymous ftp from:
	 vdd.vlsi.ll.mit.edu: ~ftp/pub/j.tar.Z

To manifest the bug, just run make "CFLAGS=-O2 -g", and do:
	echo '.i3 4' | ./j

George Young,  Rm. B-141		young@vlsi.ll.mit.edu
MIT Lincoln Laboratory			young@vdd.vlsi.ll.mit.edu
244 Wood St.				[129.55.11.1]
Lexington, Massachusetts  02173-9108	(617) 981-2756

Newsgroups: gnu.gcc.bug
From: ado@elsie.nci.nih.gov (Arthur David Olson)
Subject: Gnu GCC 2.1 can dump core if -Wtraditional is used (with fix)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 11 Apr 1992 21:06:18 GMT

Index:	gcc-2.1/c-lex.c

(We're running SunOS 4.1.1 on a Sun 4/75 and a Sun 3/280.)

Description:
	Gnu GCC 2.1 can dump core if -Wtraditional is used.

Repeat-By:
	Script started on Sat Apr 11 17:02:31 1992
	bossie.nci.nih.gov$ cat try.c
	strtoul(base) 
	{
	  unsigned long cutoff;

	  cutoff = 4294967295U / (unsigned long) base;
	}
	bossie.nci.nih.gov$ gcc -v -Wtraditional try.c
	Reading specs from /usr/local/lib/gcc-lib/sun4/2.1/specs
	gcc version 2.1
	 /usr/local/lib/gcc-lib/sun4/2.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -Wtraditional try.c /usr/tmp/cca08972.i
	GNU CPP version 2.1 (sparc)
	 /usr/local/lib/gcc-lib/sun4/2.1/cc1 /usr/tmp/cca08972.i -quiet -dumpbase try.c -Wtraditional -version -o /usr/tmp/cca08972.s
	GNU C version 2.1 (sparc) compiled by GNU C version 2.1.
	/usr/local/bin/gcc: Internal compiler error: program cc1 got fatal signal 6
	bossie.nci.nih.gov$ exit

	script done on Sat Apr 11 17:02:59 1992

Fix:
	SCCS/s.c-lex.c: 1.1 vs. 1.2
	*** 1.1/c-lex.c	Sat Apr 11 17:04:05 1992
	--- 1.2/c-lex.c	Sat Apr 11 17:04:06 1992
	***************
	*** 1613,1619 ****
			else if (TREE_UNSIGNED (traditional_type)
				 != TREE_UNSIGNED (ansi_type))
			  warning ("integer constant is unsigned in ANSI C, signed with -traditional");
	! 		else abort ();
		      }
	  #endif
	  
	--- 1613,1620 ----
			else if (TREE_UNSIGNED (traditional_type)
				 != TREE_UNSIGNED (ansi_type))
			  warning ("integer constant is unsigned in ANSI C, signed with -traditional");
	! 		else
	! 		  warning ("width of integer constant may change on other systems with -traditional");
		      }
	  #endif
	  
-- 
		Arthur David Olson	ado@elsie.nci.nih.gov
		ADO and Elsie are Ampex and Borden trademarks

Newsgroups: gnu.gcc.bug
From: ian@case.co.UK (Ian Macpherson)
Subject: GCC-2.1 PROBLEMS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 10:23:33 GMT

	Hello,

	We've just got gcc-2.1 on our Sequent Balance machine, but we're
	having problems installing it. The first is a compilation problem with
	aux-output.c. The other problem is more general and appears when
	the newly built compiler is being used to compile libgcc2. It
	generates code that is objected to by the Dynix assembler.
	GCC 1.40 does not exhibit the same problem.
	Our system is:

	Host:			Sequent Balance
	OS:			DYNIX V3.0.14
	Host compiler:		GCC 1.40
	Host assembler:		Dynix as
	Configuration:		balance-dynix
				Linked `config.h' to `./config/xm-ns32k.h'.
				Linked `tm.h' to `./config/sequent.h'.
				Linked `md' to `./config/ns32k.md'.
				Linked `aux-output.c' to `./config/ns32k.c'.
				Linked `tconfig.h' to `./config/xm-ns32k.h'.

========================== BUG 1 ==========================================
	
	The file aux-output.c (./config/ns32k.c) generates a
	compilation error at line 407. See the diff output below:

407c407
< 	  fprintf (file, "0Dx%08x%08x", u.i[1], u.i[0]);
---
> 	  fprintf (file, "0Dx%08x%08x", u.i[1], u.i[0])l

========================== BUG 2 ==========================================

	The second bug occurs while libgcc2 (or any source file containing
	subroutine calls) is being compiled for _divdi3. The compiler
	seems to use an illegal addressing mode for the "bsr" instruction
	(see the assembler output for divdi3 below). Rather than:

		bsr 0(___negdi2)

	GCC 1.40 and DYNIX cc generate

		bsr ___negdi2

#NO_APP
gcc2_compiled.:
.text
	.align 1
.globl ___divdi3
___divdi3:
	enter [],28
	movqd 0,-4(fp)
	movd 8(fp),-12(fp)
	movd 12(fp),-8(fp)
	movd 16(fp),-20(fp)
	movd 20(fp),-16(fp)
	cmpqd 0,-8(fp)
	ble L3
	comd -4(fp),-4(fp)
	movd -8(fp),tos
	movd -12(fp),tos
	bsr 0(___negdi2)
"/usr/tmp/cc017316.s", line 18: operand 1, expecting an expression or pc-rel
	movd r0,-12(fp)
	movd r1,-8(fp)
	adjspd -8
L3:
	cmpqd 0,-16(fp)
	ble L4
	comd -4(fp),-4(fp)
	movd -16(fp),tos
	movd -20(fp),tos
	bsr 0(___negdi2)
"/usr/tmp/cc017316.s", line 28: operand 1, expecting an expression or pc-rel
	movd r0,-20(fp)
	movd r1,-16(fp)
	adjspd -8
L4:
	movqd 0,tos
	movd -16(fp),tos
	movd -20(fp),tos
	movd -8(fp),tos
	movd -12(fp),tos
	bsr 0(___udivmoddi4)
"/usr/tmp/cc017316.s", line 38: operand 1, expecting an expression or pc-rel
	movd r0,-28(fp)
	movd r1,-24(fp)
	adjspd -20
	cmpqd 0,-4(fp)
	beq L5
	movd -24(fp),tos
	movd -28(fp),tos
	bsr 0(___negdi2)
"/usr/tmp/cc017316.s", line 46: operand 1, expecting an expression or pc-rel
	movd r0,-28(fp)
	movd r1,-24(fp)
	adjspd -8
L5:
	movd -28(fp),r0
	movd -24(fp),r1
	br L2
L2:
	exit []
	ret 0
	.align 1
___negdi2:
	enter [r3,r4,r5],16
	movd 8(fp),r2
	movd 12(fp),r3
	movd r2,-16(fp)
	movd r3,-12(fp)
	negd -16(fp),-8(fp)
	negd -12(fp),r4
	cmpqd 0,-8(fp)
	sned r0
	movd r4,r5
	subd r0,r5
	movd r5,r0
	movd r0,-4(fp)
	movd -8(fp),r0
	movd -4(fp),r1
	br L1
L1:
	exit [r5,r4,r3]
	ret 0

-- 
Ian Macpherson
Phone:	+44 (923) 258229
Email:	uknet!case!ian  or  ian@case.co.uk
--

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Bug in gcc 2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 21:42:41 GMT

This problem should be fixed in the next version of gcc.

> From: Frank Nobis <fn@trinity.do.open.de>
> Message-Id: <9204130517.AA01491@trinity.do.open.de>
> Subject: Bug in gcc 2.1
> To: bug-gcc@prep.ai.mit.edu
> Date: Mon, 13 Apr 92 7:17:00 MEST
> X-Mailer: ELM [version 2.3 PL11]
> Resent-From: bug-gcc-request@prep.ai.mit.edu

> I got a fatal compiler error from cc1plus.

> This is the code wich produced the bug.

> -----------------------------------------------------------------------------
> // This may look like C code, but it is really -*- C++ -*-

> class t {
>   int	some_data;
> public:
>   typedef unsigned long ulong;
>   t() { some_data = 0; };
>   void some_function(void) { some_data++; };
> };

> int main()
> {
>   t	t1;

>   t1.some_function();

>   return (0);
> }
> ------------------------------------------------------------------------------

> This code will compile without errors if you move the typedef before
> the definition of the class. But I think this it is legal to put a
> typedef inside a class definiton.

> This is the output from gcc.

> Reading specs from /usr/local/lib/gcc-lib/i386sco/2.1/specs
> gcc version 2.1
>  /usr/local/lib/gcc-lib/i386sco/2.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -DM_UNIX -DM_I386 -DM_COFF -DM_WORDSWAP -DSCO -DUSG -D__unix__ -D__i386__ -D__M_UNIX__ -D__M_I386__ -D__M_COFF__ -D__M_WORDSWAP__ -D__SCO__ -D__USG__ -D__unix -D__i386 -D__M_UNIX -D__M_I386 -D__M_COFF -D__M_WORDSWAP -D__SCO -D__USG bug.cc /usr/tmp/cca01420.i
> GNU CPP version 2.1 (80386, ATT syntax)
>  /usr/local/lib/gcc-lib/i386sco/2.1/cc1plus /usr/tmp/cca01420.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca01420.s
> GNU C++ version 2.1 (80386, ATT syntax) compiled by GNU C version 2.1.
> /usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 10

Newsgroups: gnu.gcc.bug
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: extern inline useless in GCC 2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 14:59:22 GMT

GCC 2.1 on hp300bsd (geech.gnu.ai.mit.edu).

The following input:

extern int foobar (void);
extern inline int foobar (void) { return 1; }

bar ()
{
  return foobar ();
}

produces:

foo.c:2: warning: `foobar' declarations disagree about `inline'

This completely defeats the purpose of `extern inline'.
Please fix it.

Newsgroups: gnu.gcc.bug
From: leisner@johnker.henr801@xerox.COM (Marty Leisner x76704 siena)
Subject: gcc 2.1 bug making gnuplot 3.1 on Sparcstation
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Tue, 14 Apr 1992 14:41:23 GMT

I have gcc 2.1 running on a Sparcstation 2 running Sunos 4.1.1B.

Making gnuplot 3.1 (which I believe I got off prep...), I got this:

make  CC="gcc " 	COPTS="-O -g -W " DEST="/usr/gnu/bin" MANDEST="/usr/gnu/man/man1" HELPDEST="/usr/gnu/lib/gnuplot.gih" EMAIL="bug-gnuplot%pixar.uucp@sun.com" LASERGNU="lasergnu_noinstall" CFLAGS="-O -g -W  -DREADLINE -DNOCWDRC" LIBS="-lm -lplot" X11FLAGS="" X11INCLUDES="-I/usr/include/X11 -I/usr/include/X11/Xaw" X11LIBS="-lXaw -lXmu -lXt -lXext -lX11" PLOTXFLAG="-DX11" GNUPLOT_X11=gnuplot_x11 X11INSTALL="x11_install" TERMFLAGS="-Iterm -DUNIXPLOT -DX11"    All 
gcc  -O -g -W  -DREADLINE -DNOCWDRC   -c graphics.c -o graphics.o
gcc: Internal compiler error: program cc1 got fatal signal 11
make[1]: *** [graphics.o] Error 1
make: *** [x11r4] Error 1

Playing with COPTS didn't make a different.  


marty
leisner.henr801c@xerox.com
Member of the League for Programming Freedom
(You get what you pay for -- except in software)

Newsgroups: gnu.gcc.bug
From: dan@uiucmath.math.uiuc.edu (Daniel R. Grayson)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 13:19:36 GMT

In compiling gdb 4.4 on a vaxstation II with ultrix 2.0 I get this strange gcc
error:

gcc -c -g     -I. -I. -I./../include -I./../readline -I./vx-share  breakpoint.c
make[1]: execve: /usr/local/bin/gcc: Arg list too long
make[1]: *** [breakpoint.o] Error 127
make: *** [just-gdb] Error 1

Newsgroups: gnu.gcc.bug
From: wweston@steer.sdsu.edu (stewart k)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 11 Apr 1992 12:59:13 GMT

gnu,
	I'm trying to install gcc-2.1 on the elxsi machine at SanDiego State
U.  I'm told there are over 100 of these machines in use.  We are now using
gcc-1.35; so I would think the installation is posible.  If you can tell me
where to get the "config" files or the address of someone who has made this
install, it would sure help.
						maxc0310@ucselx.sdsu.edu
.

Newsgroups: gnu.gcc.bug
From: axel@thor.informatik.uni-osnabrueck.de (Axel Schreiner)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 10:44:31 GMT

gcc-2.1 configured for next

NeXT 2.1 "ld" returns the following error, e.g. when making gperf:

ld: options.o symbol 61 (___DTOR_LIST__) has unknown n_type field (0x16)

since "collect2" feeds the system's loader "ld", g++ stuff cannot be
loaded.

Additionally, "nm" displays a "?" as type field for __CTOR_LIST__ and
__DTOR_LIST__ when applied as "nm options.o".

The problem results from the default code in varasm.c defining constructors
and destructors.  To fix insert

	#define ASM_OUTPUT_CONSTRUCTOR(FILE,NAME)
	#define ASM_OUTPUT_DESTRUCTOR(FILE,NAME)
	#define ASM_OUTPUT_GC_ENTRY(FILE,NAME)

into config/next.h as an "#else" to the "#if 0" which surrounds alternative
definitions and promises for them to work under NeXT system 3.0.

PS: varasm.c contains the same definition for these operations as does,
e.g., config/aoutos.h. Wouldn't it make more sense for varasm.c not to do
anything and let the various machine files take appropriate action?

Newsgroups: gnu.gcc.bug
From: sm@information-systems.east-anglia.ac.UK
Subject: g++ v 2.0 on a Sun SPARC 2 ( Sun OS v 4.1.1 )
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 18:23:51 GMT

Hi,

gcc v 2.0 compiles 'C' src's just fine, but I'm a bit confused about g++.

I'm using the gnu-ld distributed with binutils v 1.9.

I named gnu-ld 'ld' and installed it in /usr/local/bin and linked this into

/usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0.

Do I need to use crt1+.o ?

Here is the output from an attempt at compiling a C++ src :

Reading specs from /usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/specs
gcc version 2.0
 /usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/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 /home/staff/ba/trains/ae.cc
/usr/tmp/cca16782.cpp
GNU CPP version 2.0 (sparc)
 /usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/cc1plus /usr/tmp/cca16782.cpp
-quie
t -dumpbase ae.cc -version -o /usr/tmp/cca16782.s
GNU C++ version 2.0 (sparc) compiled by GNU C version 2.0.
 as -o ae.o /usr/tmp/cca16782.s
 /usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/ld -e start -dc -dp
/usr/local/lib/
gcc/sparc-sun-sunos4.1.1/2.0/crt0.o
-L/usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.
0/ -L/usr/local/lib/gcc/ -L/usr/local/lib/ ae.o -lgcc -lc -lgcc
crt1.c:45 (/usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/crt0.o): Undefined
symbol
 ___dli referenced from text segment
crt1.c:45 (/usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/crt0.o): Undefined
symbol
 ___dli referenced from text segment
crt1.c:45 (/usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/crt0.o): Undefined
symbol
 ___dlp referenced from text segment
crt1.c:45 (/usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/crt0.o): Undefined
symbol
 ___dlp referenced from text segment
crt1.c:45 (/usr/local/lib/gcc/sparc-sun-sunos4.1.1/2.0/crt0.o): Undefined
symbol
 ___dlp referenced from text segment

Thanks in advance for your help.


Shaun McCullagh (RA)
School of Information Systems.,
University of East Anglia.,
Norwich
England NR4 7TJ

sm@uk.ac.uea.sys ( JANET )      	       	Tel +44 603 592692
sm@sys.uea.ac.uk ( Other Nets ) 	       	FAX +44 603 507720

*******************************************************************
"I can feel the Data coming out of my Macintosh"           Anon.
*******************************************************************


Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 08:25:28 GMT

> Message-Id: <9204071619.AA27139@life.ai.mit.edu>
> To: bug-gcc@prep.ai.mit.edu
> Subject: g++ bug report
> Date: Tue, 07 Apr 92 17:17:52 +0100
> From: Russel Winder <R.Winder@cs.ucl.ac.uk>

All bug reports concerning g++ should go to the
bug-g++@prep.ai.mit.edu list, not this one.  (Note, I have queued this
one into the g++ bugs queue.)

> Attached are two strip-down programs highlighting at least 2 bugs in g++
> 2.1.

Newsgroups: gnu.gcc.bug
From: vbl@zip.eecs.umich.edu
Subject: possible gcc bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 13:17:01 GMT

It appears that the following is a bug.  Both versions of the
program compile using Sun's CFront compiler.

//================================================
//Program 1: (does not compile)

class MyClass {
public:
    MyClass () { }
    MyClass &operator=(char c) { return *this; } // line 5
    operator int() { return 9; }  // <---- DIFF
};
int main() {
    MyClass foo;
}

On a Sun Sparc running SunOS 4.1.2, gcc 2.1 generates:

127 adirondacks> gcc -v myclass.cc
Reading specs from /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1.2/2.1/specs
gcc version 2.1
 /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1.2/2.1/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 myclass.cc /usr/tmp/cca13027.i
GNU CPP version 2.1 (sparc)
  /usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1.2/2.1/cc1plus /usr/tmp/cca13027.i -quiet -dumpbase myclass.cc -version -o /usr/tmp/cca13027.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
myclass.cc: In method `class MyClass& MyClass::operator = (char)':
myclass.cc:5: too many arguments for constructor `MyClass'
myclass.cc:5: in conversion to type `MyClass'
myclass.cc:5: too many arguments for constructor `MyClass'
myclass.cc:5: in conversion to type `MyClass'
myclass.cc:5: too many arguments for constructor `MyClass'
myclass.cc:5: in conversion to type `MyClass'
...  (repeat infinitely)

//================================================


//------------------------------------------------
//Program 2: (compiles)
class MyClass {
public:
    MyClass () { }
    MyClass &operator=(char c) { return *this; }
    operator char() { return 'x'; }  // <---- DIFF
};
int main() {
    MyClass foo;
}
//------------------------------------------------


Newsgroups: gnu.gcc.bug
From: tevi@iilcad.intel.com (Devor Tevi)
Subject: bug in self build with -O -finline-functions -g
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 17:52:28 GMT

Bug when trying to self build with -O -finline-functions -g

When compiling the file regclass.c I get the following error:

(EOF):undefined name: ._I12_22

Note that without the -g I don't get the error.

I am using gcc from 25-March-92 configured for i386v4.

Regards,
Tevi.

tevi@iilcad.intel.com
972-4-355675

Newsgroups: gnu.gcc.bug
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Subject: gcc 2.1 spurious warning for "-Wno-import"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 19:19:10 GMT

The preprocessor for gcc/g++ 2.1 knows how to parse the
options "-Wno-import" and "-Wimport" (for turning
those warnings off and on).  However, these were left out
of the option parsing in c-decl.c:  c_decode_option(). 

This error shows up in both gcc and g++, of course. 


Here is a fix:

*** c-decl.c.orig	Wed Apr 15 12:15:37 1992
--- c-decl.c	Wed Apr 15 12:16:56 1992
***************
*** 612,617 ****
--- 612,621 ----
      ; /* cpp handles this one.  */
    else if (!strcmp (p, "-Wno-trigraphs"))
      ; /* cpp handles this one.  */
+   else if (!strcmp (p, "-Wimport"))
+     ; /* cpp handles this one.  */
+   else if (!strcmp (p, "-Wno-import"))
+     ; /* cpp handles this one.  */
    else if (!strcmp (p, "-Wall"))
      {
        extra_warnings = 1;

Newsgroups: gnu.gcc.bug