HDTenEightyP/NetNews huggingface dataset:
From: jgealow@mtl.mit.edu (Jeffrey C. Gealow)
Subject: GNU CC install-fixincludes problem
Reply-To: jgealow@mtl.mit.edu
Organization: MIT Microsystems Technology Laboratories
Distribution: gnu
Date: Sat, 12 Dec 1992 05:33:12 GMT

I have encountered a problem during installation.

After doing the command `make install-fixincludes', the header file 
/usr/local/gnu/lib/gcc-lib/sparc-sun-sunos/2.3.2/include/syslimits.h 
no longer exists.  The file did exist prior to the 
`make install-fixincludes'.  This causes errors when attempting to 
compile code which #include's <limits.h>.

GNU CC Version 2.3.2
SPARCstation
SunOS 4.1.3

# GCC was configured as follows:
./configure -prefix=/usr/local/gnu -target=sparc-sun-sunos4.1
echo host=sparc-sun-sunos4.1 target=sparc-sun-sunos4.1 build=sparc-sun-sunos4.1

I did not encounter this problem with previous versions of GCC.

I hope this report may be useful.  Thank you for your efforts.

Jeff

Newsgroups: gnu.gcc.bug
From: stuart@bms88.bmsi.COM (Stuart D. Gathman)
Subject: bug in g++2.3.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 17 Dec 1992 00:01:48 GMT

The following (short extract of a) program causes cc1plus to use an
infinite amount of virtual memory while expanding Money FNUM<2>::operator--().

While returning Money(*this) fixes this short test program, all my programs
using templates similar to FNUM crash the 2.3.2 compiler.  The 2.2.2 compiler
compiles them correctly (including this test program).

Output of g++ -v:

      Reading specs from /usr/local/lib/gcc-lib/delta88/2.3.2/specs
      gcc version 2.3.2

delta88 is basically m88k-motorola-sysv3 with about a dozen lines of
config/m88kv3.h hacked to use .ctor and .dtor segments (each consisting
of a null terminated list of function pointers) rather than
the .init segment.

The test program:
-------------------------test.cc-------------------------------
class Money {
  long high;
  unsigned short low;
public:
  Money(long = 0);
  Money(const Money &m): high(m.high), low(m.low) {}
  Money(const char *,int = 6);		
  void store(char *,int = 6) const;
  Money &operator -=(const Money &);
  Money operator -(const Money &a) const { Money t(a); return t -= *this; }
};

template <int size> class FNUM {
  char num[size];
public:
  FNUM() { memset(num,0,size); }
  FNUM & operator = (const Money &m) { m.store(num,size); return *this; }
  FNUM & operator = (FNUM &a) {
    memcpy(num,a.num,size);
    return *this;
  }
  operator Money() const { return Money(num,size); }
  Money operator --() { *this = Money(num,size) - 1L; return *this; }
};

struct DataDict {
  FNUM<2>	line;	
};
---------------------------------------------------
Output of cc1plus (interrupted before "virtual memory exhausted" error):

Money::Money (const class Money&) class Money Money::operator - (const class Money&)const  class Money FNUM<2>::operator -- ()


	stuart@bmsi.com

Newsgroups: gnu.gcc.bug
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, 13 Dec 1992 17:19:58 GMT

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        ``Vivement GNU!''       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: pasieka%sureal@cs.umass.edu
Subject: Small addition
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 17:46:21 GMT

I have been looking at and modifying GCC 2.2.2 for the project I am
working on here at UMass. I have found what I consider to be a slight
error in the file stmt.c. Specifically the macro POPSTACK does not
correctly adjust the value of nesting_depth. The original macro is:

#define POPSTACK(STACK)					\
do { int initial_depth = nesting_stack->depth;		\
     do { struct nesting *this = STACK;			\
	  STACK = this->next;				\
	  nesting_stack = this->all;			\
	  nesting_depth = this->depth;			\
	  obstack_free (&stmt_obstack, this); }		\
     while (nesting_depth > initial_depth); } while (0)

