HDTenEightyP/NetNews huggingface dataset:
From: tony@brc.uconn.EDU (Tony Guzzi (Staff))
Subject: Warning message will compiling cp-decl.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 16:42:20 GMT

GnuCC version: 2.2.2
OS: SunOS 4.1.1
Hardware:  SPARCstation
'configure' cmd:   ../src/configure --target=sparc-sun-sunos4.1


The following warning message appeared during the compilation of the stage
2 and stage 3 compiler:

stage2/gcc -Bstage2/ -c -g -O -I. -I../src -I../src/config ../src/cp-decl.c
../patched-src/cp-decl.c: In function `hack_incomplete_structures':
../patched-src/cp-decl.c:10584: warning: comparison is always 1 due to limited range of data type

Can I ignore this warning, or does it represent a bug in the port?


-- Tony Guzzi
   Taylor L. Booth Center for Computer Applications and Research
=========================================================================
# U.S. MAIL:				| INTERNET:			#
#    University of Connecticut		|	tony@brc.uconn.edu	#
#    Rm 54, U-31, Booth Research Center	|				#
#    233 Glenbrook Road			| TELEPHONE:			#
#    Storrs, CT  06269-4031		|	(203) 486-5305		#
=========================================================================

Newsgroups: gnu.gcc.bug
From: kherron@ms.UKy.EDU (Kenneth Herron)
Subject: 2.2.2 constant expression range checking
Organization: University Of Kentucky, Dept. of Math Sciences
Distribution: gnu
Date: Wed, 7 Oct 1992 16:16:02 GMT

Our gcc has had several of Paul Eggert's patches applied, and I think
one of them is at fault here, so if they're not to be considered 
official then take this with a grain of salt.

This file, compiled with "gcc -c testit.c":
----------------
/* #include <sys/types.h> */
#ifndef u_char
#define u_char  unsigned char
#endif

static u_char badmap[] = {
	'\200', '\201', '\202', '\203', '\204', '\205', '\206', '\207',
};
static char goodmap[] = {
	'\200', '\201', '\202', '\203', '\204', '\205', '\206', '\207',
};
----------------
produces:
----------------
gcc-test.c:8: warning: constant expression out of range for unsigned type
gcc-test.c:8: warning: constant expression out of range for unsigned type
gcc-test.c:8: warning: constant expression out of range for unsigned type
gcc-test.c:8: warning: constant expression out of range for unsigned type
gcc-test.c:8: warning: constant expression out of range for unsigned type
gcc-test.c:8: warning: constant expression out of range for unsigned type
gcc-test.c:8: warning: constant expression out of range for unsigned type
gcc-test.c:8: warning: constant expression out of range for unsigned type
----------------
Uncommenting the #include line and commenting out the #define makes
no difference.

gcc -v returns:

Reading specs from /xbin/gnu/lib/gcc-lib/symmetry-dynix/2.2.2/specs
gcc version 2.2.2
-- 
Kenneth Herron                                   kherron@ms.uky.edu
University of Kentucky                              +1 606 257 2975
Department of Mathematics      I just thought of a neat disproof of
     Fermat's last theorem, but .signatures can only be four lines.

Newsgroups: gnu.gcc.bug
From: laurenz@juno.neuroinformatik.ruhr-uni-bochum.de (Laurenz Wiskott)
Subject: gcc-2.2.2 libg++-2.2 stream bugs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 11:07:15 GMT

	Dear 'GNU',

I've great respect for your Organization and like your software very
much. Many thanks for all that.

We are just changing from the AT&T C++ compiler to your gcc-2.2.2 with
the libg++-2.2. And the bugs changes also. I think I've found at least
one bug concerning the file streams. Here follows a simple example:

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

#include <fstream.h>

main()
{
  // the test files test1 and test2 do not yet exist ;

  // this behaves as expected ;
  ifstream ifile;
  ifile.open("test1",ios::in);
  cerr << ifile.good() << flush;
  ofstream ofile;
  ofile.open("test1",ios::out);   // the test1 file will be created here ;
  ofile << "data1" << flush;
  cerr << ofile.good() << flush;

  // but it is not possible to open a fstream 
  // in order to write something onto a file 
  // after you have tried to open it fruitless for a read access ;
  fstream iofile;
  iofile.open("test2",ios::in);
  cerr << iofile.good() << flush;
  iofile.close();              // even with a close() command ;
  iofile.open("test2",ios::out); 
  cerr << iofile.fail() << iofile.good() << flush; // output: 40
  iofile << "data2" << flush;   // no data in the test2 file ;

  // but it works with the AT&T compiler ;
};

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

The second is more an uncomfortable feature than really a bug I think.
Consider the following two programs.

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

#include <stream.h>

typedef char arrType;
#define arrSize 16

main()
{
  arrType arr[arrSize];
  for (int i=0; i<arrSize; i++)
    arr[i]=(arrType)i;
  cout.write((char *)arr,sizeof(arrType)*arrSize);
//  cout.flush();
}

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

#include <stream.h>

typedef char arrType;
#define arrSize 16

main()
{
  arrType arr[arrSize];
  cin.read((char*)arr,sizeof(arrType)*arrSize);
  for (int i=0; i<arrSize; i++)
    cerr << i << " : " << float(arr[i]) << "\n";
}

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

Compile it to get the executables 'out' and 'in' and pipe the result
of the first to the second: out|in. You can do it with or without the
flush command. The flush seems necessary but as I think it would be
more comfortable if it would not. 


	Kind regards, Laurenz Wiskott.



Newsgroups: gnu.gcc.bug
From: joris@zeus.rijnh.nl (joris)
Subject: bug in -pipe flag
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 13:12:28 GMT

Dear reader,

I have built gcc 2.2.2 for iris4d-irix4,
following the installation guide. No file is modified,
(the stage2 and stage3 binaries compare equal).

Trying the -pipe option results in:

hera % cat >file.c
/* nothing */
hera % gcc -c -pipe file.c
gcc: -pipe is not supported.
as: Error: no source, object or ucode file specified
file.c:2: output pipe has been closed
Segmentation fault (core dumped)

   and dbx said:

hera % dbx `which gcc`
dbx version 2.10 11/15/91 2:02
Type 'help' for help.
Reading symbolic information of `./gcc' . . .
Process name from core dump: gcc
Process died at pc 0x4089b0 of signal : Segmentation fault
[using memory image in core]
(dbx) where
>  0 .strcmp.strcmp(0x0, 0x100048a4, 0x10015bc0, 0xa, 0xc, 0x2) ["sys/close.s":16, 0x4089ac]
   1 execute() ["gcc.c":1541, 0x40198c]
