HDTenEightyP/NetNews huggingface dataset:
From: johns@haggis.ccsf.caltech.edu (John Salmon)
Subject: inline without optimization
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 02:43:47 GMT

The following is either a bug in gcc or a bug in its documentation.
I suspect the latter.  I'm using gcc2.2.

When a function is defined as 'inline' but optimization is not
selected, the function is NOT inlined.  Presumably this is an aid to
debugging.  It's reasonable behavior, but it is completely undocumented.

I suggest that an appropriate paragraph be placed in the Inline info
node, as this behaviour was a surprise to me, and I spent a while
thinking that inline was completely broken before I figured out what
was wrong.  I won't venture to suggest the text of the paragraph
because I'm not absolutely certain I understand the exact conditions under
which `inline'-declared functions are actually inlined.

Thanks,
John


Newsgroups: gnu.gcc.bug
From: jclark@sdcc3.ucsd.edu (John Clark)
Subject: Re: built-in strlen returns long unsigned int?
Organization: University of California, San Diego
Distribution: gnu
Date: Tue, 8 Sep 1992 19:52:34 GMT

In article <1992Sep4.204457.25043@muddcs.claremont.edu> jason@jarthur.claremont.edu (Jason Merrill) writes:
+../../../libg++/src/../g++-include/string.h:28: declaration of `int  strlen
+(const char *)'
+
+<built-in>:0: conflicts with built-in declaration `long unsigned int
+strlen (const char *)'
+-----
+
+Why does gcc think that strlen should return long unsigned int, rather than
+int?  How does it go about deciding the return type for these built-in

Because ANSI C library definitions have:

size_t strlen( const char *);


+functions?  I haven't been able to find the place in the make process where
+this happens.

Look at the file 'sys-protos.h' in the gcc-2.2.2 directory.

+I am working on a Sequent Symmetry running Dynix.  The string.h we are
+using comes, I believe, from the AT&T C++ translator v1.2, and looks like
+this:
+
+
+/*	@(#)string.h	1.2	*/
+extern char
+	*strcpy(),
+	*strncpy(),


Appears to be non-ANSI standard string declarations. Get the book,
'The Standard C Library' by P.J. Plauger which describes the various
declarations for the ANSI library functions.
-- 

John Clark
jclark@ucsd.edu

Newsgroups: gnu.gcc.bug
From: bwilson@shasta.stanford.edu (Bob Wilson)
Subject: need test for negative constants in output_addr_const()
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 21:09:24 GMT

gcc version 2.2.2
configured for mips-dec-ultrix

The output_addr_const() function in final.c needs another test for negative
constants.  Without this, an expression like (x - (-2)) is printed as
"x--2", and the MIPS assembler doesn't like that.  Here's a patch:

> *** final.c.orig	Tue Sep  8 13:43:56 1992
> --- final.c	Tue Sep  8 13:46:54 1992
> ***************
> *** 2127,2133 ****
>   
>       case MINUS:
>         output_addr_const (file, XEXP (x, 0));
> !       fprintf (file, "-");
>         output_addr_const (file, XEXP (x, 1));
>         break;
>   
> --- 2127,2134 ----
>   
>       case MINUS:
>         output_addr_const (file, XEXP (x, 0));
> !       if (INTVAL (XEXP(x, 1)) >= 0)
> ! 	fprintf (file, "-");
>         output_addr_const (file, XEXP (x, 1));
>         break;
>   

Newsgroups: gnu.gcc.bug
From: ralf@up3aud1.gwdg.de (Ralf Fassel)
Subject: #include-file-bug?
Organization: Gnus Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 22:20:47 GMT

Guten Tag,
trying to compile source code containing sth like:
/***************************/
/*  test.c */
#include	<sys/ioctl.h>
#define	S32DSINT  (_IO(D,4))
main()
{
	int i=S32DSINT;
}
/***************************/
results in:
> 
> make -k CC=gcc CFLAGS="-g -O -traditional" CPPFLAGS= test.o
> gcc -g -O -traditional -target sun4 -c  test.c
> test.c: In function `main':
> test.c:6: `D' undeclared (first use this function)
> test.c:6: (Each undeclared identifier is reported only once
> test.c:6: for each function it appears in.)
> *** Error code 1
> 
GCC configuration is:
gcc -v:
-Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.2/2.2.2/specs
-gcc version 2.2.2

running on
sun sparc ipx sunos 4.1.2

was configured:
configure --target=sparc-sun-sunos4.1.2

it seems to me that the error is located in ioccom.h in <sys/>

compare:
/usr/local/lib/gcc-lib/sparc-sun-sunos4.1.2/2.2.2/include/sys/ioccom.h:
/* the 0x20000000 is so we can distinguish new ioctl's from old */
#define	_IO(x,y)	(_IOC_VOID|(x<<8)|y)
#define	_IOR(x,y,t)	(_IOC_OUT|((sizeof(t)&_IOCPARM_MASK)<<16)|(x<<8)|y)
#define	_IORN(x,y,t)	(_IOC_OUT|(((t)&_IOCPARM_MASK)<<16)|(x<<8)|y)
#define	_IOW(x,y,t)	(_IOC_IN|((sizeof(t)&_IOCPARM_MASK)<<16)|(x<<8)|y)
#define	_IOWN(x,y,t)	(_IOC_IN|(((t)&_IOCPARM_MASK)<<16)|(x<<8)|y)
/* this should be _IORW, but stdio got there first */
#define	_IOWR(x,y,t)	(_IOC_INOUT|((sizeof(t)&_IOCPARM_MASK)<<16)|(x<<8)|y)
#define	_IOWRN(x,y,t)	(_IOC_INOUT|(((t)&_IOCPARM_MASK)<<16)|(x<<8)|y)
-----------------------------------
with:
/usr/include/sys/ioccom.h
/* the 0x20000000 is so we can distinguish new ioctl's from old */
#define	_IO(x,y)	(_IOC_VOID|('x'<<8)|y)
#define	_IOR(x,y,t)	(_IOC_OUT|((sizeof(t)&_IOCPARM_MASK)<<16)|('x'<<8)|y)
#define	_IORN(x,y,t)	(_IOC_OUT|(((t)&_IOCPARM_MASK)<<16)|('x'<<8)|y)
#define	_IOW(x,y,t)	(_IOC_IN|((sizeof(t)&_IOCPARM_MASK)<<16)|('x'<<8)|y)
#define	_IOWN(x,y,t)	(_IOC_IN|(((t)&_IOCPARM_MASK)<<16)|('x'<<8)|y)
/* this should be _IORW, but stdio got there first */
#define	_IOWR(x,y,t)	(_IOC_INOUT|((sizeof(t)&_IOCPARM_MASK)<<16)|('x'<<8)|y)
#define	_IOWRN(x,y,t)	(_IOC_INOUT|(((t)&_IOCPARM_MASK)<<16)|('x'<<8)|y)
-----------------------------------
and not the quotes '' around the x'es.

Is this a bug or what did I wrong installing GCC?

Best regards
Ralf

---------------------------------------------------------
Ralf Fassel                   III.Physikalisches Institut
Internet: ralf@up3aud1.gwdg.de          Buergerstr. 42-44
Phone: (Germany)(551)39-7730            W-3400 Goettingen
FAX:   (Germany)(551)39-7720                      Germany

Newsgroups: gnu.gcc.bug
From: barrera@mtu.edu (CHRISTOPHER BARRERA)
Newsgroups: gnu.gcc.bug
Subject: Install problem - gcc-2.2.2 on Sequent
Date: 11 Sep 92 17:50:46 GMT
Distribution: gnu
Organization: Gnus Not Usenet

I am currently installing GCC 2.2.2 on a Sequent Symmetry
running Dynix 3.1.2 (BSD), and I get the following error
during the first make (make LANGUAGES=c) :

        if [ "." != "." ]; then rm -f ./enquire.c; else true; fi
        cp ./enquire.c . > /dev/null 2>&1
*** Error code 1 (ignored)
        ./gcc    -g -B./    -DNO_SC -DNO_MEM -DNO_STDDEF -O0 -I. -c enquire.c
        ./gcc    -g -B./  enquire.o -o enquire
ld:-L: bad flag
collect: /bin/ld returned 4 exit status
*** Error code 1
Make: .  Stop.

Has anyone encountered this problem before, and let me know where
to take it from here?

I did try one fix but I am not sure if that is the proper way to go about
it. In the makefile enquire.c is linked using GCC instead of the system's
CC. I changed it to use the system's CC and it linked. However, the same
problem appeared again elsewhere while compiling the stage 1 compiler.

Any help or ideas would be greatly appreciated.  :)

thanks

-chris barrera

barrera@mtu.edu   cjbarrer@major.cs.mtu.edu
Newsgroups: gnu.gcc.bug
From: willimsa@unix1.tcd.ie (Gavin Williams)
Subject: GCC 2.22 square root function.
Organization: Trinity College, Dublin
Distribution: gnu
Date: Tue, 8 Sep 1992 15:01:42 GMT

I don't *think* this is a bug, but I thought I'd better post it to g.g.b
anyway JIC.



	Hello,
	
I recently downloaded DJ Delorie's GCC 222 package, as I wish to learn C.
However, when I tried to run this program, the compiler barfed out with 
the following message,
	
eg16.o: Undefined symbol _sqrt referenced from text segment.

The command I was using was, 
		gcc eg16.c

I have a 486DX/33 with 4M ram, and the autoexec.bat set up as mandated in 
the README file.

Has anyone got any ideas as to why this is happening?

		Thanks a lot, 
				Gavin


Newsgroups: gnu.gcc.bug
From: ian@cygnus.com (Ian Lance Taylor)
Subject: Typo in optabs.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 22:14:33 GMT

There's a typo in optabs.c.  In the following:

#ifdef HAVE_fix_truncdfqi2
  if (HAVE_fix_truncdfsi2)
    fixtrunctab[(int) DFmode][(int) QImode][0] = CODE_FOR_fix_truncdfqi2;
#endif

the if condition should be HAVE_fix_truncdfqi2.  This probably makes
no difference for any actual machine.  I just happened to notice it.

Ian Taylor

Newsgroups: gnu.gcc.bug
From: meissner@osf.ORG
Subject: Possible stdarg.h bug on Mips Ultrix?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 14:33:50 GMT

| In gcc 2.2.2, stdarg.h includes va-mips.h, which says
| 
|     #define va_arg(AP, mode)						\
|       ((mode *)(AP = (char *) (__alignof(mode) > 4			\
| 				    ? ((int)AP + 2*8 - 1) & -8		\
| 				    : ((int)AP + 2*4 - 1) & -4)))[-1]
| 
| 
| (if !lint).  However, under Ultrix V4.2A (Rev. 47) running on a
| DecStation, I find the following:
| 
|     #ifdef __host_mips
| 
|      ...
| 
| 	    /* va_arg aligns list and points past data */
|     #define va_arg(list, mode) ((mode *)(list =\
|      (va_list) ((((int)list + (__builtin_alignof(mode)<=4?3:7)) &\
|      (__builtin_alignof(mode)<=4?-4:-8))+sizeof(mode))))[-1]
| 
| Notice that the va-mips.h code is insensitive to sizeof(mode).  As a
| result, passing of sufficiently large structures does not work.  What
| is going on?

Fixed in GCC 2.3.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.

Newsgroups: gnu.gcc.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: built-in conflict resolved, more or less
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Fri, 4 Sep 1992 21:19:42 GMT

OK, I understand the situation better now:

The ANSI standard for size_t is long unsigned int, and the seq386.h header
file does not redefine SIZE_TYPE to int to agree with the system headers.

However, libg++/utils/gen-params checks the system headers before the gcc
headers to find out what size_t is, so it finds the typedef of size_t to
int in sys/types.h.

There are two solutions I see:
1) Redefine SIZE_TYPE in config/seq386.h to agree with the system headers.
2) Alter gen-params to use the definition of size_t in the gcc headers.

Which is preferable?

--
Jason Merrill
jason@jarthur.claremont.edu

-- 
Fool on a Pedestal
From: gej@okcforum.osrhe.uoknor.edu (Eric Jergensen)
Newsgroups: gnu.gcc.bug
Subject: Order of evaluation problem in gcc & g++ on sun4
Date: 10 Sep 92 03:45:15 GMT
Distribution: gnu
Organization: GNUs Not Usenet

For gcc-2.2.2 (compiled w/ CFLAGS='-g -O', default sun4 configuration) on a
sparc, the program:
int main(void)
  {
  float a1[4] = { 1, 2, 3, 4 },
        a2[4] = { 1, 2, 3, 4 };
  float * ptr = a1;
  int i;
  for (i = 0; i < 3; i++)
    {
    *ptr++ = *ptr + 1;
    a2[i] += 1;
    printf("a1[%i] = %g, a2[%i] = %g\n", i, a1[i], i, a2[i]);
    }
  return 0;
  }

produces:
a1[0] = 3, a2[0] = 2
a1[1] = 4, a2[1] = 3
a1[2] = 5, a2[2] = 4

instead of:
a1[0] = 2, a2[0] = 2
a1[1] = 3, a2[1] = 3
a1[2] = 4, a2[2] = 4

The command line used to compile this as C code:
gcc -o testinc -x c testinc.cxx

The command line used to compile this as C++ code:
gcc -o testinc testinc.cxx

BOTH ways of compiling produce code that gives the bad results.

Other compilers (and even gcc-2.2.2 on 3b2) produce code that gives the
intended output.

Eric Jergensen
Newsgroups: gnu.gcc.bug
From: darrell@galois.nscf.org (Darrell Tangman)
Subject: volatile and longjmp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 14:08:23 GMT

The following code sequence fails on the Motorola 88K when compiled
with gcc 2.2.2 with options "-O -g -funsigned-char"; it has not been
tested without "-g -funsigned-char".  Without "-O" the code sequence
executes as expected.  If fail_msg is declared static the code
sequence executes as expected.

	volatile char	*fail_msg ;

	if (setjmp (regexpfail)) {
		sprintf (msg, "%s\n (%s)", fail_msg, regexp_errmsg) ;
		WriteErr (5, "EvalINDEX", msg, DO_PRINT_UNIT) ;
		operand[0].val.value.integer_value = 0 ;
	} else {
		fail_msg = "Incorrectly formed search argument." ;
		regbuff = CompileRegexp (srch) ;
		fail_msg = "Error occurred while searching." ;
		if (regexec (regbuff, src->chars) == 0)
		.
		.
		.
	}

The functions CompileRegexp and regexec both longjmp to regexpfail
when they encounter errors.  When this code is compiled with the
"-O" option, it appears that the first store to fail_msg is deleted;
if the longjmp is executed from CompileRegexp, the value in fail_msg
is not a pointer to the specified string.  This violates the specifi-
cation that "at every sequence point the value of the object in storage
shall agree with that prescribed by the abstract machine" (describing
an object with a type that includes the volatile type specifier) in
our copy of the July 9, 1986, Draft Proposed American National Standard
for Information Systems -- Programming Language C (3.5.2.4, const and
volatile).  Unfortunately, we do not have anything later than the 1986
draft; I offer my apologies if this statement has disappeared.
--
Darrell Tangman -- darrell@galois.NSCF.org
National Mathematics Center / National Science Center Foundation, Inc.
P.O. Box 15577, Augusta, GA, USA, 30919-1577
From: mpk@circhp3.epfl.ch (Peter Kennedy)
Newsgroups: gnu.gcc.bug
Subject: (none)
Date: 15 Sep 92 17:21:05 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Subject: installation on an m68k-hp-hpux


I am trying to install gcc-2.2.2 on an HP 300 series worskation running
HP-UX 8.0.  I have been following the installation procedure in the 
"Using and Porting GNU CC" manual for version 2.2.

I have configured the system using:

configure --target=m68k-hp-hpux m68k-hp-hpux

When I try to compile using:

make LANGUAGES=c

I get a bunch of warnings of the type:

operands of "=" have incompatible structure/union pointer types

and a fatal error when ld cannot find the functions `getwd' or 
`getrusage.'  What have I done wrong, and how can I fix it?
I am aware of the assembler bug that is mentioned in the manual,
but this seems to be a different problem.

Thanks,

Peter Kennedy

Departement d'Electricite
Ecole Polytechnique Federale de Lausanne
1015  Lausanne
SWITZERLAND

mpk@circhp3.epfl.ch
From: kris.wbst129@xerox.com
Newsgroups: gnu.gcc.bug
Subject: Can't 'make' glibc-1.04
Date: 11 Sep 92 12:55:30 GMT
Reply-To: kris.wbst129@xerox.com
Distribution: gnu
Organization: Xerox

(I also sent this separately to bug-glibc@prep.ai.mit...)


GNU ld is in  /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.1/2.2.2/ld.
GNU make-3.62 is in /usr/local/bin/make.
GNU gas-1.38 is in /usr/local/bin/gas.

I ran:
configure --with-gnu-ld --with-gnu-as sparc-sun-sunos4.1.1

Then typed "make".  Here's what I got in return:
Makeconfig:72: extraneous text after `include'
make: sysdeps/..: Is a directory.  Stop.