I have added to the last line a decrementation of nesting_depth as follows:

#define POPSTACK(STACK)					\
do { int initial_depth = nesting_stack->depth;		\
     do { struct nesting *this = STACK;			\
	  STACK = this->next;				\
	  nesting_stack = this->all;			\
	  nesting_depth = this->depth;			\
	  obstack_free (&stmt_obstack, this); }		\
     while (nesting_depth > initial_depth);  --nesting_depth; } while (0)

Given the following program:

main ()
{
  int x, y, z;

  y = 0;
  z = 0;

  for (x=1 ; x<10; x++) {
    y++;
  }

  for (x=1 ; x<10; x++) {
    z++;
  }

}

the value of nesting_depth while parsing both y++ and z++ should be 2.
Without the change the value is correct while parsing y++ but is 3
while parsing z++.

Is this a bug or a feature?

Please feel free to contact me about this if I can provide more
information. I can be reached via email at pasieka@cs.umass.edu or by
phone at 413/545-2447.

-- Michael

Newsgroups: gnu.gcc.bug
From: jpr@jpradley.JPr.COM (Jean-Pierre Radley)
Subject: Re: syslimits.h non existant on sunos4.N
Organization: Unix in NYC
Distribution: gnu
Date: Thu, 17 Dec 1992 03:55:50 GMT

In article <9212141459.AA29837@cuthbert.bashstreet> dunstan@gec-epl.co.UK (Dunstan_Vavasour) writes:
>I have recently made gcc-2.3.2. I then proceeded to make glibc-1.05.
>
>I am using a spaarcstation IPC running SunOS 4.1.1 Rev B.
>
>A have had recurrent error messages about syslimits.h not being found.
>

Same here on SCO ODT 2.0, after using the sysv fix file, rather than
fixincludes.

I just changed <syslimits.h> to <limits.h>. Foolish?

-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341

Newsgroups: gnu.gcc.bug
From: marshall@software.org (Eric Marshall)
Subject: trouble linking Objective C files
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 20:41:00 GMT

	I am running gcc version 2.3.2 on a Sparc running SunOS 4.1.1.
I built the languages c, c++, and objective-c as described in INSTALL. 
The problem I am experiencing is that when I link an Objective-C
program I get the following message:

	% gcc -lobjc -Wno-import -B/u1/marshall/yukon/gcc_support/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2 which.m
	which.m:0: storage size of `_OBJC_SELECTOR_REFERENCES' isn't known
	gcc: file path prefix `/u1/marshall/yukon/gcc_support/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2' never used

	The contents of .../sparc-sun-sunos4.1/2.3.2 are:

	% ls -F /u1/marshall/yukon/gcc_support/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2
cc1*            cc1plus*        include/        libgcc.a        specs*
cc1obj*         cpp*            ld*             libobjc.a

Newsgroups: gnu.gcc.bug
From: warsaw@nlm.NIh.GOV (Barry A. Warsaw)
Subject: Re: syslimits.h non existant on sunos4.N
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Distribution: gnu
Date: Wed, 16 Dec 1992 19:27:18 GMT

Just posted a fix on gnu.g++.lib.bug.  I found this article giving a
fix. Note that I had to re-run configure before re-running `make
install-fixincludes' presumably to regenerate the Makefile....

-Barry

-------------------- snip snip --------------------
From: wilson@cygnus.com
Subject: gcc 2.3.2 syslimits.h problem
Date: Tue, 1 Dec 1992 18:36:34 GMT

This will make limits.h/syslimits.h work again.

Apply the patch, and then rerun `make install-fixincludes'.

Mon Nov 30 12:03:13 1992  Jim Wilson  (wilson@sphagnum.cygnus.com)

        * Makefile.in (INSTALLED_H): Add syslimits.h.

