HDTenEightyP/NetNews huggingface dataset:
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  g++ 2.1 global object instance initialization problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 07:23:01 GMT

> Date: Mon, 6 Apr 92 19:15:01 EDT
> From: cmr!elvin!anders@mailer.cc.fsu.edu (Anders Franzen)
> To: bug-gcc@prep.ai.mit.edu
> Subject: g++ 2.1 global object instance initialization problem

Problems in the C++ part of the compiler should go to
bug-g++@prep.ai.mit.edu, not this list.

Your problem should be solved in the next release of gcc.

> BUG REPORT
> --------------
> FROM:
> --
> Anders Franzen                  | TEL: +1 904/422-3574  | 
> Software Engineer               | FAX: +1 904/386-2562  |
> TechnoTeacher, Inc.             |                       |
> 1810 High Road                  | <anders@cmr.fsu.edu>  |
> Tallahassee, FL 32303           |                       |


> PROGRAM: g++  SUBPROGRAM: cc1plus
> VERSION: 2.1
>  SYSTEM: Sun 4/40 (IPC)
>      OS: SunOS 4.1.1 Rev B.

> LOCAL INSTALLATION:
> gcc 2.1 was installed by patching the 2.0 distribution
> with the gcc.diff-2.0-2.1 file. The following commands were then
> issued to build and install the new release:

>   configure sun4
>   make LANGUAGES=c
>   make stage1
>   make CC=stage1/gcc CFLAGS="-g -O -Bstage1/"
>   make stage2
>   make CC=stage2/gcc CFLAGS="-g -O -Bstage2/"

>   for file in *.o; do
>   cmp $file stage2/$file
>   done

>   make CC=stage2/gcc install
>   make install-fixincludes

> All of the above commands were successful.

> ---------------------------------------------------------------------

> BUG DESCRIPTION:

> The problem occurs when I try to use global instances of C++ objects
> with constructors as initializers.

> Here's an example of a global object array initialization. The
> following C++ code example (which I condensed from a much larger source)
> causes a signal 11, Segmentation fault, when compiled with g++ 2.1 on
> my system.

> -- Begin itest.cc

> class X {
>     int i1;
>     int i2;
>   public:
>     X(
>       int ii1,
>       char ii2
>       )
>       {
> 	  i1 = ii1;
> 	  i2 = ii2;
>       }
> };

> X x[] = { X(1, 2) };

> -- End itest.cc

> Here is an example g++ compilation of the above example:

>   anders@scofield 3% g++ -v -c itest.cc
>   Reading specs from /usr/local/lib/gcc-lib/sun4/2.1/specs
>   gcc version 2.1
>    /usr/local/lib/gcc-lib/sun4/2.1/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix itest.cc /usr/tmp/cca06032.i
>   GNU CPP version 2.1 (sparc)
>    /usr/local/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca06032.i -quiet -dumpbase itest.cc -version -o /usr/tmp/cca06032.s
>   GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
>   /usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11

Newsgroups: gnu.gcc.bug
From: pete@coos.dartmouth.edu (Pete Schmitt)
Subject: gcc 2.1 on Convex (C1)?
Organization: Dartmouth College, Hanover, NH
Distribution: gnu
Date: Fri, 10 Apr 1992 18:34:01 GMT

In trying to compile gcc2.1 on a Convex with 9.1 of ConvexOS I get
the following error:

cc -pcc -c    -g     -I. -I. -I./config version.c
cc -pcc -c    -g     -I. -I. -I./config obstack.c
cc -pcc    -g   -o cccp cccp.o cexp.o version.o obstack.o ` case "cc -pcc" in "c
c") echo  ;; esac `

ld: ERROR - Library 'libC1_old.a' not found
ld: No executable produced.
*** Exit 2

This file doesn't exist anywhere.  Why is it asking for it?

-pete
--
Peter Schmitt, UNIX Consultant, Computing Services, Dartmouth College
Email: peter.schmitt@dartmouth.edu                Phone: 603-646-2085
*** Let us not give up meeting together, as some are in the habit ***
*** of doing, but let us encourage one another.    -Hebrews 10:25 ***

