HDTenEightyP/NetNews huggingface dataset:
From: eric@leonardo.synnet.com (Eric Baur)
Subject: gcc-2.3.1 -fpic problem [simple patch]
Organization: Synernetics Inc
Distribution: gnu
Date: Thu, 5 Nov 1992 04:42:06 GMT

Apparently new code was added to 2.3.1 to simplify some expressions is
assembler output. This broke -fpic.  Attempting to output pic data
references causes the compiler to abort. Here's a simple patch to
varasm.c which seems to cure the problem. 

2217,2220c2217,2218
<   if ( GET_CODE (XEXP (x, 1)) != PC ) 
<       {
<           decode_rtx_const (GET_MODE (x), XEXP (x, 0), &val0);
<           decode_rtx_const (GET_MODE (x), XEXP (x, 1), &val1);
---
>   decode_rtx_const (GET_MODE (x), XEXP (x, 0), &val0);
>   decode_rtx_const (GET_MODE (x), XEXP (x, 1), &val1);
2222,2224c2220,2221
<           if (val0.un.addr.base == val1.un.addr.base)
<               return GEN_INT (val0.un.addr.offset - val1.un.addr.offset);
<       }
---
>   if (val0.un.addr.base == val1.un.addr.base)
>     return GEN_INT (val0.un.addr.offset - val1.un.addr.offset);

Eric Baur                       eric@synnet.com
Synernetics Inc                 (508) 670-9009

Newsgroups: gnu.gcc.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: gcc 2.3.1 install-common
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 05:56:04 GMT

The install-common target in GCC 2.3.1's Makefile depends on
$(srcdir)/c++.  By virtue of the rule that makes c++ depend on cc1plus,
this means that GNU C++ gets compiled even though I specified only
LANGUAGES=c to `make install'.

I'm not sure what a good fix is; I simply deleted install-common's
dependencies on $(srcdir)/c++ and $(srcdir)/g++.

This was on a 486 running Interactive Unix 2.2.1, using GNU make 3.62.
I doubt it's system-dependent, though.

Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: matherr not invoked for sqrt domain errors (GCC 2.3.1, sparc)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 01:17:46 GMT

The GCC manual says that TARGET_EDOM should not be defined if mathematical
functions on your system use `matherr' when there is an error.  The
mathematical functions in SunOS 4.1.2 (sparc) use `matherr', but
config/sparc.h defines TARGET_EDOM.  The following scenario illustrates the
discrepancy that this causes.

	$ cat t.c
	#include <math.h>
	int matherr (e) struct exception *e;  {
		printf("matherr invoked from %s\n", e->name);
		return 1;
	}
	main() {
		printf("sqrt(-1) == %g\n", sqrt(-1.0));
		return 0;
	}
	$ cc -O t.c -lm
	$ ./a.out
	matherr invoked from sqrt
	sqrt(-1) == NaN
	$ gcc -O t.c -lm
	$ ./a.out
	sqrt(-1) == NaN

The two outputs should be identical, but GCC's a.out doesn't invoke matherr so
the message is not printed.

Here is a patch.

Fri Nov  6 00:41:53 1992  Paul Eggert  (eggert@twinsun.com)

	* sparc.h (TARGET_EDOM, GEN_ERRNO_RTX): Removed, since Sun's
	math library invokes matherr.

===================================================================
RCS file: config/sparc.h,v
retrieving revision 2.3
retrieving revision 2.3.1.1
diff -c -r2.3 -r2.3.1.1
*** config/sparc.h	1992/10/20 21:12:29	2.3
--- config/sparc.h	1992/11/06 00:41:53	2.3.1.1
***************
*** 1277,1290 ****
     in one reasonably fast instruction.  */
  #define MOVE_MAX 8
  
- /* This is the value of the error code EDOM for this machine,
-    used by the sqrt instruction.  */
- #define TARGET_EDOM 33
- 
- /* This is how to refer to the variable errno.  */
- #define GEN_ERRNO_RTX \
-   gen_rtx (MEM, SImode, gen_rtx (SYMBOL_REF, Pmode, "errno"))
- 
  /* Define if normal loads of shorter-than-word items from memory clears
     the rest of the bigs in the register.  */
  #define BYTE_LOADS_ZERO_EXTEND
--- 1277,1282 ----

Newsgroups: gnu.gcc.bug
From: jbg@qualcomm.com (Jeff Gehlhaar)
Subject: Gcc loop-unroll bug...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 05:31:34 GMT

gcc version 2.3.1, SunOS 4.1.1 Sparc machine

// This is a program that causes G++ to commit suicide.
// Don't ask me why all of this seems necessary to tickle the bug,
// but removing anything causes a successful compile.

#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");
}

// When compiled with:
//      g++ -v -c -O -g -funroll-loops -Wshadow bug6.cc
// it procduces:
//      Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.1/specs
//      gcc version 2.3.1
//      /usr/local/lib/g++-include/streambuf.h: In method `ios::ios (struct
streambuf* (=  0 ), class ostream* (=  0 ))':
//      In file included from /usr/local/lib/g++-include/iostream.h:25,
from bug6.cc:5:
//      /usr/local/lib/g++-include/streambuf.h:436: warning: declaration of
`tie' shadows a member of `this'
//      /usr/local/bin/gcc: Internal compiler error: program cc1plus got
fatal signal 11


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