The above two steps were the only things I did, i.e. no configparms, etc.
Any pointers?  BTW, libg++-2.2 installed without a hitch.  Thanks.


--
Kris A. Schneider
EMail:     kris.wbst129@xerox.com
XRXMail:   Kris:Wbst129:Xerox
Newsgroups: gnu.gcc.bug
From: schulze@asgard.lpl.arizona.edu (Dean Schulze)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 19:04:41 GMT

Sept. 8, 1992

Hello FSF,

    I'm having two problems with GNU C v1.39 running under Sun OS 4.1.1 on a
SPARC system.

    The first involves the function ungetc().  Here is a file that
demonstrates the problem.  (This code comes from the file
lread.c which is part of the distribution for ATT's fortran to C converter
f2c.  lread.c is part of the library libI77.)

#include  "stdio.h"


int (*l_ungetc)();

/*
    inserting this line allows the code to complile
#define ungetc
*/

#ifdef ungetc
 static int
#ifdef KR_headers
un_getc(x,cf) int x; FILE *cf;
#else
un_getc(int x, FILE *cf)
#endif
{ return ungetc(x,cf); }
#else
#define un_getc ungetc
#ifdef KR_headers
 extern int ungetc();
#endif
#endif

int AFunction()
{
    l_ungetc = un_getc;
    return (0);
}