*** ../clean-gcc-2.3.2/Makefile.in      Wed Nov 25 20:43:52 1992
--- Makefile.in Mon Nov 30 11:56:19 1992
***************
*** 405,411 ****
      va-pa.h va-pyr.h va-sparc.h va-spur.h proto.h $(EXTRA_HEADERS)
  
  # All the header files that are installed for users from GCC itself.
! INSTALLED_H = float.h stddef.h stdarg.h varargs.h $(USER_H) limits.h
  
  # The files that "belong" in CONFIG_H are deliberately omitted
  # because having them there would not be useful in actual practice.
--- 405,412 ----
      va-pa.h va-pyr.h va-sparc.h va-spur.h proto.h $(EXTRA_HEADERS)
  
  # All the header files that are installed for users from GCC itself.
! INSTALLED_H = float.h stddef.h stdarg.h varargs.h $(USER_H) limits.h \
!     syslimits.h
  
  # The files that "belong" in CONFIG_H are deliberately omitted
  # because having them there would not be useful in actual practice.


Newsgroups: gnu.gcc.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: Can a varargs simple function be inlined?
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
Distribution: gnu
Date: Wed, 16 Dec 1992 19:37:25 GMT

I'm running gcc 2.3.2 on sparcs, sunos 4.1.2

I have a simple function which I want to inline which uses varargs...

     4  static void inline test_args( char *fmt, ...)
     5  {
     6  #if 0
     7          va_list args;
     8  
     9          va_start(args, fmt);
    10  
    11          vfprintf(stderr, fmt, args);
    12  
    13          va_end(args);
    14  #endif
    15  }

I used -finline-functions and received a warning:
"inline declaration ignored for function with `...'

So I played around and tried:
     3  #ifndef 0
     4  static void test_args()
     5  {
     6  }
     7  #else
     8  static void inline test_args( char *fmt, ...)
     9  {
    10          va_list args;
    11  
    12          va_start(args, fmt);
    13  
    14          vfprintf(stderr, fmt, args);
    15  
    16          va_end(args);
    17  }
    18  #endif

and I can't seem to make an empty function inline  (removing the call).

Hints?

--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom

Newsgroups: gnu.gcc.bug
From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Subject: Re: fixinclude problem on EP/IX machine
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Distribution: gnu
Date: Sat, 19 Dec 1992 10:40:23 GMT

apardon@vub.ac.BE (Antoon Pardon) writes:

>I have tried to install gcc 2.2.2 on a CDC machine running EP/IX 1.4.3
>This is a mipsbox with some modifications to the O.S. Its a sysv-bsd
>hybrid.

Try gcc Version 2.3.1 or 2.3.2, the fixincludes problem should be gone.
I'm using gcc 2.3.1 both mips-sysv and mips-bsd on a CD4680 flawlessly.

Sincerely,
Klaus Steinberger
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE

Newsgroups: gnu.gcc.bug
From: rrh@tera.com (Robert R. Henry)
Subject: sizeof large structures broken in gcc2.3.[12]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 16 Dec 1992 18:52:25 GMT

When manipulating obscenely large structures...

For gcc2.3.1 target==host==sparc-sun-sunos4.1, the program at the bottom
prints out (lines marked '*' are my editing to show errors)
* sizeof(struct RootSection) == 0xf0000000, 3840 Mb
* sizeof(struct RootMemory) == 0xf0000000, 3840 Mb
  &p->instruction_buffer = 0xc0000000
  &p->outbound_buffer = 0xd0000000
* &p->inbound_buffer = 0xc0000000
For gcc2.3.1, target==host==dec-mips-ultrix, the same program prints out
  sizeof(struct RootSection) == 0x10000000, 256 Mb
* sizeof(struct RootMemory) == 0x10000000, 256 Mb
  &p->instruction_buffer = 0xc0000000
  &p->outbound_buffer = 0xd0000000
* &p->inbound_buffer = 0xc0000000
which is a bit closer to the correct answer; I believe that the correct
answer should be:
  sizeof(struct RootSection) == 0x10000000, 256 Mb
  sizeof(struct RootMemory) == 0x30000000, 768 Mb
  &p->instruction_buffer = 0xc0000000
  &p->outbound_buffer = 0xd0000000
  &p->inbound_buffer = 0xe0000000