Newsgroups: gnu.gcc.bug
From: TRANLE@intellicorp.com (Minh Tran-Le)
Subject: gcc-2.3.1: on rs6000 aix 3.2.x gcc should define _AIX32
Reply-To: tranle@intellicorp.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 16:05:50 GMT

On the rs6000 under aix 3.2.x the standard compiler cc predefine _AIX32.

Here is my changes to the file config/rs6000.h.

Minh Tran-Le.

*** rs6000.h-	Sat Oct 24 18:03:46 1992
--- rs6000.h	Sun Nov  1 11:47:37 1992
***************
*** 25,31 ****
--- 25,35 ----
  
  /* Names to predefine in the preprocessor for this target machine.  */
  
+ #ifdef _AIX32
+ #define CPP_PREDEFINES "-D_IBMR2 -D_AIX -D_AIX32"
+ #else
  #define CPP_PREDEFINES "-D_IBMR2 -D_AIX"
+ #endif /* _AIX32 */
  
  /* Print subsidiary information on the compiler version in use.  */
  #define TARGET_VERSION ;
-------

Newsgroups: gnu.gcc.bug
From: chucks@orl.mmc.COM (Malcolm C. Strickland)
Subject: bug in gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 06:19:45 GMT

 I built and installed gcc 2.3.1 this weekend. it was built initialilly
 using gcc 2.2.2. I am running sun os 4.1.2 on sun4c architecture.

 when attempting to build mit X distribution I get the following error.

 % gcc -fpcc-struct-return -c -I/pub/X11R5/include -DSUNSHLIB -DSHAREDCODE -v -f
pic -O2 Context.c
Reading specs from /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/2.3.1/specs
gcc version 2.3.1
 /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/2.3.1/cpp -lang-c -v -DSUNSHLIB -DSHAREDCODE -I/pub/X11R5/include -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -D__OPTIMIZE__ Context.c /tmp/cca29443.i
GNU CPP version 2.3.1 (sparc)
 /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/2.3.1/cc1 /tmp/cca29443.i -quiet -dumpbase Context.c -O2 -version -fpcc-struct-return -fpic -o /tmp/cca29443.s
GNU C version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
gcc: Internal compiler error: program cc1 got fatal signal 6


 this is on file mit/lib/X/Context.c

 if you remove the -fpic options it works with no problems but does not
 produce position independent code.


 the mit X code is x11R5 pl 17.

 this fails on only some modules.

 passwed:
 lib/Xmu/AllCmap.c lib/Xaw/AllWidgets.c

 failed:
  lib/XtActionHook.c  lib/Xmu/Atoms.c  lib/oldXXDraw.c


 I will continue to try and isolate what is causing the failure, am hoping
 this is a known error.



*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*
Malcolm C. Strickland                 Martin Marietta Missile Systems
chuck-strickland@orl.mmc.com          mail point 170    
Phone: 407-356-7437                   pobox 555837
Fax:   407-356-5482                   orlando florida 32855-5837
*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*


Newsgroups: gnu.gcc.bug
From: pozo@cs.utk.edu
Subject: .i files from C++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 08:42:16 GMT

After reading the man page for gcc/g++, I'm still not sure how to see
the intermediate C code from g++.  What flag do I specify on the 
command line? 

Thanks for any info,
Roldan

Newsgroups: gnu.gcc.bug
From: iwj@cam-orl.co.UK (Ian Jackson)
Subject: 2.3.1: make install ignores LANGUAGES=c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 13:49:50 GMT

