HDTenEightyP/NetNews huggingface dataset:
From: sm@cvedc.prime.com
Subject: bug in old function definition/new function prototype
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 01:16:32 GMT

The following is correct code (according to 2nd edition K&R,pp. 202 & 197):

void foo(unsigned int, unsigned int, unsigned int, unsigned long);

void foo(uchar_error, ushort_error, uint_okay, ulong_okay)
unsigned char	uchar_error;
unsigned short	ushort_error;
unsigned int	uint_okay;
unsigned long	ulong_okay;
{
	return;
}

However, gcc generates an error message for "uchar_error" and "ushort_error".

Scott MacHaffie

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  gcc for Solaris 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 14:10:41 GMT

> Date: Fri, 28 Aug 92 10:59:49 EDT
> From: freeman@saul.cis.upenn.edu (Jon Freeman)
> Posted-Date: Fri, 28 Aug 92 10:59:49 EDT
> Message-Id: <9208281459.AA24224@saul.cis.upenn.edu>
> To: bug-gcc@prep.ai.mit.edu

> We've installed Solaris 2.0 on one of our Sparcstations and now
> we need a compiler (even though the folks at Sun apparently thought
> we wouldn't).  We have the source code for gcc, but we need a
> compiler to compile it (!).  So, does any kind soul out there have
> an executable for gcc 2.2.2 that we can ftp?  (Has gcc been ported
> to Solaris 2.0 yet?)

You will want to get the CD-ROM Catalyst disk.  It has gcc on it,
prebuild and tested, fully functional.

Newsgroups: gnu.gcc.bug
From: adachir@cuugnet.cuug.ab.ca (Rob Adachi 297-3607)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 21:40:31 GMT

>>| | I'm having problems getting gcc to compile under the new OS and am wondering
>>| | if anyone else has had success. Here is the error message:
>>| |
>>| |       [stuff deleted]
>>| |       ./gcc    -g -B./  enquire.o -o enquire
>>| |       ld:
>>| |       ABI incompatible stack frame instruction sequence in object enquire.o
>>| |       collect: /usr/bin/ld returned 1 exit status
>>| |       *** Error code 1
>>| |
>>| | Configure was run with mips-mips-sysv but I have the same problem with bsd
>>| | and svr4.
>>| 
>>| 
>>| Has a solution to this problem been found?  

>>I just put a fix into the GCC release.  If you are on the gcc2 alpha
>>list, it will appear in the next snapshot.  Otherwise, it will appear
>>in GCC 2.3.


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

Hi;
	We are having the same problem and I would like to get the fix
as soon as possible. Would it be possible for someone to send me the
fix? Or mail me some info on how to get the fix? 

Rob Adachi			internet: adachir@cuug.ab.ca
Calgary Alberta 
Canada

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Undefined assembler symbols in .o files
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 14:07:02 GMT

This is a bug in gcc 2.2.2, gcc 2.2.1 I believe did not have this
problem.  The next release of gcc should not have it either.

> To: bug-gcc@prep.ai.mit.edu
> Date: Thu, 27 Aug 92 15:26:01 +0100
> Message-Id: <3379.714925561@xtel.co.uk>
> From: Alan Shepherd <a.shepherd@xtel.co.uk>

> Quite a while ago I sent a message reporting undefined assembler
> symbols such as "L495" appearing in .o files.  I didn't receive any
> acknowledgement or see any answer or patch in the newsgroup, although
> I did see someone else reporting the same thing.

> output from gcc -v

> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.1/2.2.2/specs
> gcc version 2.2.2

> The problem seems to arise when using the -g flag and can be evidenced
> by compiling the lates version of libg++.a.  I can't remember which
> particular file other than it is one of the ones in iostream, but I
> did report it before.

Newsgroups: gnu.gcc.bug
From: jonathan@cs.keele.ac.UK (Jonathan Knight)
Subject: G++ 2.2.2 and floating point numbers
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 13:47:07 GMT

G++ 2.2.2
Gas 1.38.1
ld 1.9
libg++ 2.2

I'm having trouble with this program:

#include <fstream.h>
#include <stdlib.h>

int main()
{       float a;

        cin >> a;
        cout << a << "\n";
}

The output is always 0 regardless of what I put in.


-- 
  ______    JANET :jonathan@uk.ac.keele.cs     Jonathan Knight,
    /       BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
   / _   __ other :jonathan@cs.keele.ac.uk     University of Keele, Keele,
(_/ (_) / / UUCP  :...!uknet!kl-cs!jonathan    Staffordshire.  ST5 5BG.  U.K.

Newsgroups: gnu.gcc.bug
From: etxmesa@eos.ericsson.SE (Michael Salmon)
Subject: Re: Bug in cygnus 2.0.1 (2.1 and 2.2.2 of mainstream)
Reply-To: etxmesa@eos.ericsson.se (Michael Salmon)
Organization: Ericsson Telecom AB
Distribution: gnu
Date: Thu, 3 Sep 1992 07:47:01 GMT

In article <X3NgqB3w164w@kryton.UUCP>,
system@kryton.UUCP (Scott Beckstead) writes:
|> I am currently porting a cygnus version of gcc (gpp objc etc.) to a new system.
|> In my libraries (ansi) strcmp return -1 for less than, 1 for greater than and
|> 0 for equality.  The spec merely states negative for less than positive for greater
|> than and 0 for equal.  Yet in the file rtl.c There is a code fragment that 
|> looks like this 
|> 
|> 	if(!strcmp(somevalue,someothervalue))
|> 		someaction;
|> 
|> This seems like a particularly BAD idea considering the values returned by
|> this fully ansi compliant library (yes it does change the behavior of
|> the programs)  I have modified my library to fix this but the code
|> really should be fixed so that a unary not of a non boolean return
|> is not used as a boolean.  Because with the value -1 I'm sure you see the
|> problem.  (!(-1) is 0 but !(1) is -2 and !(0) is -1) 

I think that you are confusing ! with ~ as I hope that this shows.

 eos6c02 tmp 11 > cat testcode.c
#include <stdio.h>

int main()
{
    int i;

    for ( i = -1; i <= 1; ++i)
        printf( "!(%2d) == %2d, ~(%2d) == %2d.\n", i, !i, i, ~i);
    
    return 0;
}
 eos6c02 tmp 12 > testcode
!(-1) ==  0, ~(-1) ==  0.
!( 0) ==  1, ~( 0) == -1.
!( 1) ==  0, ~( 1) == -2.

In C, 0 is false everything else is true.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

Newsgroups: gnu.gcc.bug
From: tiemann@cygnus.com
Subject: Re: c-lex.c, init_lex(), magic number 40?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 02:15:07 GMT

   Return-Path: gnulists@ai.mit.edu
   Date: Wed, 2 Sep 92 14:42:15 GMT-0400
   From: gsk@marble.com
   Sender: gnulists@ai.mit.edu
   To: bug-gcc@prep.ai.mit.edu
   Subject: c-lex.c, init_lex(), magic number 40?
   
   
   
   I noticed that sizeof (struct lang_identifier) is 40, then I saw
   
     maxtoken = 40;
   
   and wondered if 40 was a "magic number".
   
Nope, sorry.  However, 42, 69, and 3 are magic numbers.  I suggest
playing them in the lottery today.

Michael

Newsgroups: gnu.gcc.bug
From: jon@halsp.hitachi.COM (Jonathan Ryshpan)
Subject: Specs file
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 28 Aug 1992 20:49:38 GMT

There isn't anything in the documentation (all the .texi files) about
the VERY interesting specs file or any of the local options which it 
creates.  On my system, which is:
	GNU C version 2.2.2 (80386, ATT syntax)
these include:
	-posix and -shlib, 

Many Thanks:

Jonathan Ryshpan		<...!uunet!hitachi!jon>

M/S 420				(415) 244-7369 
Hitachi America Ltd.
2000 Sierra Pt. Pkwy.
Brisbane CA 94005-1819

	===============> I write for myself ONLY. <===============


Newsgroups: gnu.gcc.bug
From: eggert@shadow.TWinsun.COM (Paul Eggert)
Subject: bug fix for my Aug 7 patch (GCC 2.2.2 does not warn about `1<=i<=N')
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 30 Aug 1992 00:07:57 GMT

On Aug 7 I submitted a patch to make GCC 2.2.2 warn about C expressions like
`1<=i<=N', which have a different meaning than in traditional mathematics.
Unfortunately, the patch has a bug that sometimes causes gcc -O -W to issue a
warning when it shouldn't.  For a program like

	struct tree_common
	{
	  int code : 8;
	  unsigned public_flag : 1;
	};
	static int
	gen_decl (decl)
	     struct tree_common *decl;
	{
	  if (( (decl)->code)  == 10 && !((decl)->public_flag) )
	    return 3;
	  return -2;
	}

GCC 2.2.2 (-O -W, sparc, SunOS 4.1.2, with my patch) wrongly complains:

	x.c:10: warning: comparisons like X<=Y<=Z do not have the usual meaning

Roughly speaking, the problem is that the patched GCC internally optimizes the
&& to an ==, and then wrongly complains about the transformed expression.

Here is a fix.  The c-typeck.c patch is with respect to GCC 2.2.2.  The
invoke.texi patch has not changed since Aug 7, but I'm including it to make
this report self-contained.

Sat Aug 29 23:55:12 1992  Paul Eggert  (eggert@twinsun.com)

	* c-typeck.c (parser_build_binary_op): Don't get confused by bit-field
	merging when warning about expressions like `1<=i<=N'.

Fri Aug  7 22:34:20 1992  Paul Eggert  (eggert@twinsun.com)

	* c-typeck.c (parser_build_binary_op): Warn about expressions like
	`1<=i<=N'.
	* invoke.texi: Document warning.

===================================================================
RCS file: c-typeck.c,v
retrieving revision 2.2
diff -c -r2.2 c-typeck.c
*** c-typeck.c	1992/05/28 05:20:58	2.2
--- c-typeck.c	1992/08/29 23:55:12
***************
*** 2128,2133 ****
--- 2128,2139 ----
  	}
      }
  
+   /* Similarly, check for cases like 1<=i<=10 that are probably errors.  */
+   if (extra_warnings
+       && TREE_CODE_CLASS (code) == '<'
+       && (TREE_CODE_CLASS (code1) == '<' || TREE_CODE_CLASS (code2) == '<'))
+     warning ("comparisons like X<=Y<=Z do not have the usual meaning");
+ 
    class = TREE_CODE_CLASS (TREE_CODE (result));
  
    /* Record the code that was specified in the source,
===================================================================
RCS file: invoke.texi,v
retrieving revision 2.2.2.1
diff -c2 -r2.2.2.1 invoke.texi
*** invoke.texi	1992/08/01 03:27:09	2.2.2.1
--- invoke.texi	1992/08/07 22:22:36
***************
*** 616,619 ****
--- 616,624 ----
  
  @item
+ A comparison like @samp{x<=y<=z} appears; this is equivalent to
+ @samp{(x<=y ? 1 : 0) <= z}, which is a different interpretation than
+ ordinary mathmatics.
+ 
+ @item
  A storage-class specifier like @code{static} appears other than
  at the beginning of a declaration.  According to the C Standard,

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  bug with iostream.h?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 14:25:17 GMT

I suspect this is a problem with libg++.

You need to report bugs or problems in libg++ to the
	bug-lib-g++@prep.ai.mit.edu list.

libg++-2.2 I believe corrects these problems.

> Date: Thu, 23 Jul 92 00:14:29 +0100
> From: jb145@eng.cam.ac.uk
> Message-Id: <9207222314.AA27182@caxton>
> To: bug-gcc@prep.ai.mit.edu

> #I've been having a very frustrating problem with iostream.h in gcc
> version 2.0(?).  I am running g++ on a Decstation mips machine.

> Is there any known bug in the compiler with respect to buffered input

> 	int from; cin >> from;

> then the program runs fine, looping forever without keyboard input.
> But when the line is left in, then it works fine for about 100 or 200
> inputs cycles until suddenly crashing with a message like:


> grow failed because stack limit exceeded, pid 26935, proc play
> ts = 0x1c, ds = 0x1d, ss = 0x80
> Segmentation fault (core dumped)


> I have been chasing this problem for over two weeks and am hoping,
> begging that you will have a clue what might be causing it.  By the
> way, I've tried lots of hacks such as replacing
> 		cin >> from;
> with
> 		char str[5]; cin >> str; from = atoi(str);

> but the crash remains despite all my efforts.

Newsgroups: gnu.gcc.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: GCC manual errors?
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 10:53:33 GMT

A few possible buglets in the GCC 2.2.2 manual:

Node: Incompatibilities

   * Programs that use preprocessor directives in the middle of macro
     arguments do not work with GNU CC.  For example, a program like
     this will not work:

          foobar (
          #define luser
                  hack)

I'm probably just being dense, but I don't understand this example.  Is
there supposed to be a `#define foobar(arg)' before this?


Node: Disappointments

     This code really is erroneous, because the scope of `struct
     mumble' the prototype is limited to the argument list containing

I think the word `in' is missing before `the prototype'.


Node: Non-bugs

   * Assuming (for optimization) that the address of an external
     symbol is never zero.

     This assumption is false on certain systems when `#pragma weak' is
     used.

Since the GNU C preprocessor doesn't recognize `#pragma weak' (as far as
I can tell), maybe changing the second sentence to something like:

     This assumption is false on certain systems when you use
     `#pragma weak' and a compiler other than GNU CC.

would make it clearer that #pragma weak is not a GNU feature, and it's
pointless to look through the GNU documentation for it.


Newsgroups: gnu.gcc.bug
From: meissner@osf.ORG
Subject: gcc on RISC 5.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 05:44:19 GMT

| | I'm having problems getting gcc to compile under the new OS and am wondering
| | if anyone else has had success. Here is the error message:
| |
| |       [stuff deleted]
| |       ./gcc    -g -B./  enquire.o -o enquire
| |       ld:
| |       ABI incompatible stack frame instruction sequence in object enquire.o
| |       collect: /usr/bin/ld returned 1 exit status
| |       *** Error code 1
| |
| | Configure was run with mips-mips-sysv but I have the same problem with bsd
| | and svr4.
| 
| 
| Has a solution to this problem been found?  

I just put a fix into the GCC release.  If you are on the gcc2 alpha
list, it will appear in the next snapshot.  Otherwise, it will appear
in GCC 2.3.

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  gcc-2.2.2 cc1plus dumps core building libg++-2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 12:45:58 GMT

This problem should be fixed in the next release of gcc.  Let ne know
if it is not.

> Date: Fri, 14 Aug 1992 13:51:42 +1200
> Message-Id: <9208140151.AA11525@raygun.inform.co.nz>
> From: mike@inform.co.nz (Mike Williams)
> To: bug-gcc@prep.ai.mit.edu

>   * GCC version: gcc-2.2.2
>   * Hardware: Data General AViiON 4600
>   * OS: DG/UX 5.4.1 (svr4)

>   * Configuration:
>       md -> config/m88k.md
>       tconfig.h -> config/xm-m88k.h
>       tm.h -> config/m88kdgux.h

>   * Description:

>     When building libg++-2.0, cc1plus dumps core when compiling BitSet.cc

>   * Backtrace:

>   | bin@raygun$ sde-target
>   | environment is m88kbcs
>   | bin@raygun$ make
>   |         (rootme=`pwd` ; export rootme ; cd src ; \
>   |                 make "CC=`if [ -d ${rootme}/../gcc ] ; \
>   |         then echo ${rootme}/../gcc/gcc -B${rootme}/../gcc/ ; \
>   |         else echo gcc ; fi`" "XTRAFLAGS=`if [ -d ${rootme}/../gcc ] ; \
>   |         then echo -I${rootme}/../gcc/include ; \
>   |         else echo ; fi`" \
>   |                 "AR=`if [ -d ${rootme}/../binutils ] ; \
>   |         then echo ${rootme}/../binutils/ar ; \
>   |         else echo ar ; fi`" "RANLIB=`if [ -d ${rootme}/../binutils ] ; \
>   |         then echo ${rootme}/../binutils/ranlib ; \
>   |         else echo ranlib ; fi`")
>   |         gcc -I. -I./../iostream -I./../g++-include  -c BitSet.cc
>   | gcc: Internal compiler error: program cc1plus got fatal signal 6
>   | *** Error code 1
>   |  
>   | Stop.
>   | *** Error code 1
>   |  
>   | Stop.
>   | bin@raygun$ find . -name core -print
>   | ./src/core
>   | bin@raygun$ dbx /usr/local/lib/gcc-lib/m88k-dg-dgux/2.2.2/cc1plus src/core
>   |  
>   | This version of DBX is implemented on top of GDB 3.6.9.12,
>   | Copyright (C) 1988 Free Software Foundation, Inc. and is in
>   | total compliance with the GDB copyright agreement.
>   |  
>   | According to GDB copyright agreement, you are welcome to distribute
>   | copies of this DBX under certain conditions; type "help copying" to see
>   | the conditions.
>   |  
>   | Reading symbol data from /usr/local/lib/gcc-lib/m88k-dg-dgux/2.2.2/cc1plus...done.
>   | Type "help" for a list of commands.
>   | (dbx) where
>   | Stack level 0 : 0x15e99c in _kill ()
>   | Stack level 1 : 0x15e574 in _abort ()
>   | Stack level 2 : 0x4644c in break_out_calls (exp=(union tree_node *) 0x41b8e8), file cp-tree.c, line 207

Newsgroups: gnu.gcc.bug
From: danisch@ira.UKa.DE (Hadmut Danisch )
Subject: Request for bugfix
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 12:55:47 GMT

Hi,

i sent a bugreport for the gcc-2.2.2 at Jun 25. Could you
tell me, whether there is already a bugfix or a newer
release of gcc?

Yours sincerely

Hadmut Danisch   danisch@ira.uka.de
Institut fuer Algorithmen und Kognitive Systeme
Universitaet Karlsruhe
D-7500 Karlsruhe

Germany

Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: GCC 2.2.2's source code sometimes uses `-1' in an unsigned context
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 03:53:44 GMT

GCC 2.2.2's source code sometimes uses a constant expression equivalent to
`-1' in an unsigned context.  This is a little confusing, and it provokes
warning messages in some compilers.  Here is a patch.

Thu Sep  3 03:28:35 1992  Paul Eggert  (eggert@twinsun.com)

	* integrate.h (CONST_AGE_PARM): Make it unsigned, to avoid
	warnings about negative numbers in unsigned contexts.
	* unroll.c (copy_loop_body): Use `CONST_AGE_PARM', not `-1'.
	* combine.c (simplify_and_const_int): Cast ~0 to unsigned,
	for similar reasons.

===================================================================
RCS file: RCS/integrate.h,v
retrieving revision 2.2
diff -c2 -r2.2 integrate.h
*** integrate.h	1992/01/14 11:50:17	2.2
--- integrate.h	1992/09/03 03:28:35
***************
*** 71,75 ****
       A value of -1 indicates an entry for a reg which is a parm.
       All other values are "positive".  */
! #define CONST_AGE_PARM (-1)
    unsigned int const_age;
    /* In parallel with const_equiv_map, record the valid age for each entry.
--- 71,75 ----
       A value of -1 indicates an entry for a reg which is a parm.
       All other values are "positive".  */
! #define CONST_AGE_PARM ((unsigned) -1)
    unsigned int const_age;
    /* In parallel with const_equiv_map, record the valid age for each entry.
===================================================================
RCS file: RCS/unroll.c,v
retrieving revision 2.2
diff -c2 -r2.2 unroll.c
*** unroll.c	1992/05/27 22:10:02	2.2
--- unroll.c	1992/09/03 03:29:28
***************
*** 1662,1666 ****
  
  	      if (map->const_age_map[regno] == map->const_age)
! 		map->const_age_map[regno] = -1;
  	    }
  	  break;
--- 1662,1666 ----
  
  	      if (map->const_age_map[regno] == map->const_age)
! 		map->const_age_map[regno] = CONST_AGE_PARM;
  	    }
  	  break;

===================================================================
RCS file: RCS/combine.c,v
retrieving revision 2.2
diff -c2 -r2.2 combine.c
*** combine.c	1992/06/02 21:35:27	2.2
--- combine.c	1992/09/03 03:30:26
***************
*** 4988,4992 ****
  	      varop = plus_constant (XEXP (varop, 0),
  				     INTVAL (XEXP (varop, 1)) & constop);
! 	      constop = ~0;
  	      break;
  	    }
--- 4988,4992 ----
  	      varop = plus_constant (XEXP (varop, 0),
  				     INTVAL (XEXP (varop, 1)) & constop);
! 	      constop = (unsigned) ~0;
  	      break;
  	    }

Newsgroups: gnu.gcc.bug
From: ler@lerami.lerctr.ORG (Larry Rosenman)
Subject: warning on fsglmul.x on AMIX
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 25 Aug 1992 01:12:07 GMT

i get a warning saying size must be .s if source is from FP register on a 
FSGLMUL instruction. 


this is with GCC 2.2.2

this is on AMIX. 

THis is similar to the fsgldiv problem I reported some time ago. 

if you need more info or a sample, let me know.

-- 
Larry Rosenman                            Internet: ler@lerami.lerctr.org
ATT: +1 214-399-0210 (voice)  BIX: ler    UUCP: ..!utacfd.uta.edu!lerami!ler
US Mail: 900 Lake Isle Circle, Irving, TX 75060-7726

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: WRONG LIST (was: Re:  gcc-2.2.2 cc1plus dumps core building libg++-2.0)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 12:44:54 GMT

In the future please report all g++ bugs to the
        bug-g++@prep.ai.mit.edu
list, thanks.  If they are back-end bugs, they can be reported here,
but please let us know if you think the problem is in the back-end.

You don't need to resubmit this one.

> Date: Fri, 14 Aug 1992 13:51:42 +1200
> Message-Id: <9208140151.AA11525@raygun.inform.co.nz>
> From: mike@inform.co.nz (Mike Williams)
> To: bug-gcc@prep.ai.mit.edu

>   * GCC version: gcc-2.2.2
>   * Hardware: Data General AViiON 4600
>   * OS: DG/UX 5.4.1 (svr4)

>   * Configuration:
>       md -> config/m88k.md
>       tconfig.h -> config/xm-m88k.h
>       tm.h -> config/m88kdgux.h

>   * Description:

>     When building libg++-2.0, cc1plus dumps core when compiling BitSet.cc

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++-2.2.2 profiling problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 13:11:21 GMT

You might try gcc 2.2.1, as I think it cures this problem.

> From: munson@acacia.cs.berkeley.edu (Ethan V. Munson)
> Message-Id: <9208191656.AA07546@acacia.CS.Berkeley.EDU>
> To: bug-gcc@prep.ai.mit.edu
> Date: Wed, 19 Aug 92 09:56:50 PDT

> Compiler: g++-2.2.2 (using LibG++ 2.1)
> Machine: SparcStation 2 running SunOS 4.1.2

> Problem: Can't link when profiling

> Description:

> When performing the final link step on our large program we get
> complaints from /usr/bin/ld that it can't find a number of symbols.
> These symbols all match the regular expression:

> 	LB[BE][1-9][0-9]

> For example, LBB29 and LBE29.  These symbols always come in pairs like
> this.

> They look like compiler-generated symbols to me and do not appear in
> any of our own code.

> Our final link command is:

> /usr/sww/bin/g++-2.2.2   -g -DTRACE -DDEBUG -pg -static  -Wimplicit -Wreturn-type -Wswitch    -o LDObj.sun4/ensemble main/LDObj.sun4/test5.o view/LDObj.sun4/libview.a exl/glue/LDObj.sun4/libglue.a exl/types/LDObj.sun4/libxtypes.a exl/misc/LDObj.sun4/libxmisc.a  doc/LDObj.sun4/libdoc.a  io/LDObj.sun4/libio.a  texted/LDObj.sun4/libtexted.a  supered/LDObj.sun4/libsupered.a  dispatch/LDObj.sun4/libdispatch.a  view/LDObj.sun4/libview.a  pres/LDObj.sun4/libpres.a  realize/LDObj.sun4/librealize.a  struct/LDObj.
sun4/libstruct.a  textbuf/LDObj.sun4/libtextbuf.a  textform/LDObj.sun4/libtextform.a  textrender/LDObj.sun4/libtextrender.a  location/LDObj.sun4/liblocation.a  repman/LDObj.sun4/librepman.a  ecp/LDObj.sun4/libecp.a  uspec/LDObj.sun4/libuspec.a  vtree/LDObj.sun4/libvtree.a  font/LDObj.sun4/libfont.a  common/LDObj.sun4/libcommon.a doc/LDObj.sun4/libdoc.a ecp/LDObj.sun4/libecp.a -lgsR4 -L.  -L/home/auspex/d/ensemble/lib -L/usr/sww/X11R4/lib -L/usr/sww/lib -lg++-2_1 -lm -lXm -!
lXt!
>  -lX11


> Ethan Munson
> munson@cs.berkeley.edu



Newsgroups: gnu.gcc.bug