(dbx) 

The 'specs' file for mips-irix tells correctly that the mips assembler
does not support pipes. For some reason (I don't have the time to investigate
the 'specs' logic) gcc does set up the full pipeline cpp | cc1 | as,
and later dumps core at "gcc.c":1541.
Suggestion:

gcc -pipe file.c  does
cpp file.c | cc1 > tmpfile ; as tmpfile -o file.o

Joris vdr Geer
joris@rijnh.nl
From: h.b.furuseth@usit.uio.NO
Newsgroups: gnu.gcc.bug
Subject: installation problems
Date: 16 Oct 92 15:35:01 GMT
Followup-To: gnu.utils.bug
Distribution: gnu
Organization: GNUs Not Usenet

Some installation problems with several GNU packages:

* Please do not make INSTALL targets write to the source directory.
  gcc-2.2.2/Makefile does this when it creates include files.
  Root has no write access to the source tree if it is NFS-mounted
  with "nosuid" for security (ie root is mapped to "nobody").  This
  can be fixed by giving the source tree public write access, but that
  idea is kind of unattractive:-)

* Insert a ".PHONY: install" line i Makefile.  GNU Make tried to end
  gcc-2.2.2 installation with "cat install.sh > install" because it
  found an install.sh file in the source direcory.

* (Not a bug)
  I'd like some control over how programs are named in $(bindir), ie
  install PROG as $(bindir)/PROG$(prog_suffix).
  For safety, I keep the older version of a program around until I have
  used the new version for some time.  So I install programs as ie
  /local/bin/gnu/bison-1.19 and make a link bison -> bison-1.19.  And
  /local/lib/gnu/bison/ -> bison-1.19/ of course.

Followup-To: gnu.utils.bug.


Regards,

Hallvard
Newsgroups: gnu.gcc.bug
From: metcalf@catfish.lcs.mit.edu (Chris Metcalf)
Subject: pmax cc1 2.2.2 dumps core
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 8 Oct 1992 08:29:08 GMT

The following short program (simplified from the gs 2.5.2 sources)
causes the DEC MIPS cc1 from gcc 2.2.2 to take a seg fault iff -O 
and -g are both specified.

        struct foo { int a; } *q, *p;

        void
        func(struct foo *r)
        {        
                p = r;
                q = p;
        }

It has probably already been reported, since it results from using
the Gnu compiler to build a Gnu tool on a popular platform.

--
			Chris Metcalf, MIT Laboratory for Computer Science
			metcalf@cag.lcs.mit.edu   //   +1 (617) 253-7766