Apparently if ungetc isn't #defined the user is supposed to supply their own.
However, gcc thinks that ungetc is not #defined, so the macro un_getc gets
set to ungetc.  (I'm not using KR_headers.)

   The compiler generates the following error message:

lread.c: In function s_rsle:
lread.c:584: `ungetc' undeclared (first use this function)
lread.c:584: (Each undeclared identifier is reported only once
lread.c:584: for each function it appears in.)

    How is ungetc() implemented in GNU C?  I can't find a prototype for it
in any of the header files, but it exists in one of the libraries and other
code that uses it works.  I've also tried compiling with the -E switch to
see if ungetc() was implemented as a macro, but it isn't.

    I got the code to compile by placing a

#define ungetc

before the

#ifdef ungetc

statement.  If ungetc is a library function why isn't there a prototype for
it?  If it is "built in" to GNU C why isn't the compiler aware of it when
cpp encounters the

#ifdef ungetc

statement?

    The second problem involves the function strtoul().  It doesn't seem to
exist in GNU C v1.39.  Does it exist or was it left out of v1.39?


Dean Schulze
schulze@argus.lpl.arizona.edu


Newsgroups: gnu.gcc.bug
From: cracraft@ai.mit.edu (Stuart Cracraft)
Subject: GCC 2.2 report
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sun, 13 Sep 1992 02:06:52 GMT

Hi,

I recently downloaded gcc 2.2.2 and ran into this error when
installing. cc1plus fails to link due to two undefined symbols.
This was on a Sparc-1 (4/60) running SUN Os 4.1.2.

Any takers?		--Stuart


bambam# make install
cc -c    -g     -I. -I. -I./config \
  `echo ./cp-parse.c | sed 's,^\./,,'`
cc -c    -g     -I. -I. -I./config cp-decl.c
cc -c    -g     -I. -I. -I./config cp-decl2.c
cc -c    -g     -I. -I. -I./config cp-typeck.c
cc -c    -g     -I. -I. -I./config cp-type2.c
cc -c    -g     -I. -I. -I./config cp-tree.c
cc -c    -g     -I. -I. -I./config cp-ptree.c
cc -c    -g     -I. -I. -I./config cp-cvt.c
cc -c    -g     -I. -I. -I./config cp-search.c
cc -c    -g     -I. -I. -I./config cp-lex.c
cc -c    -g     -I. -I. -I./config cp-gc.c
cc -c    -g     -I. -I. -I./config cp-call.c
cc -c    -g     -I. -I. -I./config cp-class.c
cc -c    -g     -I. -I. -I./config cp-init.c
cc -c    -g     -I. -I. -I./config cp-method.c
cc -c    -g     -I. -I. -I./config cp-except.c
cc -c    -g     -I. -I. -I./config cp-expr.c
cc -c    -g     -I. -I. -I./config cp-pt.c
cc -c    -g     -I. -I. -I./config cp-edsel.c
cc -c    -g     -I. -I. -I./config cp-xref.c
cc -c    -g     -I. -I. -I./config cp-spew.c
cc    -g   -o cc1plus cp-parse.o cp-decl.o cp-decl2.o  cp-typeck.o cp-type2.o cp-tree.o cp-ptree.o  cp-cvt.o cp-search.o cp-lex.o cp-gc.o cp-call.o  cp-class.o cp-init.o cp-method.o cp-except.o  cp-expr.o cp-pt.o cp-edsel.o cp-xref.o   cp-spew.o c-common.o toplev.o version.o tree.o print-tree.o stor-layout.o fold-const.o  function.o stmt.o expr.o calls.o expmed.o explow.o optabs.o varasm.o  rtl.o print-rtl.o rtlanal.o emit-rtl.o  dbxout.o sdbout.o dwarfout.o xcoffout.o  integrate.o jump.o cse.o loop.o unro
ll.o flow.o stupid.o combine.o  regclass.o local-alloc.o global-alloc.o reload.o reload1.o caller-save.o  insn-peep.o reorg.o sched.o final.o recog.o reg-stack.o  insn-recog.o insn-extract.o insn-output.o insn-emit.o  insn-attrtab.o aux-output.o getpwd.o  obstack.o ` case "cc" in "cc") echo  ;; esac `  
ld: Undefined symbol 
   ___main 
   ___builtin_saveregs 
*** Error code 2
make: Fatal error: Command failed for target `cc1plus'
bambam# 

