HDTenEightyP/NetNews huggingface dataset:
From: rusty@groan.berkeley.edu (Rusty Wright)
Subject: gcc 2.1; request, not a bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 12 Apr 1992 03:42:30 GMT

When doing an install, the Makefile puts libgcc.a into $(libsubdir).
It would be nice if it would also create a link in $(libdir) to
$(libsubdir)/libgcc.a; i.e., add to the Makefile the 2 lines flagged
with a +.

The reason for this is when you make emacs with gcc, it needs -lgcc
during the linking phase.  On machines where the linker accepts the -L
flag, it would be nice to be able to fix my Makefile to use -L with
$(libdir) and forget it.  But with libgcc.a in $(libsubdir) I have to
remember to update my emacs Makefile whenever I install a new version
of gcc since $(libsubdir) has the version number in it.  In other
words, I don't want to have to keep updating my emacs Makefile to
incorporate the new gcc version number where libgcc.a is.


install-libgcc: libgcc.a
	-if [ -f libgcc.a ] ; then \
	  rm -f $(libsubdir)/libgcc.a; \
+	  rm -f $(libdir)/libgcc.a; \
+	  $(SYMLINK) $(libsubdir)/libgcc.a $(libdir)/libgcc.a \
	  $(INSTALL_DATA) libgcc.a $(libsubdir)/libgcc.a; \
	  if $(RANLIB_TEST) ; then \
	    (cd $(libsubdir); $(RANLIB) libgcc.a); else true; fi; \
	  chmod a-x $(libsubdir)/libgcc.a; \
	else true; fi

Newsgroups: gnu.gcc.bug
From: marby@laura.harvard.edu (Craig Marby)
Subject: Incorrect warning 'value computed is not used' generated by GCC 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 09:40:55 GMT

Hi,

The following program

main()
{
   int i = 0;
   int *ptr_i;

   ptr_i = &i;

   *ptr_i++;
   *ptr_i = *ptr_i + 1;

   return 0;
}

when compiled by gcc version 2.0 using

gcc -Wall bug.c

generates the following warning

bug.c:8: warning: value computed is not used

this refers to *ptr_i++, which is synonymous with *ptr_i = *ptr_i + 1.
Generating such a warning for *ptr_++ is incorrect.

Craig Marby
marby@layla.harvard.edu



Newsgroups: gnu.gcc.bug
From: brian@gothamcity.jsc.nasa.gov (Brian Donnell [PT4])
Subject: GCC 2.1 Optimizer Bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 19:20:02 GMT

The program below when compiled with the command:

gcc -o foo -O foo.c

generates the following output on a Sun/Sparc with SunOS 4.1.1
(I am using GCC 2.1)

8941 837 1013
1903521977 768 1013
1903521766 557 1013
1886547925 544 1013

When compiled without the -O option, it generates the correct output:

1903521977 768 1013
1903521977 768 1013
1903521766 557 1013
1886547925 544 1013


Brian Donnell
NASA/JSC

File foo.c contents:

#include <stdio.h>

void main(void);
static int HashSymbol(char *,int);

void main()
  {
   HashSymbol("quoxnar",1013);
   HashSymbol("quoxnar",1013);
   HashSymbol("progn",1013);
   HashSymbol("progn",1013);
  }

static int HashSymbol(word,range)
  char *word;
  int range;
  {
   register int k,j,i;
   register int length;
   int tally;
   unsigned long count = 0L,tmpLong;
   char *tmpPtr;

   tmpPtr = (char *) &tmpLong;
   for (length = 0; word[length]; length++);
   length = length / sizeof(unsigned long);

   for (i = 0 , j = 0 ; i < length; i++)
     {
      for (k = 0 ; k < sizeof(unsigned long) ; k++ , j++)
        tmpPtr[k] = word[j];
      count += tmpLong;
     }
   for (word = (char *) &word[j]; *word; word++) count += (unsigned long) *word;
   tally = (int) (count % range);
printf("%lu %d %d\n",count,tally,range);
   if (tally < 0) return(-tally);
   return(tally);
  }

Newsgroups: gnu.gcc.bug
From: Bruce_Martin@next.com
Subject: Re: GCC 2.1 codegen bug when function is declared volatile
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 16:21:30 GMT

I reported:

> Gcc Version: 2.1
> Configuration: i386-mach
> Reported by: Bruce Martin (Bruce_Martin@NeXT.COM)
> 