When typing make install LANGUAGES=c the generated makefile tries to
install the C++ files as well, so (if you haven't compiled them) it
starts to try to build them first !

leek:gcc-2.3.1> make install LANGUAGES=c
if [ -d /project/atmos/target/arm ] ; then true ; else mkdir /project/atmos/target/arm ; fi
cc -c -DCROSS_COMPILE -DIN_GCC   -g     -I. -I. -I./config \
  `echo ./cp-parse.c | sed 's,^\./,,'`
 ... etc.

Also, the file cp-parse.y in the distribution is more recent than the
.h and .c files so it has to be bisonned before the build can start. I
don't know whether that's intentional or not; I would have thought
that pre-bisonning it for the users would be worthwhile.

Ian Jackson.
Ian Jackson  iwj@cam-orl.co.uk ..!uknet!cam-orl!iwj  These opinions are my own.
Olivetti Research Ltd, Old Addenbrookes Site, Trumpington St, Cambridge, UK;
Home: 35 Molewood Close, Cambridge, CB4 3SR; +44 223 327029.     +44 223 343398

Newsgroups: gnu.gcc.bug
From: brendan@cygnus.com (Brendan Kehoe)
Subject: .i files from C++
Reply-To: brendan@cygnus.com (Brendan Kehoe)
Organization: Gnus Not Usenet
Distribution: gnu
Date: Fri, 13 Nov 1992 01:15:41 GMT

> After reading the man page for gcc/g++, I'm still not sure how to see
> the intermediate C code from g++.  What flag do I specify on the 
> command line? 

There is no intermediate C code, because g++ is a native compiler.
That is, it generates assembly directly from the C++ program, without
acting as a "translator" to convert the C++ into C.

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Mountain View, CA                              +1 415 903 1400
                                                             His name's Avery!

Newsgroups: gnu.gcc.bug
From: mob@think.com (Mario O. Bourgoin)
Subject: Internal compilation error while using asm.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 18:45:28 GMT

While compiling:

  test ()
  {
    asm volatile ("fubar %0"  :: "irf" ((float) 3.1));
  }

I get:

  % gcc -v -c test.c
  gcc -v -c test.c
  Reading specs from /usr/local/lib/gcc-lib/sun4/2.2.2/specs
  gcc version 2.2.2
   /usr/local/lib/gcc-lib/sun4/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix test.c /usr/tmp/cca07951.i
  GNU CPP version 2.2.2 (sparc)
   /usr/local/lib/gcc-lib/sun4/2.2.2/cc1 /usr/tmp/cca07951.i -quiet -dumpbase test.c -version -o /usr/tmp/cca07951.s
  GNU C version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
  gcc: Internal compiler error: program cc1 got fatal signal 6

The preprocessor output is:

% gcc -v -E test.c
gcc -v -E test.c
Reading specs from /usr/local/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sun4/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix test.c
GNU CPP version 2.2.2 (sparc)
# 1 "test.c"
test ()
{
  asm volatile ("fubar %0"  :: "irf" ((float) 3.1));
}

I am using:

  SunOS Release 4.1.2 (CMSTANDARD) #3: CMOST Version 7.2 8.21: Fri Aug 21 11:36:56 EDT 1992

--Mario


Newsgroups: gnu.gcc.bug
From: linstee@dutecaj.et.tudelft.nl (Erik van Linstee)
Subject: memcmp reverses return value
Organization: Delft University of Technology, Dept. of Electrical Engineering
Distribution: gnu
Date: Thu, 12 Nov 1992 10:57:14 GMT

Has this been mentioned or noticed before? I just ran
into it when a program I got gave me wrong results
whereas the DOS version worked fine. I finally traced
it to memcmp, which returns -1 instead of 1 and vice
versa.

Erik



-- 
Erik van Linstee   |   Delft University of Technology   |   I'll be back ... 
----
   We are god, 'cause only we can create the idea of his existence
   in our holy brains...  (Yello)


Newsgroups: gnu.gcc.bug
From: chucks@orl.mmc.COM (Malcolm C. Strickland)
Subject: followup to bug in gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 12:07:39 GMT

 after futher playing I go the routine down to:


extern void _XFreeContextDB();

void testsub(
   )
{
int test;
         test = (int)_XFreeContextDB;
}


 this produces an internal compiler error.

 I derived this from mit/lib/X/Context.c source file.

gcc -v -c -fpic testit.c
Reading specs from /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/2.3.1/specs
gcc version 2.3.1
 /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/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 testit.c /tmp/cca06496.i
GNU CPP version 2.3.1 (sparc)
 /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/2.3.1/cc1 /tmp/cca06496.i -quiet -dumpbase testit.c -version -fpic -o /tmp/cca06496.s
GNU C version 2.3.1 (sparc) compiled by GNU C version 2.3.1.
gcc: Internal compiler error: program cc1 got fatal signal 6

 I compiled against gcc 2.2.2 and got
% gcc -v -c -fpic  testit.c
Reading specs from /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/2.2.2/specs
gcc version 2.2.2
 /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix testit.c /tmp/cca05997.i
GNU CPP version 2.2.2 (sparc)
 /pub/local/gnu/lib/gcc-lib/sparc-sun-sunos412/2.2.2/cc1 /tmp/cca05997.i -quiet -dumpbase testit.c -version -fpic -o /tmp/cca05997.s
GNU C version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
testit.c:1: `IPFOR' undeclared, outside of functions


*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*
Malcolm C. Strickland                 Martin Marietta Missile Systems
chuck-strickland@orl.mmc.com          mail point 170    
Phone: 407-356-7437                   pobox 555837
Fax:   407-356-5482                   orlando florida 32855-5837
*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*


Newsgroups: gnu.gcc.bug
From: lindholm@ucs.ubc.CA (George Lindholm)
Subject: Re: gcc-2.3.1 breaks oleo-1.0
Organization: University Computing Services, UBC, Canada
Distribution: gnu
Date: Mon, 9 Nov 1992 19:17:12 GMT

In article <9211070046.AA09089@slug.unidesk.com>, sacco@mga.COM (Joseph E. Sacco) writes:
> Tried to build oleo-1.0 using gcc-2.3.1 on a SUN IPX running OS-4.1.3.
...
>  as -o io_utils.o /usr/tmp/cca12771.s
> as: "/usr/tmp/cca12771.s", line 111: error: location counter not on word boundary

The problem is that oleo assumes that if you are using gcc to compile the
source, you are also using gas as the assembler. You can either install
gas in the gcc tree or rip out the "asm" statements in io_utils.c.

-- 
George Lindholm                                  phone:    (604) 822-4375
University Computing Services, UBC               fax:      (604) 822-5116
6356 Agricultural Road, Vancouver, B.C., Canada  internet: lindholm@ucs.ubc.ca
V6T 1Z2                                          bitnet:   USERGNL@UBCMTSG


Newsgroups: gnu.gcc.bug
From: kivinen@joker.cs.hut.fi (Tero Kivinen)
Subject: extra warnings when using -Wshadow
Organization: Helsinki University of Technology/Centre for Continuing Education
Distribution: gnu
Date: Thu, 5 Nov 1992 19:07:56 GMT

I think gcc shouldn't complain about this:

~>cat foo.c
void f(int foo, void (*g)(int foo));
~>gcc2 -Wshadow -c foo.c 
foo.c:1: warning: declaration of `foo' shadows a parameter
~>gcc2 -v  
Reading specs from /p/gnu/lib/gcc-lib/sparc-sun-sunos4/2.3.1/specs
gcc version 2.3.1
--
Tero_Kivinen@hut.FI              Work : +358-0-451 4032
Klovinrinne 6b, 02180, Espoo     Home : +358-0-524 207

Newsgroups: gnu.gcc.bug
From: logan@penril.COM (James Logan)
Subject: segmentation violation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 4 Nov 1992 18:47:41 GMT

I got the following message from the compiler while building
with the stage1 compiler for GCC 2.3.1 on a Sun SPARC running
4.1.1:

	make: Fatal error: Command failed for target `cp-parse.c'
	expect 30 shift/reduce conflicts and 14 reduce/reduce conflicts
	cd .; bison  -d -o cp-parse.c cp-parse.y
	sh: bison: not found
	*** Error code 1

I then touched cp-parse.c and cp-parse.h and tried again:

	make: Fatal error: Command failed for target `cp-parse.c'
	stage1/xgcc -Bstage1/ -c  -DIN_GCC   -g -O     -I. -I. -I./config
	\
	`echo ./cp-parse.c | sed 's,^\./,,'`
	stage1/xgcc: Internal compiler error: program cc1 got fatal
	signal 11
	*** Error code 1
	make: Fatal error: Command failed for target `cp-parse.o'

I will try to build the stage1 compiler with version 1.36 of GCC
rather than with CC in the meanwhile.  


-- 
Jim Logan                  WORK: logan@penril.com
Penril Datacomm Networks   HOME: logan@gimlet.herndon.va.us

Newsgroups: gnu.gcc.bug
From: marvinw@intrepid18.wv.tek.COM
Subject: another gcc-2.3.1 -msoft-float bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 23:46:52 GMT

There is a small C program included in the script below which illustrates
the problem.  The compiler, cc1, core dumps!

		Marvin Wyckoff
		Tektronix, Inc.
		503-685-2985

---------------------------------------------------------------------------
Script started on Tue Nov 10 15:42:50 1992

[ent] cat config.status
#!/bin/sh
# GCC was configured as follows:
../configure --host=mips --target=mips-mips-bsd
echo host=mips-mips-none target=mips-mips-bsd build=mips-mips-none
[ent] uname -a
enterprise enterprise 5.0 RISCos mips
[ent] cat bug.c
double          prev_err, err;
float          *src_pd, *src_cdf;
_CreateMHLut()
{
        *src_cdf++ = *src_pd++;
        prev_err = err;
}
[ent] mgcc -O2 -v -c -msoft-float bug.c
gcc version 2.3.1
 /big1/people/marvinw/nwd/tools/mips/lib/gcc-lib/mips-mips-bsd/2.3.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_BSD43 -D_mips -D_unix -D_host_mips -D_MIPSEB -D_R3000 -D_SYSTYPE_BSD43 -D__mips__ -D__unix__ -D__host_mips__ -D__MIPSEB__ -D__R3000__ -D__SYSTYPE_BSD43__ -D___mips__ -D___unix__ -D___host_mips__ -D___MIPSEB__ -D___R3000__ -D___SYSTYPE_BSD43__ -D__mips -D__unix -D__host_mips -D__MIPSEB -D__R3000 -D__SYSTYPE_BSD43 -D___mips -D___unix -D___host_mips -D___




MIPSEB -D___R3000 -D___SYSTYPE_BSD43 -D__OPTIMIZE__ -D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C bug.c /usr/tmp/cc016801.i
GNU CPP version 2.3.1 [AL 1.1, MM 28] RISC-OS BSD Mips
 /big1/people/marvinw/nwd/tools/mips/lib/gcc-lib/mips-mips-bsd/2.3.1/cc1 /usr/tmp/cc016801.i -mgpopt -quiet -dumpbase bug.c -msoft-float -O2 -version -o /usr/tmp/cc016801.s
GNU C version 2.3.1 [AL 1.1, MM 28] RISC-OS BSD Mips compiled by CC.
mgcc: Internal compiler error: program cc1 got fatal signal 4

Newsgroups: gnu.gcc.bug
From: marvinw@intrepid18.wv.tek.COM
Subject: yet another gcc-2.3.1 -msoft-float -O2 bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 19:51:11 GMT

There is a small C program included below which produces the problem.  The
compiler is aborting.

		Marvin Wyckoff
		Tektronix, Inc.
		503-685-2985
		marvinw@orca.wv.tek.com

---------------------------------------------------------------------------
Script started on Wed Nov 11 11:48:26 1992

[ent] cat config.status
#!/bin/sh
# GCC was configured as follows:
../configure --host=mips --target=mips-mips-bsd
echo host=mips-mips-none target=mips-mips-bsd build=mips-mips-none
[ent] uname -a
enterprise enterprise 5.0 RISCos mips
[ent] cat bug5.c
static int _CreateMHLut(hshape, param1, param2 )
int hshape;
float param1;
float param2;
{
    unsigned status;
    unsigned i,j,k;			 
    unsigned long *hist_ptr, *h_ptr;	 
    unsigned long hist_cnt;		 
    double fmax, prev_err, err;		 
    unsigned long total_pixels;		 
    float *src_pd_base, *src_pd;	 
    float *src_cdf_base, *src_cdf;	 
    float *src_map_base, *src_map;	 
    float *dst_cdf_base, *dst_cdf;	 
    unsigned long *remap_base, *remap;	 
    for( i = 0; i < hist_cnt; i++ )
	*src_pd++ = (float)(*h_ptr++) / (float)total_pixels;
    src_pd  = (float *)src_pd_base;
    src_cdf = (float *)src_cdf_base;
    *(int *)src_cdf++ = *(int *)src_pd++;
    for( i = 1; i < hist_cnt; i++, src_cdf++ )
	*src_cdf = *(src_cdf-1) + *src_pd++;
    src_cdf = (float *)src_cdf_base;
    fmax = (float) (hist_cnt - 1);		 
	remap = remap_base;
	for( k = 0, i= 0; i < hist_cnt; i++, src_cdf++ )
	    {
	    for( prev_err = 1.0,j = k; j < hist_cnt; j++ )
		{
		err = (( (double)(((float)j / fmax) - *src_cdf)) > 0.0 ? ( (double)(((float)j / fmax) - *src_cdf)) : -( (double)(((float)j / fmax) - *src_cdf)))	;
		if( err == 0.0 )
		    {
		    j++;
		    break;
		    }
		else if( err > prev_err )
		    break;
		else
		    prev_err = err;
		}
	    *remap++ = j - 1;
	    k = j - 1;				     
	    }
}
[ent] /big1/people/marvinw/nwd/tools/mips/bin/mgcc -msoft-float -O2 -v -c bug5.c
gcc version 2.3.1
 /big1/people/marvinw/nwd/tools/mips/lib/gcc-lib/mips-mips-bsd/2.3.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_BSD43 -D_mips -D_unix -D_host_mips -D_MIPSEB -D_R3000 -D_SYSTYPE_BSD43 -D__mips__ -D__unix__ -D__host_mips__ -D__MIPSEB__ -D__R3000__ -D__SYSTYPE_BSD43__ -D___mips__ -D___unix__ -D___host_mips__ -D___MIPSEB__ -D___R3000__ -D___SYSTYPE_BSD43__ -D__mips -D__unix -D__host_mips -D__MIPSEB -D__R3000 -D__SYSTYPE_BSD43 -D___mips -D___unix -D___host_mips -D___




MIPSEB -D___R3000 -D___SYSTYPE_BSD43 -D__OPTIMIZE__ -D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C bug5.c /usr/tmp/cc019444.i
GNU CPP version 2.3.1 [AL 1.1, MM 28] RISC-OS BSD Mips
 /big1/people/marvinw/nwd/tools/mips/lib/gcc-lib/mips-mips-bsd/2.3.1/cc1 /usr/tmp/cc019444.i -mgpopt -quiet -dumpbase bug5.c -msoft-float -O2 -version -o /usr/tmp/cc019444.s
GNU C version 2.3.1 [AL 1.1, MM 28] RISC-OS BSD Mips compiled by CC.
/big1/people/marvinw/nwd/tools/mips/bin/mgcc: Internal compiler error: program cc1 got fatal signal 4

Newsgroups: gnu.gcc.bug
From: rec@aim.COM (Bob Cousins)
Subject: gcc 2.3.1 on Esix 5.3.2 Rev D
Summary: Strange FP problem compiling enquire.c
Organization: /usr/lib/news/organization
Distribution: gnu
Date: Thu, 12 Nov 1992 17:12:42 GMT

I've got a 386 machine running ESIX 5.3.2 rev D (beta) and
I'm trying to install gcc 2.3.1 on it. I've found three problems:

1.	The linker blows up trying to link the compiler. I've
	successfully worked around this problem by incrementally
	linking the files (ld -r). I believe that the linker
	has an unreasonably small limit on the number of symbols.

2.	Incrementally linking ran me out of free disk space on
	that filesystem so I hacked the Makefile to put the
	intermediate links into /tmp. (I suggest that the 
	configure script be modified to include 1 and 2 on
	small machines such as mine.)

3.	xgcc blows up with a floating point trap when trying to
	compile enquire.c. A bit of debugging has shown that
	the trap occurs when the FP trap handler is installed,
	but has been told to call abort(). Crowbaring the code
	to clean up has been useless--the system just keeps
	having the problem until it eventually goes crazy and
	dumps core for some other reason.

I hope #1 & #2 are helpful to some people.

I hope someone can point to what I'm doing wrong for #3.

BTW: I used configure to select i386-sysv. I'm not using
gas or the other gnu tools.

I realize that this installation would be much easier using
V.4, but I called ESIX and was told that they wanted about $1500
to upgrade to V.4. Since this is approximately 5 times what I
paid for ESIX, I don't think that I can afford it. Any suggestions
about a reasonable alternative would be appreciated.

-- 
________________________________________________________________________________
Robert Cousins                    rec@aim.com                  (408)748-8649x212
Aim Technology                                        Speaking for myself alone.

Newsgroups: gnu.gcc.bug