Newsgroups: gnu.gcc.bug
From: chip@tct.COM (Chip Salzenberg)
Subject: Re: Possibly better bitfield patch for GCC 2.1
Organization: TC Telemanagement, Clearwater, FL
Distribution: gnu
Date: Wed, 8 Apr 1992 20:04:00 GMT

According to <caveh@csl.sri.com>:
>i reported a bug earlier today regarding gcc-2.[01] generating word
>instructions to access char-bitfields contained in a char for structures
>that were known to be long aligned.  i believe the following patch
>fixes the problem:

This patch is unnecessarily draconian.  Many machines don't care about
alignment.  How about this one instead:

Wed Apr  8 16:02:33 1992  Chip Salzenberg  (chip at animal)

	* stor-layout.c (get_best_mode): we may use word mode
	  for smaller objects iff STRICT_ALIGNMENT is false.

Index: stor-layout.c
*************** get_best_mode (bitsize, bitpos, align, l
*** 990,994 ****
      return VOIDmode;
  
!   if (SLOW_BYTE_ACCESS
        && ! volatilep
        && BITS_PER_WORD <= MIN (align, BIGGEST_ALIGNMENT)
--- 990,995 ----
      return VOIDmode;
  
!   if (!STRICT_ALIGNMENT
!       && SLOW_BYTE_ACCESS
        && ! volatilep
        && BITS_PER_WORD <= MIN (align, BIGGEST_ALIGNMENT)
-- 
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: gnu@toad.com
Subject: Re: ANSI C spec and GNU C preprocessing
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 11 Apr 1992 05:23:22 GMT

Mr. Barnes, you are completely confused about ANSI C.  The standard
specifies the *input* to a compiler, not the *output* from a
preprocessor.  The standard doesn't even have the concept of a
preprocessor that is separate from a compiler.

Applications that depend on the output of an arbitrary C preprocessor
are typically broken.  X11 expands makefiles that way -- that's a bug.
I've seen code in Berkeley Unix that tried to macro-process assembler
language files with a C preprocessor.  Of course, it broke when the
preprocessor was changed to handle ANSI C rules.  Save yourself some
trouble and use something else, such as "m4" or "sed", to handle your
macro or string replacement needs.  C preprocessors can do anything
that results in a valid C program; they are typically written to feed
their output into a particular C compiler, and can pass arbitrary
syntax-extensions to it (such as `# 5 "file.c"'); there is no spec
for their output.  Many compilers don't even have a separate
preprocessor.

1) #foo:  You have it backwards.
>    Since the spec doesn't say you can do that, I would read that as you
>    can't do it, so it would be a fatal error from the preprocessor.

On the contrary, if the spec does not have a specific requirement or
prohibition, the compiler can do anything.  See 2.1.1.3.

> 2) A conforming preprocessor must output line directives (3.8.4)

You have this backwards too.  This section describes the *input* syntax.

> 3) An alternate form of the '#line' directive would not use the keyword

Irrelevant since you were confused about (2).

	John Gilmore



Xref: sparky gnu.gcc.bug:1117 comp.lang.perl:3182
From: bill@Celestial.COM (Bill Campbell)
Newsgroups: gnu.gcc.bug,comp.lang.perl
Subject: gcc2.1 -O bug with SCO UNIX 3.2v4 and perl 4.10
Summary: Pattern Test #48 fails
Date: 15 Apr 92 15:59:15 GMT
Followup-To: gnu.gcc.bug,comp.lang.perl
Organization: Celestial Software, Mercer Island, WA
To: uunet!gnu-gcc-bug@uunet.uu.net

I got the gcc2.1 sources from uunet last weekend and compiled it
under SCO UNIX 3.2v4 with few problems other than some minor
changes to the SCO include files.

The first problem I've had was compiling perl 4.10 (I know 4.19
is the latest release, but the /$pattern/oi bug breaks too many
things for me :-).  The problem was that the op/pat failed on
test 48 (actually pattern 5 in that sequence) unless I turned
optimization completely off.  I tried various combinations on
Configure including both system and Larry mallocs with the same
results.

Is this a known problem with gcc2.1 or should I provide more
documentation?

A few other observations:
    -   The SCO egrep failed in perly.fixer saying the regular
        expression was too large.  gnu-grep-1.5 fixed that
        problem (compiled with gcc-2.1).

    -   The SCO cc compiler didn't work because of problems with
        cc -E in the make depend.  I didn't pursue this, but it
        shouldn't be too difficult to work around.

    -   rcc failed in the dbm tests (well actually it just hung
        forever).  This was probably because I had not put -Di386
        in the compiler flags.  I hadn't read the DevSys
        documentation prior to trying rcc.

Bill
-- 
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
             uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
Newsgroups: gnu.gcc.bug
From: lextrait@essi.cerisi.fr (Lextrait Vincent)
Subject: gnu cpp 2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 19:42:12 GMT

gnu cpp 2.1 aborts with Memory fault on the following input file :
BEGINNING OF FILE
#define	AslProgrTarg(program)						@@\
_OBJS:SH=setsuf .c .o $(C_SRCS)		 				@@\
	${NX} -DUTILITY=\"program\" ${NXOPTS} $<			@@\
/*-----------------------------------------------------------------------
 *-----------------------------------------------------------------------*/
install:: all								@@\
	$(INSTALL) -c $(INSTALLFLAGS) program $(BINDIR)
#define NxObjServers()							@@\
$(_VS_SRV):								@@\
	exit 1)								@@\
									@@\
_o_$(_VS_SRV):								@@\
	@mkdir $@							@@\
									@@\
_o_$(_VS_SRV)/$(VSMAKEFILE):						@@\
	@(echo "VSL_UTIL=SRVC" >> $@ ;\					@@\
END OF FILE
My cpp is compiled on a SparcStation1 running SunOs 4.1.0 (I use gcc 2.1)
Here is the output of gdb:
$ gdb /usr/local/gcc/cpp
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.4, Copyright 1991 Free Software Foundation, Inc...
(gdb) run reduced
Starting program: /usr/local/gcc/cpp reduced

Program received signal 10, Bus error
0x90ec in handle_directive (ip=0x2d2d2d2d, op=0x2d2d2d2d) at cccp.c:3363
3363          ip->bufp = resume_p;
(gdb) bt
#0  0x90ec in handle_directive (ip=0x2d2d2d2d, op=0x2d2d2d2d) at cccp.c:3363
#1  0x6584 in rescan (op=0x40400965, output_marks=2020176928) at cccp.c:2289
#2  0x5400 in main (argc=Cannot access memory at address 0x5256297e.
(gdb)
Some information has been written onto the stack. (Overflow of the area
reserved by alloca ?).
Vincent Lextrait
University of Nice
lextrait@essi.cerisi.fr

Newsgroups: gnu.gcc.bug
From: miron@cs.sfu.ca (Miron Cuperman)
Subject: Re: small program crashes GCC-2.1 on HP9000/720 (HP-UX 8.07)
Organization: Simon Fraser University
Distribution: gnu
Date: Sat, 11 Apr 1992 21:17:00 GMT

bhunt@critical.nswc.navy.mil (Brian Hunt) writes:

>I have (successfully so far, except for the problem I'm reporting)
>built GCC-2.1 on an HP9000/720 running HP-UX 8.07 (I don't have
>any other system I can build GCC-2.1 on, so I'm not sure how
>machine-specific the problem is.)  I am getting the following error
>message when trying to compile some programs.

>gcc: Internal compiler error: program cc1 got fatal signal 6

I don't know about this particular one, but you should compile
gcc with #define ONLY_INT_FIELDS.  The c compiler that comes with hpux
does not handle enums > 127.
-- 
Forever, Miron Cuperman <miron@cs.sfu.ca>		(NeXTmail ok)

	Laissez faire.

Newsgroups: gnu.gcc.bug
From: ltu@ki.icl.SE (Lars Tunkrans)
Subject: gcc 2.0 on sparc-svr4 wants bsd routines against advice in 
	INSTALL doc.
Organization: ICL Data AB Kista Sweden
Distribution: gnu
Date: Tue, 14 Apr 1992 17:10:30 GMT

I have started to build gcc 2.0 on sparc-svr4. I performed the 
"./configure sparc-svr4" run without problems. The compilation with the
USL cc compiler proceeds until we are supposed to link the cccp thing to
cpp  then ld says that we are missing several routines: bcopy bzero index and
rindex plus others.   Fine,  these things live in the /usr/ucblib/libucb.a  
library which the INSTALL document advices you not to use. It says literaly:
DONT USE THE LIBRARIES UNDER /usr/ucb SINCE THEY CONTAIN BUGS. After I hack the Makefile and set LIBS to -lucb the "cpp" links ok. Then later still gcc wants
some definitions in /usr/ucbinclude/sys/resource.h  I stopped here since I
realised there must be some configuration problems.

Is there another way to set up configure for sparc and SysVr4 than what i did ?
I cant find anythig else that works. what is the file config/sparcv4.h 
supposed to be used for ?

Lars.
--
_______________________________________________________________________________
Lars Tunkrans  Phone +46 (0)87642419   DRS Systems Services
DOMAIN Address : ltu@ki.icl.se         UUCP: 
X400: I=L;S=Tunkrans;OU1=SWE2002;O=ICL Data;P=ICL;A=TEDE;C=SE

Newsgroups: gnu.gcc.bug
From: S.Marshall@sequent.cc.HUll.ac.UK (Simon Marshall)
Subject: Bug with gcc-2.1 building epoch-4.0 (Sequent)...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 17:47:31 GMT

	I think this is a bug with gcc-2.1, which I found when I built
    epoch-4.0 on a Sequent Symmetry S81 running DYNIX V3.0.17.10.

	If I built with optimisation flags, all was OK.  If I built without,
    however, temacs crashed.  I found out this was due to me needing
    different CRT0_DUMMIES.  With optimisation, I needed to define it with
    one dummy, without I optimisation needed two.

	This appears (I have not tried all optimisation flags) to be as a
    result of optimisation turning on `-fomit-frame-pointer'.  Does this
    mean that `FRAME_POINTER_REQUIRED' should be defined for a Sequent?  If
    it does, unless I mis-understand it, this will mean that gcc-2.1 always
    needs two dummies, unlike the host cc.

	Simon. 
_______________________________________________________________________________
Simon Marshall, Dept. of Computer Science, University of Hull, Hull HU6 7RX, UK
  "Football isn't about life and death.  It's more important than that." Bill
Email: S.Marshall@Hull.ac.uk    Phone: +44 482 465181    Fax: 466666   Shankley

Newsgroups: gnu.gcc.bug
From: wilson@cygnus.com (Jim Wilson)
Subject: Re:  gcc 2.1 bug with frame ptr handling
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 23:53:55 GMT

	The code below on a sparc produces bad code when no opimization is
	turned on---note that it uses %fp *after* it's been zero'd out.  A

	register long int sp asm("%sp"), fp asm("%fp");
	foo ()
	{
	  int a;
	  fp = 0;
	  a = ((int *)sp)[4];
	  return a;
	}

You can't have an `auto' variable if there is no frame pointer to access
it off of.

I suggest adding `register' (or `static') to a's declaration.  This solves
the problem very nicely.

Jim
wilson@cygnus.com

Newsgroups: gnu.gcc.bug
From: root@minnie.informatik.uni-stuttgart.de
Subject: Re: GCC 2.1 on HPPA-HPUX
Organization: IfI, Univ. Stuttgart, W Germany
Distribution: gnu
Date: Mon, 6 Apr 1992 11:00:24 GMT

We have similar problems. We got an error of the as. (errno=1060).
Do anyone know help to us ?
We have an HP 9000/845 and HP-UX 8.0 .
We hope someone can help us.

Yours,
   Thomas Ploss
   (plossts@minnie.informatik.uni-stuttgart.de)

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  GCC 2.1 codegen bug when function is declared volatile
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 22:47:24 GMT

Please cite ANSI or any standard or any non-standard or any compiler
that accepts that code without complaints.

You probably cannot.  If you can, it is probably a broken compiler.

If you even tried gcc with -pedantic -ansi you would get errors:

t10.c: In function `main':
t10.c:4: warning: ANSI C forbids const or volatile functions

If you remove the volatile keyword, the code works.

Please see the documentation of volatile function in the gcc
distribution for exact semantics.

> Message-Id: <9204150101.AA19311@oz.NeXT.COM>
> Date: Tue, 14 Apr 92 18:01:38 PDT
> From: Bruce_Martin@next.com
> Received: by NeXT Mailer (1.63)
> To: bug-gcc@prep.ai.mit.edu
> Subject: GCC 2.1 codegen bug when function is declared volatile

> 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).

> Things work correctly when the optimizer is not used.

> Test case:

> 	compiled with: cc1 -O -o foo.s foo.c

> foo.c:

> main()
> {
>     volatile double     result1, result2;
>     volatile double     one_over(double);

>     do {
>         result1 = one_over(12);
>         result2 = one_over(12);
>     } while (result1 == result2);
>     exit(0);
> }

> double
> one_over(       double  x)
> {
>     return (double)( 1.0 / x );
> }




> Result of the compilation (note the lack of any code in main to
> test the return value of one_over, or a call to exit()):

>         .file   "foo.c"
> gcc2_compiled.:
> .text
>         .align 2
> .globl _main
> _main:
>         pushl %ebp
>         movl %esp,%ebp
>         subl $16,%esp
>         call ___main
>         pushl $1076363264
>         pushl $0
>         call _one_over
>         fstp %st(0)
>         .align 2,0x90
>         .align 2
> LC0:
>         .double 0d1.00000000000000000000e+00
>         .align 2
> .globl _one_over
> _one_over:
>         pushl %ebp
>         movl %esp,%ebp
>         fldl LC0
>         fdivl 8(%ebp)
>         leave
>         ret
>         .align 2,0x90



Newsgroups: gnu.gcc.bug
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: disabling warnings in dead code
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 17:28:36 GMT

It would be nice to not issue some kinds of warnings for completely dead code.

I have, for example:

      if (sizeof (cccc) > 4)
	cccc |= cccc << 32;

If CCCC is 32 bits, gcc 2.1 -Wall issues a warning that the shift count is
too large.  That's true; the code is wrong.  But it will never be executed.
If compiled with sizeof (CCCC) == 8, for example (i.e., cccc is declared
long long instead of long), however, the code will be executed, and it will
be correct.

Since cpp cannot do things like sizeof, there is no way to avoid having the
known-erroneous code presented to the compiler.  But gcc does this sort of
optimization well, so the dead statements never actually produce any code,
so using them is fine.  Only the warnings are annoying.

Newsgroups: gnu.gcc.bug
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Subject: Re: cccp patch for multi-arg defines...
Organization: Department of Computer Science, U of Copenhagen
Distribution: gnu
Date: Tue, 14 Apr 1992 11:08:49 GMT

gray@antaire.COM (Gray Watson) writes:
>Not a bug.  A feature upgrade on-top of gcc version 2.1.
>>	#define vmacro (...)		(void)printf(...)

>After a couple of hours of deep discussion here, we came up with __REST__ as
>magical token.  It is quite arbitrary and is #defined on in the patches so it
>can be changed easily.

Some years ago, I saw a description of another implementation of this
feature, the syntax of which I liked better:

#define errprint(fmt args) \
	(void)fprintf(stderr, "%s: "##fmt##": %s\n", prog args, strerr(errno))

Note the ``missing'' commas in both parameter and replacement lists;
the expansion of the last parameter includes the leading comma (if
any) to allow for the number of variable arguments to be zero. (Yes,
this causes odd expansions like |foo(, bar)| --- but varargs functions
in Standard C always have at least one fixed argument, so this would
only occur when using the preprocessor for other purposes.)

>In any case.  It seems to work fine here.  Can anyone see any problems with
>this being integrated into ccp?

Well, it seems to me that the above version is better because it
allows a proper name for the parameter, and allows it to cover zero
arguments. Since implementation in GCC probably is the only hope of
creating prior art so that a feature like this can be included in a
future revision of Standard C, I'd like to see as capable a version as
possible.

I don't have the 2.1 cccp.c unpacked at the moment, and more
importantly, I don't have the time to test anything, but I looked at
the 1.40 cccp.c and the patch file you sent, and I think this version
can be implemented with about the same amount of changes as the
__REST__ version, or perhaps a bit less. Perhaps after Easter ...

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)

Newsgroups: gnu.gcc.bug
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: GCC 2.1 Problem with System V/68
Organization: TH-Darmstadt
Distribution: gnu
Date: Wed, 8 Apr 1992 00:39:50 GMT

In article <m0lXfN8-0000CwC@tscs.tscs.com> gerard@tscs.tscs.COM (Stephen M. Gerard) writes:

   Newsgroups: gnu.gcc.bug
From: rlm@ms_aspen.hac.com (Robert L. McMillin)
Subject: Garbage in causes a crash
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 18:36:40 GMT

The following code fragment causes GCC v2.0 to crash:

---
/*
 * A test case to break the GNU C compiler...
 */

struct kaboom
{
    unsigned char	c[16];
};
volatile struct kaboom *k;

void
this_crashes_gnu_c ()
{
     *k;
}

---

This occurs with any of the v2.0 compilers I've tried, both on the Sun
386i running SunOS v4.0 and on the Motorola Delta running SVR3.6.  In
either case, the compiler dies with the following error message:

	gcc: Internal compiler error: program cc1 got fatal signal 6

The above fragment doesn't really seem to mean anything (I caught it as
a result of a coding error on my part), but it does seem that the
compiler shouldn't die like this.

---
Robert L. McMillin                     | Voice:    (310) 568-3555
Hughes Aircraft/Hughes Training, Inc.  | Fax:      (310) 568-3574
Los Angeles, CA                        | Internet: rlm@ms_aspen.hac.com


Newsgroups: gnu.gcc.bug
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: 2.1 gives annoying warnings
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 16:38:46 GMT

I have the macro:

#define	__sigemptyset(set)	((*(set) = 0L), 0)

Code like:

{
  sigset_t set;
  __sigemptyset (&set);
}

elicits `warning: value computed is not used' from gcc 2.1 with -Wall.
This is annoying.  And, it seems inconsistent.  GCC does not complain the
same code with:

int __sigemptyset (sigset_t *);

instead of the macro.  The return value is computed and ignored in both
cases.

Newsgroups: gnu.gcc.bug
From: hoelken@iml.fhg.DE (Norbert Hoelken)
Subject: gcc 2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 6 Apr 1992 20:08:01 GMT

I just received version 2.1 of GNU CC, but there seems to be a bug with static
data members in C++.

I installed gcc 2.1 on a Sun4/75 running SunOS 4.1.1 using 'configure sparc'.
Using this compiler i installed libg++ 2.0.

The following program was compiled without any options (only saying
g++ <name>.cc) and produced the linker error

		undefined reference to `__4test$Global_Value'

I tried all combinations of GNU as/ld and systems as/ld with the same result.
The error disappeares when i try to initialize the static member Global_Value
(commented out in the example).

The program works fine with an old release of g++ (g++ 1.37.1).

--- example -----
#include <stream.h>

class test
{
  public:
    test();
    ~test() {}
    static int Global_Value;
};

test::test()
{
    cout << Global_Value << "\n";
}

// int test::Global_Value = 1;

int main()
{
    test *t_ptr;
    t_ptr = new test;
}
------ end --------


			Thanks,

			Norbert Hoelken
			FhG-IML
			Emil-Figge-Str. 75
			D-4600 Dortmund 50 (FRG)
			email: hoelken@iml.fhg.de


Newsgroups: gnu.gcc.bug
From: rms@ccv.FR (Richard M. Stallman)
Subject: gcc2.1/i860 bug converting ints => doubles (fix included)
Reply-To: rms@gnu.ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 19:03:20 GMT

I think I did something else to fix this bug.  Could you please
look in the change log and see?

Newsgroups: gnu.gcc.bug