> Description: if a function is declared volatile, gcc 2.1 produces
> completely bogus code when the optimizer is used.  I'm not at all
> sure what the correct response to the following C code should be,
> but the current behavior is definitely wrong (I'm assuming that
> the lack of any error messages means that the compiler should
> succeed in the compilation).


this is not a bug.  I mis-read the GCC documentation.  Sorry for the
false alarm.

				...bruce

Newsgroups: gnu.gcc.bug
From: chip@tct.COM (Chip Salzenberg)
Subject: Re: DON'T USE FIX FOR: optimization bug
Organization: TC Telemanagement, Clearwater, FL
Distribution: gnu
Date: Mon, 13 Apr 1992 13:11:00 GMT

In an earlier message to bug-gcc, I wrote:
>The below patch makes GCC generate and retain the correct machine
>modes for constants.

To quote Richard Kenner: "Your fix is nonsense."
To quote RMS: "A CONST_INT without VOIDmode?!  You've got to be kidding!"

So I guess you shouldn't use my patch.  Sorry about that.
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
      "Informix 4GL is not a 4G, and it's barely an L."  -- John Tombs

Newsgroups: gnu.gcc.bug
From: doug@foxtrot.ccmrc.ucsb.edu (Douglas Scott)
Subject: Re:  gcc 2.1 spurious warning for "-Wno-import" -- second part to patch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 16:10:45 GMT

I forgot that there are two parts to this patch.  Here is the part that fixes the same bug  
in the g++ portion of the compiler (the objc part is fixed my the gcc fix).

*** cp-decl2.c.orig	Wed Apr 15 14:12:01 1992
--- cp-decl2.c	Wed Apr 15 14:13:12 1992
***************
*** 448,453 ****
--- 448,455 ----
  	;			/* cpp handles this one.  */
        else if (!strcmp (p, "trigraphs"))
  	;			/* cpp handles this one.  */