At the very least some warning message could be issued.

sun's native cc, and dec-ultrix cc both topple over with this.


Reading specs from /usr/local/lib/gcc-lib/sparc-sun/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/sparc-sun/2.3.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix junk3.c /usr/tmp/cca02979.i
GNU CPP version 2.3.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun/2.3.1/cc1 /usr/tmp/cca02979.i -quiet -dumpbase junk3.c -version -o /usr/tmp/cca02979.s
GNU C version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
 /usr/local/lib/gcc-lib/sparc-sun/2.3.1/as -o /usr/tmp/cca029791.o /usr/tmp/cca02979.s
 /usr/local/lib/gcc-lib/sparc-sun/2.3.1/ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun/2.3.1 -L/usr/local/lib /usr/tmp/cca029791.o -lgcc -lc -lgcc

#include <stdio.h>
typedef unsigned int u_int;
#define Mb (1024*1024)
struct RootSection {
  u_int data[(128/sizeof(u_int)) * Mb];
  u_int csr[(128/sizeof(u_int)) * Mb];
};
struct RootMemory {
  struct RootSection instruction_buffer;
  struct RootSection outbound_buffer;
  struct RootSection inbound_buffer;
};

#define ROOT_MEMORY_ADDRESS 0xc0000000

main()
{
  struct RootMemory *p = (struct RootMemory *) ROOT_MEMORY_ADDRESS;

  printf("sizeof(struct RootSection) == 0x%08x, %d Mb\n",
    (u_int)sizeof(struct RootSection),
    (u_int)sizeof(struct RootSection)/Mb
  );
  printf("sizeof(struct RootMemory) == 0x%08x, %d Mb\n",
    (u_int)sizeof(struct RootMemory),
    (u_int)sizeof(struct RootMemory)/Mb
  );

  printf("&p->instruction_buffer = 0x%08x\n", &p->instruction_buffer);
  printf("&p->outbound_buffer = 0x%08x\n", &p->outbound_buffer);
  printf("&p->inbound_buffer = 0x%08x\n", &p->inbound_buffer);
}

Newsgroups: gnu.gcc.bug
From: higgins@math.niu.edu (Greg Higgins)
Subject: *** [zoneinfo/US/Eastern] Segmentation fault (core dumped)
Organization: Northern Illinois University
Distribution: gnu
Date: Mon, 14 Dec 1992 05:36:07 GMT

I'm using gcc-2.3.2 on sparc-sun-sunos4.1.1; I've created the stage2
compiler successfully.

Now I'm tyrying to create glibc-1.05. 

I do a make lib, which seems to go OK, but then during the 
make install, the following error occurs:

gmake -C time subdir_install
gmake[1]: Entering directory `/usr/local/software/gnu/glibc-1.05/time'
ar ruv ../libc.a offtime.o asctime.o clock.o ctime.o difftime.o gmtime.o 
localtime.o mktime.o strftime.o time.o __tzset.o tzfile.o __gettod.o settod.o 
adjtime.o getitmr.o __getitmr.o __adjtime.o __settod.o __setitmr.o 
tzset.o gettod.o setitmr.o stime.o syms-time.o
ranlib ../libc.a
gcc -nostdlib -o zic ../start.o zic.o ../libc.a scheck.o ialloc.o emkdir.o -lgcc ../libc.a
zic -d zoneinfo -L leapseconds northamerica
gmake[1]: *** [zoneinfo/US/Easern] Seation fault (core dumped)
gmake[1]: Leaving directory `/usr/local/software/gnu/glibc-1.05/time'

My configparms file looks like:
-D__SIZE_TYPE='unsigned long int'
override stddef.h =
override stdarg.h =
timezone = US/Central


Anyone have any idea what's going wrong? Yes, I did do the install-fixincludes
when making gcc.