Newsgroups: gnu.gcc.bug
From: h.b.furuseth@usit.uio.NO
Subject: Re: Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 15:04:41 GMT

In article <9209050116.AA04670@skipsun.UUCP> skip@skipsun.UUCP (Skip Gilbrech) writes:
>				I would really appreciate (as would I'm
> quite sure many others) a command-line _option_ to totally disable
> built-in functions (and their prototypes).

I'd like builtins to have _default_ prototypes: `implicit declaration of
function BUILTIN' would give BUILTIN another type than int().  Gcc could
also check that any explicit or `implicit int()' declaration gives the
same call sequence as the built-in declaration - the program has a bug
otherwise.  Maybe -ansi -pedantic would warn about `conflicting types
for built-in function'.

This would still not accept `double memcpy(int, char *);' gracefully, but I
wouldn't trust a program which did that anyway.

An option to disable built-in functions would be nice in a few cases (ie
to use "debug" versions of the built-ins), but it would usually not be
necessary.


Hallvard

Newsgroups: gnu.gcc.bug
From: michael@stb.INfo.COM (Michael Gersten)
Subject: Compiler initialization -- reg+reg+offset test
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sat, 12 Sep 1992 02:18:00 GMT

I'm wondering if this is a bug or not, or if there's something subtle  
that I'm missing.

During initialization, gcc tried to see if reg+reg+offset is a legal  
addressing mode, by taking the frame pointer, adding it to itself,  
and a small constant 4.

Shouldn't this test be with a psuedo register, not a fixed register?  
Its possible that a machine may allow reg+reg only if one of the  
regs is in a small set (such as the military 1750), which need not  
be the frame pointer.

(In this case it ultimately doesn't matter, as the 1750 doesn't allow  
the sum to be offset.)
--
		Michael Gersten		michael@stb.info.com
HELLO! I'm a signature virus! Join in the fun and copy me into yours!
ex:.-1,. w $HOME/.signature

Newsgroups: gnu.gcc.bug
From: talvola@qin.berkeley.edu (Erik Talvola)
Subject: Problem in gcc v2.2.2 compilation under VMS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 18:04:59 GMT

GCC v2.2.2 under VAX-VMS, compiling with GCC v2.2.2

In rtl.c, ftell() is declared as:

extern long ftell();

But, in the VMS stdio.h header file, there is a definition
of ftell() as:

int ftell (FILE *file_ptr);

which causes the declaration in rtl.c to get an error message.
Either the rtl.c definition should be removed, or an #ifndef VMS
needs to be put around it.

--- Erik


Newsgroups: gnu.gcc.bug
From: kring@physik.uni-kl.DE (Thomas Kettenring)
Subject: GCC 2.2.2 on an Atari ST: address error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 21:05:29 GMT

I found a bug in GCC 2.2.2, PL2.  When I try to compile the following
program

        #include <float.h>

        main()
        {
            float x;

            x = -DBL_MAX;
        }
        
the compiler aborts with an `address error' in cc1.  Obviosly DBL_MAX cannot
be stored in a float, but I think it is not ok for the compiler to crash
in such a case.

I run GCC on an Atari ST.  The version I use is said to be compiled with
the MiNT libs (I don't know whether this makes a difference).

Jochen.

---
You can mail me at `kring@physik.uni-kl.de'.
Please use `c/o Jochen' in the Subject.

Newsgroups: gnu.gcc.bug
From: skip@skipsun.UUCP (Skip Gilbrech)
Subject: Re: Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 5 Sep 1992 22:06:51 GMT

I wrote:

>  And anyway, do you really want each of the thousands of people ...
>  to send in a report...
>

RMS replied:

>You seem to be urging the public to disregard my advice as to how to
>report bugs, on the grounds that you know better than I what they
>should do to be helpful.

That was NOT my intent, as I believe is clear from my original message.

My apologies to anyone else who may have drawn the same conclusion.

-Skip

-- 
Skip Gilbrech			email:	skip@fsg.com
Fusion Systems Group			uupsi!fsg!skip
225 Broadway, 24th Floor		uupsi!skipnyc!skip
New York, NY 10007		phones:	212-285-8001 (work)
					201-825-8732 (home)

Newsgroups: gnu.gcc.bug