+       else if (!strcmp (p, "import"))
+ 	;			/* cpp handles this one.  */
        else if (!strcmp (p, "all"))
  	{
  	  extra_warnings = setting;

---
Douglas Scott                              (805)893-8352
Center for Computer Music Research and Composition
University of California, Santa Barbara
Internet: (NeXTMail ok)   <doug@foxtrot.ccmrc.ucsb.edu>

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  GCC (C++) 2.01 - additional info
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 22:16:02 GMT

This is not a problem with gcc, but rather g++, so the report should not
go to the bug-gcc list, but rather the 
	bug-g++@prep.ai.mit.edu
list.

I will answer for now anyways, the problem has been fixed, the next release
of gcc should be better.

> Date: Tue, 14 Apr 92 13:21:55 EDT
> From: keith@thinkage.on.ca (Keith Dorken)
> Message-Id: <9204141721.AA13968@sabre.Thinkage.On.CA>
> To: bug-gcc@prep.ai.mit.edu
> Subject: GCC (C++) 2.01 - additional info
> Resent-From: bug-gcc-request@prep.ai.mit.edu

> The bug in GCC that causes the compiler to go into an infinite loop
> during parsing has been isolated even further in the following
> (smaller!) sample code.  You can eliminate any one section of the
> code surrounded by BUG, BUG1 or BUG2, and the parsing problem goes
> away. Any known fixes would be appreciated..

> This is the .h header file. To reproduce, put everything below
> "SAMPLE" into a bug.h file, create a bug.cc file with '#include
> "bug.h"' in it, and compile with c++ -c bug.cc

> This problem is for the compiler identified by 
> Reading specs from /n/server/usr/local/languages/gnu-compilers/lib/gcc-lib/sun4os4/2.1/specs
> gcc version 2.1
>  /n/server/usr/local/languages/gnu-compilers/lib/gcc-lib/sun4os4/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 junk.cc /usr/tmp/cca13962.i
> GNU CPP version 2.1 (sparc)

> ---------- SAMPLE ----------
> #define BUG		// remove either BUG
> #define BUG1	// or BUG1 
> #define BUG2	// or BUG2 and the parsing problem goes away.
> class Unsigned36
> {
> protected:
>   char*	rep;

> public:
> 	Unsigned36();
> #ifdef BUG2
> 	Unsigned36(int);
> #endif
> 	operator int();
> #ifdef BUG
>    friend
> #endif
>  int	operator == (const Unsigned36&, const Unsigned36&);
> };

> int operator ! (const Unsigned36& x);

> inline Unsigned36::Unsigned36() : rep( (char *)0 )
>   {
>   }
> inline unsigned int Unsigned36::operator int()
>   {
> 	return ( rep[0] );
>   }
> inline int operator ! ( Unsigned36& x )
>   {
> #ifdef BUG1
> 	return( x == 0 );
> #endif
>   }














Newsgroups: gnu.gcc.bug
From: erich@microsoft.com
Subject: typo in cpp.info
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 21:14:31 GMT

I'm sorry, but I don't know which version of cpp.info I have, although
I think it's recent -- I picked it up off of prep within the last month
or so.  Anyway... there's a sentence that goes like this:
	`#include' is obsolete becuase it is not a well-designed feature.
	It requires the users of a header file--the applications
I think RMS meant to say that `#import' is obsolete, not `#include'.

Thanks



Newsgroups: gnu.gcc.bug
From: bjork@napa.telebit.com
Subject: gcc 2.1, sun2, sunos 4.0.3 build report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 12 Apr 1992 10:03:28 GMT

On sun2, sunos 4.0.3 cc, compile fails:
"recog.c", line 1684: compiler error: expression causes compiler loop:
try simplifying

Compiled with gcc 1.39 built on sunos 3.4, compile succeeded.
Then, added gcc 1.39 gcc-gnulib to link list for stage1 link.

This allowed stage1 to successfully complete.

Full stage2 then worked.

Attempts to gcc 2.1 compile (something) that included netinet/ip.h
resulted in error of unlabeled union. Add to union definition on
line 81: ipt_timestamp

Next step, attempt R4 build with gcc 2.1 on sun2 sunos 4.0.3 host.

Steven

11 apr 1992

Newsgroups: gnu.gcc.bug
From: jpr@jpradley.JPr.COM (Jean-Pierre Radley)
Subject: Re: GCC 2.1 on SCO Unix 3.2.4
Keywords: gcc sco bug
Organization: Unix in NYC
Distribution: gnu
Date: Mon, 6 Apr 1992 23:02:53 GMT

In article <15kjky=.maw@netcom.com> maw@netcom.com (Martin Walker) writes:
>Hello all.
>When compiling GCC 2.1 on SCO Unix 3.2.4, using the development system
>version 3.2.4, the "%s" at the end of crtend.o in the ENDFILE_SPEC
>fails to get expanded. The upshot is that GCC never finds crtend.o when 
>linking.

The SCO 3.2v4 Development System is available? My sources don't have it.
-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160,1341


Newsgroups: gnu.gcc.bug
From: chip@tct.COM (Chip Salzenberg)
Subject: FIX FOR: optimization bug
Organization: TC Telemanagement, Clearwater, FL
Distribution: gnu
Date: Fri, 10 Apr 1992 13:31:00 GMT

A bug report from James Clark <jjc@jclark.com> reports that GCC 2.1
misoptimizes this program:
	main()
	{
	  signed char c = -1;
	  printf("%d\n", c < 0);
	  exit(0);
	}
It prints zero instead of one.

I've found this bug.  The optimizer is noting that "c" equals 0xFF,
but it is forgetting that 0xFF is a _byte_ value (QImode).  So when
the optimizer SIGN_EXTENDs that constant, the constant looks like it
has already been extended.  This bug results in a wrong value of 255
(which is, of course, not less than zero) instead of the correct -1.

The below patch makes GCC generate and retain the correct machine
modes for constants.

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

Thu Apr  9 17:22:19 1992  Chip Salzenberg  (chip at tct.com)

	* emit-rtl.c (gen_rtx): Generate CONST_INT with requested MODE.
	  (gen_lowpart_common): Ditto.

Index: emit-rtl.c
*************** gen_rtx (va_alist)
*** 257,260 ****
--- 257,261 ----
  
        rt_val = rtx_alloc (code);
+       rt_val->mode = mode;
        INTVAL (rt_val) = arg;
      }
*************** gen_lowpart_common (mode, x)
*** 533,537 ****
  	    : (GET_MODE_BITSIZE (mode) == HOST_BITS_PER_INT
  	       && GET_CODE (x) == CONST_INT) ? x