Please reply by e-mail if possible, I will summarize.


Gregory Higgins, Systems Manager, higgins@math.niu.edu
			

Newsgroups: gnu.gcc.bug
From: rcf@sioux.eel.ufl.edu (Robert Fellenz)
Subject: Problem linking libg++.a (rev.)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 23:50:15 GMT

After installing gcc-2.3.2 and libg++-2.3, I noticed that the g++ compiler
could not find the libg++.a library.  I determined the linker (/bin/ld) was
only using the default paths to find the libraries (/lib /usr/lib).  Since
/usr/local/lib/libg++.a was not in the default path, the library could not
be linked.  To resolve this problem, I placed a link from /usr/bin to the
library.

I would like to know if it is possible to have the compilers from gcc-2.3.2
automatically search for libg++.a in /usr/local/lib/ without having to make
links from /lib and /usr/lib.

NOTE: Our previous version of gcc (gcc-2.1) did not have this problem.


Architecture:  HP9000/425
Operating Sys: HP-UX 8.0
Configure args:m68k-hp-hpux
GNU CC vers.:  gcc-2.3.2
Library:       libg++-2.3

EXAMPLE:

	bash$ gcc -lgcc tst.c
	ld: cannot find library for -lgcc
	ld: (Warning) did not generate an output file
	collect: /bin/ld returned 1 exit status


Thanks in advance...
 

Pleas email me at rcf@sioux.eel.ufl.edu

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

Robert Fellenz
University of Florida
rcf@sioux.eel.ufl.edu









Newsgroups: gnu.gcc.bug
From: rcf@sioux.eel.ufl.edu (Robert Fellenz)
Subject: Linker Error (___ls__RF7ostreamPCc)
Organization: UF EE Department
Distribution: gnu
Date: Sun, 20 Dec 1992 05:33:54 GMT

Architecture:  HP9000/425
Operating Sys: HP-UX 8.0
GNU CC vers.:  gcc-2.3.2
Config option: m68k-hp-hpux
g++ library:   libg++-2.3

I am currently having trouble with the linker giving the following error: 

	        g++ -O2 -I/local/lib/g++-include    -o a.out *.o
	-L/usr/local/interviews3.1a/lib/$CPU   -lIV  -lXext -lX11 -lm
	ld: Undefined external -
	        ___ls__FR7ostreamPCc
	ld: output file still contains undefined symbols
	collect: /bin/ld returned 1 exit status
	*** Error code 1

If g++ from gcc-2.1 is used the linker will compile correctly.  I would appreciate it if anyone could assist me in this matter.

Please email me at rcf@sioux.eel.ufl.edu.


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

Robert Fellenz
rcf@sioux.eel.ufl.edu

Newsgroups: gnu.gcc.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Optimizer Bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 19:03:09 GMT

    Dear League for Programming Freedom

    We currently use gcc-2.3.2. We encountered the following bug in the
    optimizer.

There must be some confusion.  The League for Programming Freedom has
nothing to do with GCC, or GNU, or free software at all.

The League for Programming Freedom campaigns to protect all
programmers from being sued for writing programs.  If you want
information, contact lpf@uunet.uu.net.


Newsgroups: gnu.gcc.bug
From: rcf@sioux.eel.ufl.edu (Robert Fellenz)
Subject: Linker Error (___ls__RF7ostreamPCc)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 19 Dec 1992 19:32:52 GMT

Architecture:  HP9000/425
Operating Sys: HP-UX 8.0
GNU CC vers.:  gcc-2.3.2
Config option: m68k-hp-hpux
g++ library:   libg++-2.3

I am currently having trouble with the linker giving the following error: 

	        g++ -O2 -I/local/lib/g++-include    -o a.out *.o
	-L/usr/local/interviews3.1a/lib/$CPU   -lIV  -lXext -lX11 -lm
	ld: Undefined external -
	        ___ls__FR7ostreamPCc
	ld: output file still contains undefined symbols
	collect: /bin/ld returned 1 exit status
	*** Error code 1