Newsgroups: gnu.gcc.bug
From: rjg@umnstat.stat.umn.edu (Robert J. Granvin)
Subject: Dumb, but critical question...
Reply-To: rjg@umnstat.stat.umn.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 16:07:20 GMT

I know this is going to end up being dumb, but it's not the first time.
:-)

I have just installed gcc 2.2.2 in place of gcc 2.1 on our DECstations.
As with 2.1, everything went wonderfully well.  However, also as with
2.1, even though a g++ script is installed and everything is compiled to
handle c++ code, libg++.a is nowhere to be found.  Nor can I find very
much reference to it in the source or manpages (except indicating that
it's very likely needed).

The latter is true - it is needed - a system we're trying to install
requires c++, and we can't proceed unless g++ is fully installed.

Can you direct me where to find libg++.a, or what I may have done
incorrectly in the gcc installation to neglect building libg++.a?

Basically... I'm confused, and unable to progress at the moment.

Thanks for any assistance...

/bob
-- 
Robert J. Granvin                                       School of Statistics
rjg@umnstat.stat.umn.edu                             University of Minnesota

Newsgroups: gnu.gcc.bug
From: MEHRDAD@glum.DEv.cf.ac.UK (GHASSEMPOORY)
Subject: Documentation error in REAL_VALUE_TRUNCATE macro
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 15:46:00 GMT

I am trying to make a GCC 68K cross compiler for VAX-VMS. Since VAX is not 
compatible with IEEE floating point, I have to define REAL_VALUE... macros
according to GNU manual pages 294-295. The manual defines the macro as:

	REAL_VALUE_TRUNCATE(x)

While real.h has a default definition :

	REAL_VALUE_TRUNCATE(mode,x)

Can somebody clarify the situation please?

Many thanks in advance


Newsgroups: gnu.gcc.bug
From: samccall@ucdavis.edu (Sam McCall)
Subject: GCC2.2.2/dbx bug
Organization: Computing Services, UC Davis
Distribution: gnu
Date: Fri, 9 Oct 1992 20:27:35 GMT

i've run into the following bizarre behavior with gcc 2.2.2 and
dbx on a sparcstation running sunos 4.1.1B and 4.1.2.

when i install breakpoints in loops with dbx and then step through
them, dbx reports that the address/process is no longer writeable. 

this worked with gcc 1.39, same hardware and operating system.

is this a bug with dbx that's being massaged by gcc, or is it truly
a problem with the code generated by gcc?  

i'd appreciate responses sent directly to me, as i can't read this
group as often as i'd like.

email: Sam.McCall@ucdavis.edu

------------- typescript follows --------------
Script started on Fri Oct  9 13:20:12 1992
chip% ls
./          ../         t.c         typescript
chip% gcc -v -g -o t t.c
Reading specs from /usr/pkg/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/pkg/gnu/lib/gcc-lib/sparc-sun-sunos4.1/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 -g t.c /usr/tmp/cca11655.i
GNU CPP version 2.2.2 (sparc)
 /usr/pkg/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1 /usr/tmp/cca11655.i -quiet -dumpbase t.c -g -version -o /usr/tmp/cca11655.s
GNU C version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
 as -o t.o /usr/tmp/cca11655.s
 /usr/pkg/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/ld -e start -dc -dp -o t /lib/crt0.o -L/usr/pkg/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2 -L/usr/pkg/gnu/lib t.o -lgcc -lc -lg -lgcc
chip% dbx t
Reading symbolic information...
Read 117 symbols
(dbx) list
    6   {
    7           long    v[100];
    8           int     i;
    9   
   10           for(i=0;i<100;i++)
   11                   v[i]=(long)i*i;
   12           for(i=100;i;i--)
   13                   printf("v[%d] is %ld\n",i);
   14   }
(dbx) stop at 10
(2) stop at "/home1/ccsam/tmp/t.c":10
(dbx) run
Running: t 
stopped in main at line 10 in file "t.c"
   10           for(i=0;i<100;i++)
(dbx) step
stopped in main at line 11 in file "t.c"
   11                   v[i]=(long)i*i;
(dbx) step
stopped in main at line 10 in file "t.c"
   10           for(i=0;i<100;i++)
(dbx) step
can't write to process (address 0x10022b8)
May be unwriteable address, unwriteable process, etc (see ptrace(2))
(dbx) quit
chip% dbx t
Reading symbolic information...
Read 117 symbols
(dbx) stop at 13
(2) stop at "/home1/ccsam/tmp/t.c":13
(dbx) run
Running: t 
stopped in main at line 13 in file "t.c"
   13                   printf("v[%d] is %ld\n",i);
(dbx) step
v[100] is 0
stopped in main at line 12 in file "t.c"
   12           for(i=100;i;i--)
(dbx) step
can't write to process (address 0x1002304)
May be unwriteable address, unwriteable process, etc (see ptrace(2))
(dbx) quit
chip% cat t.c
#include <stdio.h>

main(ac,av)
int     ac;
char    **av;
{
        long    v[100];
        int     i;

        for(i=0;i<100;i++)
                v[i]=(long)i*i;
        for(i=100;i;i--)
                printf("v[%d] is %ld\n",i);
}
chip%
script done on Fri Oct  9 13:21:16 1992

Newsgroups: gnu.gcc.bug
From: greyhelm@cis.ksu.edu (Karl S. Hagen)
Subject: Question about GCC 2.2.2 - no support for harris tahoe bsd
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 17:17:58 GMT

Hi,

   I have access to a HARRIS HCX-9 that is running Tahoe Reno
   BSD 4.4.  I was going to upgrade the gcc compiler on it
   (1.40) due to the fact we were encountering strange errors
   that I could not explain as code problems.  One might it
   would compile fine and the next... major bugs... and this
   is with no code changes.  SO I decided to upgrade the compiler
   and reading thru. the instructions I found the harris stuff
   commented out.

    Has there been a fix for this that I have missed... or is there
   something I can do to fix this.  It would be very much appreciated

-- 
   Karl S. Hagen  			   Dept. of Physics
   greyhelm@cis.ksu.edu             Physics Education Research Group
   Kansas State University 		Phone: (913) 532-5629

Newsgroups: gnu.gcc.bug
From: andy@research.CAnon.oz.AU (Andy Newman)
Subject: void functions returning expressions (which are void functions)
Organization: Canon Information Systems Research Australia
Distribution: gnu
Date: Fri, 9 Oct 1992 05:59:23 GMT

gcc 2.2.2 under SunOS 4.1.1 (and 4.1.2) does not report any problems
with the following code...


void fred(void)
{
}

void joe(void)
{
    return fred();
}


Section 3.6.6.4 of the ANSI standard states that void functions cannot
have return statements with expressions.

-- 
Andy Newman (andy@research.canon.oz.au)
"Giving money and power to governments is like giving whiskey and
 car keys to teenage boys" - P.J.O'Rourke

Newsgroups: gnu.gcc.bug
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: GCC for i386: builtin strcmp not ANSI compliant
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 23:48:56 GMT

The __builtin_strcmp function that GCC uses for strcmp on i386 when compiling
with -O is not ANSI compliant.

I'm using GCC version 2.2.2d, configured as i386-linux by H.J.Lu.

To be ANSI compliant, strcmp() must compare the characters of the two strings
as if they were unsigned characters. This implies that "abc" is to be
considered `less' than any string beginning with "abc".
The following program tests this.

==================== strcmp.c ================================
#include <string.h>
#include <stdio.h>

main ()
  { printf("%d %d %d %d\n",strcmp("abc","abcx"),
                           strcmp("abc","abc\376"),
                           strcmp("abcx","abc"),
                           strcmp("abc\376","abc")
          );
  }
===============================================================

When compiled with  gcc -O strcmp.c  and run, it produces the output
-120 2 120 -2
This reveals incorrect handling of characters with values in the range
128..255.

The assembly code produced by  gcc -O -S strcmp.s  is the following:

====================== strcmp.s ================================
	.file	"strcmp.c"
gcc2_compiled.:
.text
LC0:
	.ascii "abc\0"
LC1:
	.ascii "abc\376\0"
LC2:
	.ascii "abcx\0"
LC3:
	.ascii "%d %d %d %d\12\0"
	.align 2
.globl _main
_main:
	pushl %ebp
	movl %esp,%ebp
	pushl %edi
	pushl %esi
	call ___main
	movl $LC1,%esi
	movl $LC0,%edi
	movl $4,%ecx
	xorb %al,%al
	repe
	cmpsb
	je L2
	movb -1(%esi),%al
	subb -1(%edi),%al
L2:
	movsbl %al,%eax
	pushl %eax
	movl $LC2,%esi
	movl $LC0,%edi
	movl $4,%ecx
	xorb %al,%al
	repe
	cmpsb
	je L3
	movb -1(%esi),%al
	subb -1(%edi),%al
L3:
	movsbl %al,%eax
	pushl %eax
	movl $LC0,%esi
	movl $LC1,%edi
	movl $4,%ecx
	xorb %al,%al
	repe
	cmpsb
	je L4
	movb -1(%esi),%al
	subb -1(%edi),%al
L4:
	movsbl %al,%eax
	pushl %eax
	movl $LC0,%esi
	movl $LC2,%edi
	movl $4,%ecx
	xorb %al,%al
	repe
	cmpsb
	je L5
	movb -1(%esi),%al
	subb -1(%edi),%al
L5:
	movsbl %al,%eax
	pushl %eax
	pushl $LC3
	call _printf
	leal -8(%ebp),%esp
	popl %esi
	popl %edi
	leave
	ret
================================================================

Simply subtracting the two last characters is not enough:
	movb -1(%esi),%al
	subb -1(%edi),%al
They should be zero-extended to some wider format before being subtracted.

These instructions are emitted by the section "memcmp recognizers"
in i386.md.

In any case, compiling strcmp() inline is a VERY advanced optimization.
Congratulations for that work!

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

Newsgroups: gnu.gcc.bug
From: jon@halsp.hitachi.COM (Jonathan Ryshpan)
Subject: Re: Incorrect code generated unless optimization is turned on.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 20:09:01 GMT

>Short synopsis: I am running DJGPP 1.08, under MS/DOS.  gcc -v reports 2.2.2.
>Unfortunately, I do not have access to a 386 version of Unix to test this on.
>I did nothing other to unpack the .ZIP files and run them (no compiler mods)

Yup.  Same problem running gcc under System V.  Don't have time to
investigate more.  Foo contains George Jetson's program.

Foo!

	$ gcc foo.c -o foo
	$ foo
	Memory fault

Newsgroups: gnu.gcc.bug
From: dcb@us-es.SEl.DE
Subject: G++, ARM Page 141
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 08:51:52 GMT

Hello there,

Given the following code

extern int fred( int);

class X {
public :
    void f( int = fred( 0) ) ;
} ;

void X::f( int x = fred( 0) ) {
}

and a copy of GCC 2.2.2 on Sun 4 hardware, then according to my reading
of Page 141, section 8.2.6, fourth sentence, I think the line with
the last mention of function fred should produce an error.

In fact the compiler accepts it happily.

Regards

David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841
If you lie to the compiler, it will get its revenge


Newsgroups: gnu.gcc.bug
From: khraishi@isl.stanford.edu (Nasser M. Khraishi)
Subject: A g++ bug in overloading in derived classes.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 06:24:01 GMT

Hello,
I ran into the following bug while porting a function to the SUN-CC2.1.
I initially thought that it is a CC2.1 problem (I trust your stuff a little
bit more) but after reading the ARM quite carefully it turns out that the
desirable response produced by g++ is actually the incorrect one.

The piece of code in question can be reduced to the equivalent of the
following code.  I have included the explanation of the bug as a comment.

Best regards, and keep up the good work.

Nasser.
-------------
#include	<iostream.h>
enum f1 {
     F1
};

enum f2 {
    F2
};

class A {
public:
    void set (f1 f);
};
void A::set (f1 f) { cout << "called A f1\n";}

class B : public A {
public:
    void set (f2 f);
};
void B::set (f2 f) { cout << "called B\n";}

main() {
    B b;
    b.set(F1); // ARM page 309: should call A.set(f1) and that what g++ does,
	       // but 13.1 of ARM clearly states that it should call B::set()
	       // or generate an error because overloading works only for
	       // functions within the same scope (first page of chapter 13)
	       // while member of derived and base classes are considered to
	       // belong to different scopes.  Thus B::set() should have
	       // hidden (completely) the A::set() function.
}
----------

Newsgroups: gnu.gcc.bug
From: moore%cs@hellgate.utah.edu (Tim Moore)
Subject: Re: stdarg/varargs and the v?printf's on HP700
Organization: University of Utah CS Dept
Distribution: gnu
Date: Wed, 7 Oct 1992 14:13:45 GMT

In article <9210062259.AA01023@bunny.gte.com> steve%eowyn@gte.com (Steve Preston) writes:

   HP9000/720 HPUX 8.07 gcc 2.2.2 (configured for hppa1.1-hp-hpux)

   This is really HP's fault, I would guess.

   The GNU C compiler defines its own version of stdarg/varargs data
   structures, defining the type va_list as a structure of pointers,
   thusly:

   typedef struct
   {
...
   } va_list;

   In the HPUX headers, the v?printf's are declared to take the type
   __va_list which is typedef'ed as a pointer to double.  So any calls to
   v?printf either cause a compile error or fail badly at runtime.

varargs/stdargs have been rewritten for gcc 2.3 (coming soon) to be
compatible with HP's implementation.

--
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
	- Rush

Newsgroups: gnu.gcc.bug