! 	    : gen_rtx (CONST_INT, VOIDmode,
  		       (GET_MODE_MASK (mode)
  			& (GET_CODE (x) == CONST_INT
--- 534,538 ----
  	    : (GET_MODE_BITSIZE (mode) == HOST_BITS_PER_INT
  	       && GET_CODE (x) == CONST_INT) ? x
! 	    : gen_rtx (CONST_INT, mode,
  		       (GET_MODE_MASK (mode)
  			& (GET_CODE (x) == CONST_INT
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
      "Informix 4GL is not a 4G, and it's barely an L."  -- John Tombs

Newsgroups: gnu.gcc.bug
From: stan@sabaac.mayo.edu
Subject: c++ template bugs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 07:19:32 GMT

The current version of gcc has partial support for template in c++
programs. Is there a developement group I could join and become a beta
site for the template development effort??

Andrew Staniszewski
Mayo Foundation
staniszewski@mayo.edu

Newsgroups: gnu.gcc.bug
From: djanecek%decserv2@dns1.eecs.wsu.edu
Subject: Problems Running gnu C++ 2.0 on dec3100 station
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 02:47:55 GMT

Hi!

I am running Ultrix 4.2 version on DEC3100 station. I think the administrator installed the 2.1 gnu CC version correctly.

I use the c++ macro to compile mi code.

I have a big problem with end of file. I have to put sometimes few lines, spaces, or comments to make it work. After that it compiles, strange right (space sensitive compiler). This is an error which I get: 
resource.h:3: parse error at null character

I am not a C++ expert but there were some more problems (am using the Borland's C++)

1. For class with internal variable array it would not initialize array (at all) unless I have defined an empty constructor

2. The iostreams are not very robust. When I have red the '#' character into the int space the program had crashed. I think it should set error bit flag on and ignore further reading!

3. When I was using inside the case statement #ifdef the compiler complains to error.


4. Doesn't let overload the Memory() and Memory(
char* ) constructor in Memory class. Could not specified in the parent class constructor which one to use.
Contrller():Memory(char fileName)
Is this feature supported.

5. I tried to read hex numbers using cin >> hex >> variable. I do the stuff in Borland's C++ and it is just fine. Maybe this is not implemented yet.


__DAVID

Newsgroups: gnu.gcc.bug
From: keith@thinkage.on.CA (Keith Dorken)
Subject: GCC (C++) 2.01 - additional info
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 17:21:55 GMT

The bug in GCC that causes the compiler to go into an infinite loop during parsing
has been isolated even further in the following (smaller!) sample code.
You can eliminate any one section of the code surrounded by BUG, BUG1 or BUG2,
and the parsing problem goes away. Any known fixes would be appreciated..

This is the .h header file. To reproduce, put everything below "SAMPLE" into a 
bug.h file, create a bug.cc file with '#include "bug.h"' in it, and compile with
c++ -c bug.cc

This problem is for the compiler identified by 
Reading specs from /n/server/usr/local/languages/gnu-compilers/lib/gcc-lib/sun4os4/2.1/specs
gcc version 2.1
 /n/server/usr/local/languages/gnu-compilers/lib/gcc-lib/sun4os4/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 junk.cc /usr/tmp/cca13962.i
GNU CPP version 2.1 (sparc)

---------- SAMPLE ----------
#define BUG		// remove either BUG
#define BUG1	// or BUG1 
#define BUG2	// or BUG2 and the parsing problem goes away.
class Unsigned36
{
protected:
  char*	rep;

public:
	Unsigned36();
#ifdef BUG2
	Unsigned36(int);
#endif
	operator int();
#ifdef BUG
   friend
#endif
 int	operator == (const Unsigned36&, const Unsigned36&);
};

int operator ! (const Unsigned36& x);

inline Unsigned36::Unsigned36() : rep( (char *)0 )
  {
  }
inline unsigned int Unsigned36::operator int()
  {
	return ( rep[0] );
  }
inline int operator ! ( Unsigned36& x )
  {
#ifdef BUG1
	return( x == 0 );
#endif
  }












Newsgroups: gnu.gcc.bug
From: hikichi@srarc2.sra.co.JP (Nobuyuki Hikichi)
Subject: gcc 2.1 bug? -mips2 -mcpu=r6000 with -O2
Reply-To: hikichi@sra.co.jp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 17 Apr 1992 07:42:03 GMT

I think code sequence from (A) to (B) in following script are
incorrect.

				Name: Nobuyuki Hikichi <hikichi@sra.co.jp>
			Office: Software Research Associates, Inc. Japan.

.........................start of script...............................
							#
							# Original gcc
							#
gnu@srarc2 $ cat ~gnu/src/gcc-2.1/config.status
#!/bin/sh
# GCC was configured as follows:
./configure mips-mips-bsd
gnu@srarc2 $ gcc -mcpu=r6000 -mips2 -c x.c -DTIME -c -O
as1: Warning: x.c, line 5: nop required			# warning.!!
		0x44900000	mtc1	$16,$f0
		0x46800020	cvt.s.w	$f0,$f0
gnu@srarc2 $ cat x.c
long            User_Time;
float           Dhrystones_Per_Second;

main ()
{
  int             Number_Of_Runs;

  if (User_Time < 120 )
  {
    printf ("\n");
  }
  else
  {
    Dhrystones_Per_Second = ((float) 60  * (float) Number_Of_Runs)
                        / (float) User_Time;
  }
}
gnu@srarc2 $ gcc -B./ -mcpu=r6000 -mips2 -c x.c -DTIME -S -O
gnu@srarc2 $ ed x.s
967
/mtc1/
	mtc1	$16,$f0
20,$p

	.comm	User_Time,8

	.comm	Dhrystones_Per_Second,8

	.text

	.loc	1 5
	.ent	main
main:
	subu	$sp,$sp,32		# vars= 0, regs= 2/0, args = 16, extra= 8
	.frame	$sp,32,$31
	.mask	0x80010000,-12
	.fmask	0x00000000,0
	sw	$31,20($sp)
	sw	$16,16($sp)
	jal	__main
	lw	$2,User_Time
	#nop
	.set	noreorder
	bgtl	$2,119,$L2
	.set	nomacro	
	mtc1	$16,$f0					# (A)
	cvt.s.w	$f0,$f0					# (B)
	.set	macro
	.set	reorder

	la	$4,$LC0
	jal	printf
	j	$L3
$L2:
	li.s	$f2,6.00000000000000000000e+01
	#nop
	mul.s	$f0,$f0,$f2
	lw	$2,User_Time
	#nop
	mtc1	$2,$f2
	cvt.s.w	$f2,$f2
	div.s	$f0,$f0,$f2
	s.s	$f0,Dhrystones_Per_Second
$L3:
	lw	$31,20($sp)
	lw	$16,16($sp)
	addu	$sp,$sp,32
	j	$31
	.end	main

Newsgroups: gnu.gcc.bug
From: hosking%ibis@cs.umass.edu (Tony Hosking)
Subject: Bug in gcc-2.1 for VAX
Reply-To: hosking@cs.umass.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 13:12:36 GMT

There seems to be a pattern missing from the vax.md machine description in
gcc-2.1 to dealing with indexed indirect jumps.  The program:

extern void *table[];

void try (int i) {
  goto *table[i];
}

gives the following error message when compiled with gcc-2.1 on a VAX running
Ultrix 4.1:

try.c: In function `test':
try.c:5: internal error--unrecognizable insn:
(jump_insn 8 7 9 (set (pc)
       (mem/s:SI (plus:SI (mult:SI (reg:SI 20)
                   (const_int 4))
               (symbol_ref:SI ("table"))))) -1 (nil)
   (nil))
gcc: Internal compiler error: program cc1 got fatal signal 4

I'd appreciate any help in updating the machine description.

Thanks,

		Tony Hosking
Papernet:	Dept. of Computer Science
		University of Massachusetts			 _--_|\
		Amherst, MA 01003				/      \
Voicenet:	(413) 545-0256					\_.--._/    )
Internet:	hosking@cs.umass.edu				      v    /

Newsgroups: gnu.gcc.bug
From: brannon@stun4b.cs.caltech.edu (Terrence M. Brannon)
Subject: only gcc produces __builtin_va_arg_incr error. Why?
Organization: Caltech Yoga Qi Gong Tai Chi
Distribution: gnu
Date: Wed, 15 Apr 1992 02:25:46 GMT

I am on a Sun4 running SunOs 4.0.1

I attempted to compile expect, a program to filter the input and
output of processes, and it worked fine with the Sun C compiler.

However, gcc produces the following error at link time:


ld.so: Undefined symbol: ___builtin_va_arg_incr



--
Terrence Brannon                              brannon@jove.cs.caltech.edu 
yoga . qi gong . tai chi . shamanism . primitive knowledge . neurobiology
Happiness!   Happiness!  Happiness!   Happiness!  Happiness!   Happiness!  
po box 5027		bethlehem, pa 18015 usa              215.758.1720


Newsgroups: gnu.gcc.bug
From: keith@thinkage.on.CA (Keith Dorken)
Subject: Re:  GCC (C++) 2.01 - additional info
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 12:26:09 GMT

I received a message containing a patch (a patch by Mike Tiemann) to fix this
problem. I haven't yet installed it, but it looks like the solution to my
problem.

The info file for GCC should be updated to indicate that bug reports for
G++ should be sent to bug-g++@... (is this correct)?) 

		[ yes -len, aka bug-gcc-request@prep.ai.mit.edu  ]

now that G++ is
integrated with GCC; i used the reporting method that came with the package
I was installing (GCC 2.01). I guess I should have realized it was wrong.
Thanks for the response.

Newsgroups: gnu.gcc.bug
From: TSAICH@ccvax.as.edu.tw
Subject: gcc-2.0 install problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 21:26:00 GMT

Dear Sir:
  I got an copy of GNU gcc-2.0 recentely, but when I try to install it on
an HP 9000/425t workstation which O.S. is HP-UX 8.0 , I got an problem
that I can't resolve it according to the installing text and Makefile 
descriptions . the error missage is " ./gcc : Internal compiler error: 
program as got fatal signal 11 ".
  I also install gcc-2.0 on sun sparc ,and Dec 5200 workstations, the 
installing process is fine but when I try to compile my c++ code with g++ ,
there are problems , it required libg++.a library which isn't produced in 
the installing process . I chech the Makefile to see how can produce libg++
.a ,but has not any informations about that. 

  I wish someone can help me to solve these problems.
Any messages about this ,I am appreciative .

                     Tsai C.H.    April 8 1992
                                     address:   tsaich@ccvax.cc.as.edu.tw


Newsgroups: gnu.gcc.bug
From: flur@eecom.gatech.edu (Peter W. Flur)
Subject: Re: gcc compiler bug ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 14:10:04 GMT

|->  From osborn@eecom.gatech.edu Tue Apr 14 09:00:15 1992
|->  Return-Path: <osborn@eecom.gatech.edu>
|->  Date: Tue, 14 Apr 1992 09:00:13 -0500
|->  To: help@eecom
|->  From: osborn@eecom.gatech.edu
|->  Subject: gcc compiler bug ?
|->  
|->  
|->  There appears to be a bug in the gcc compiler on the hp's.  (I have not
|->  tried the suns yet.)
|->  
|->  The following program shows that the absolute value function (fabs) does
|->  not except double precision variables, as the man pages indicate.
|->  
|->  #include <math.h>
|->  
|->  main(ac,av)
|->  int ac;
|->  char *av[];
|->  {
|->  
|->  double a,b;
|->  
|->  a = 1.7;
|->  b = 0.5;
|->  printf("x = %g\n",fabs(a-b));
|->  printf("x = %g\n",fabs((a-b)));
|->  printf("x = %g\n",fabs((double)(a-b)));
|->  printf("x = %g\n",fabs((float)(a-b)));
|->  printf("x = %g\n",fabs(a*b));
|->  }
|->  
|->  Who should this bug be reported to ??  
|->  
|->  Allan Osborn
|->  
|->  

Well, in playing around, I see that this is a bug with the optimization or
lack thereof.  If you use gcc -O, it compiles fine.

Newsgroups: gnu.gcc.bug
From: bobw@cc.usu.edu
Subject: gcc error when using dbx
Organization: Utah State University
Distribution: gnu
Date: Wed, 15 Apr 1992 21:32:06 GMT

We just compiled gcc version 2.1 on a SUN SPARC 1+ computer and noticed the
folowing problem when using dbx:

% dbx trans
Reading symbolic information...
dbx: internal error: unexpected value 38 at line 2620 in file ../common/object.c
%
The program will debug ok with gdb.
The program follows:

/* #define MAX 80  */
const int MAX = 80; 

main ( )
{
  char from[MAX];

} /* main */

An extremely simple program. If the define is uncommented and the const
commented the dbx is ok. Is this a problem with dbx or with gcc?
We use dbx instead of gdb because dbx allows strings to be printed during
debugging.

-- 
===============================================================================
Bob Wood    WA7MXZ                      bobw@cc.usu.edu
Utah State University                   bobw@usu.bitnet
Computer Science			tel. (801) 750-3205
UMC 4205				fax. (801) 750-3265
Logan, Utah  84322-4205
===============================================================================


Newsgroups: gnu.gcc.bug