If g++ from gcc-2.1 is used the linker will compile correctly.  I would
appreciate it if anyone could assist me in this matter.

Please email me at rcf@sioux.eel.ufl.edu.


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

Robert Fellenz
rcf@sioux.eel.ufl.edu

Newsgroups: gnu.gcc.bug
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: missed long long optimizations on i386
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 20 Dec 1992 00:45:33 GMT

This is not a bug report, only a hint that "long long" performance on
i386 may be improved.

I'm working with gcc 2.2.2, configured as i386-linux.

Input file:

============================== lltest.c =====================================
unsigned long foo (unsigned long long x)
{ return x & 0x00000000FFFFFFFFULL; }

unsigned long foo2 (unsigned long long x, unsigned long long y)
{ unsigned long long z = x + y;
  z &= 0x00000000FFFFFFFFULL;
  return z;
}

unsigned long long bar (void* addr)
{ return (unsigned long long)(unsigned long)(addr) + 0x0000000D00000000ULL; }

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

Output from "gcc -O6 -S lltest.c", with comments:

================================= lltest.s ===================================
	.file	"lltest.c"
gcc2_compiled.:
.text
	.align 2
.globl _foo
_foo:
	pushl %ebp
	movl %esp,%ebp
	movl 8(%ebp),%eax
	movl 12(%ebp),%edx              ! superfluous
	leave
	ret
	.align 2,0x90
	.align 2
.globl _foo2
_foo2:
	pushl %ebp
	movl %esp,%ebp
	pushl %ebx
	movl 8(%ebp),%ecx
	movl 12(%ebp),%ebx
	addl 16(%ebp),%ecx
	adcl 20(%ebp),%ebx
	movl %ecx,%eax
	xorl %edx,%edx                   ! superfluous
	movl -4(%ebp),%ebx
	leave
	ret
	.align 2
.globl _bar
_bar:
	pushl %ebp
	movl %esp,%ebp
	movl 8(%ebp),%eax
	movl %eax,%edx                    !
	xorl %ecx,%ecx                    ! may be replaced by
	movl %edx,%eax                    ! a simple
	movl %ecx,%edx                    !
	addl $0,%eax                      !    movl $13,%edx
	adcl $13,%edx                     !
	leave
	ret
	.align 2,0x90
==============================================================================

Note further that gcc (even without -O) aborts like this on some bigger
functions that use many "long long" variables. I can provide examples.
   gcc: Internal compiler error: program cc1 got fatal signal 6

Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de

Newsgroups: gnu.gcc.bug
From: Garrett.Wollman@uvm.edu
Subject: GCC 2.3.1 (rs6000): unrecognizable insn
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Dec 1992 11:44:25 GMT

While compiling InterViews 3.1 for the RS6000, I had the following
error while making Doc:

g++ -O      -Dcplusplus_2_1  -DSYSV -DAIXV3 -I../../../.././src/include -I/usr/local/include   -c ../Document.c
../Document.c: In function `void  _GLOBAL_.I.arabic_formatter__FlPc ()':
../Document.c:317: internal error--unrecognizable insn:
(insn 1348 1346 389 (set (reg:DI 3 3)
       (reg:DI 64 mq)) -1 (nil)
   (nil))
/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

In addition, I also noticed (with some irritation) that G++ emits two
separate (but equal) symbols for every C++ member function it
compiles.  When I try to make a shared library, this causes `ld' to
complain ``WARNING:  Duplicate symbol '__4Long7Mangled4NameUiUiUiUi' ''.  This
is a significant irritation when the library in question has 10,000+
symbols in it.  I also get  the complaint:

0706-768 WARNING: PREBIND: Instruction following BRANCH is not LOAD.

but I don't know if this is due to the current version of gcc, or the
previous version (which was used to build libg++).

I can provide more details if necessary.

-GAWollman


Newsgroups: gnu.gcc.bug