HDTenEightyP/NetNews huggingface dataset:
From: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab)
Subject: Bugs in CPP 2.2.2
Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 12:11:15 GMT

1. Hexadecimal numbers can confuse token parsing.

---- bug1.c
#define A 1

int i = 0x2e+A;
int j = 0x2e+ A;
----

Output of: gcc -E bug1.c
----
# 1 "bug1.c"


int i = 0x2e+A;
int j = 0x2e+ 1 ;
----

2. Macro parameters which are only to be stringified or concatenated, but
not exapanded are nevertheless expanded internally and can lead to
errors and strange effects.

---- bug2.c
#define k(a) #a

char *s = k(k(1,2));
char *t = k(#) k(#undef k) k(x);	/* feature?? */
----

Output of: gcc -E bug2.c
----
bug2.c:3: macro `k' used with too many (2) args
bug2.c:4: invalid preprocessor directive name
# 1 "bug2.c"


char *s = "k(1,2)" ;
char *t = "#"  "#undef k"  k(x);	 
----
--
Andreas Schwab
schwab@ls5.informatik.uni-dortmund.de

Newsgroups: gnu.gcc.bug
From: meissner@osf.ORG
Subject: another gcc-2.3.1 -msoft-float -O2 bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 12:56:51 GMT

I just put in a fix for all four of the -msoft-float bugs on the MIPS
into the FSF sources, and it should be in the next release (whenever
that is).  The bug was reload was dying because it couldn't allocate
any registers since normally it is told to strongly prefer the FP
registers.  I split the move patterns into two patterns, one for hard
floating point, and one for soft.

--
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: cliff@cs.cornell.edu (Cliff Krumvieda)
Subject: enums and gcc-2.3.1 (but not 2.2.2) cause dbx to dump core
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 07:03:36 GMT

Howdy:

The executable created by running gcc-2.3.1 on the short program below
causes dbx to dump core; the one created by gcc-2.2.2 works fine.
We're running gcc on sparcs and SunOS 4.1.1; configure was run as
"configure --target=sparc-sun-sunos4.1".  Also, "fixincludes" has been
installed.

======================================================================
#include <stdio.h>

typedef enum {HI, ALLO} greetings;

main()
{
   printf ("hello world\n");
}
======================================================================

Here's a script; note that gdb works ok:

======================================================================
[~] gemini% which dbx
/usr/ucb/dbx
[~] gemini% gcc -v
gcc version 2.3.1
[~] gemini% gcc -g bug.c
[~] gemini% a.out
hello world
[~] gemini% dbx a.out
Reading symbolic information...
Segmentation fault
[~/bug/kalantar] gemini% gdb a.out
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.7, Copyright 1992 Free Software Foundation, Inc...
(gdb) quit
[~] gemini% gcc-2.2.2 -v
Reading specs from /usr/local/gnu/gcc-2.2.2/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
[~] gemini% gcc-2.2.2 -g bug.c
[~] gemini% a.out
hello world
[~] gemini% dbx a.out
Reading symbolic information...
Read 108 symbols
(dbx) quit
======================================================================

							--Cliff
From: linstee@dutecaj.et.tudelft.nl (Erik van Linstee)
Newsgroups: gnu.gcc.bug
Subject: strlwr causes segmentation fault
Date: 5 Nov 92 11:31:48 GMT
Distribution: gnu
Organization: Delft University of Technology, Dept. of Electrical Engineering

Using strlwr in a piece of code resulted in a segmentation fault
under gcc 2.2.2 for OS/2. The string was not empty nor a NULL.
The program functions fine under BC so I guess it must be the
strlwr library call in OS/2.

Erik



-- 
Erik van Linstee   |   Delft University of Technology   |   I'll be back ... 
----
   We are god, 'cause only we can create the idea of his existence
   in our holy brains...  (Yello)
Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: cpp doesn't diagnose '\^X' (GCC 2.3.1)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 01:38:10 GMT

GCC 2.3.1 (sparc, SunOS 4.1.2) does not diagnose the syntax error in the first
line of the following program:

	#if '\^X'
	main() { return 0; }
	#endif

cc1 rejects '\^X', so the simplest fix is to have cpp reject it too:


Fri Nov  6 01:29:53 1992  Paul Eggert  (eggert@twinsun.com)

	* cexp.y (parse_escape): Don't accept '\^X'.

===================================================================
RCS file: cexp.y,v
retrieving revision 2.3
retrieving revision 2.3.1.1
diff -c -r2.3 -r2.3.1.1
*** cexp.y	1992/10/21 06:53:52	2.3
--- cexp.y	1992/11/06 01:29:53	2.3.1.1
***************
*** 764,776 ****
      case 0:
        (*string_ptr)--;
        return 0;
-     case '^':
-       c = *(*string_ptr)++;
-       if (c == '\\')
- 	c = parse_escape (string_ptr);
-       if (c == '?')
- 	return 0177;
-       return (c & 0200) | (c & 037);
        
      case '0':
      case '1':
--- 764,769 ----

Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: fix for -fpic core dump (GCC 2.3.1, sparc)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 04:12:46 GMT

gcc 2.3.1 (Sparc, SunOS 4.1.2) with just the -fpic option (or with just the
-fPIC option) dumps core when compiling the following program:

	main() { printf("Hello world\n"); }

The problem is that simplify_subtraction invokes decode_rtx_const on pc_rtx,
and decode_rtx_const doesn't know what to do if GET_CODE yields PC.  Here is a
workaround.


Thu Nov  5 01:53:38 1992  Paul Eggert  (eggert@twinsun.com)

	* varasm.c (simplify_subtraction): Don't invoke decode_rtx_const
	on PC; it won't know what do to with it.


===================================================================
RCS file: varasm.c,v
retrieving revision 2.3
retrieving revision 2.3.1.1
diff -c -r2.3 -r2.3.1.1
*** varasm.c	1992/10/29 22:29:57	2.3
--- varasm.c	1992/11/05 04:01:34	2.3.1.1
***************
*** 2214,2219 ****
--- 2214,2222 ----
  {
    struct rtx_const val0, val1;
  
+   if (XEXP (x, 0) == pc_rtx || XEXP (x, 1) == pc_rtx)
+     return XEXP (x, 0) == XEXP (x, 1) ? const0_rtx : x;
+ 
    decode_rtx_const (GET_MODE (x), XEXP (x, 0), &val0);
    decode_rtx_const (GET_MODE (x), XEXP (x, 1), &val1);
  

Newsgroups: gnu.gcc.bug
From: heusch@engels2.cs.uni-duesseldorf.de (Peter Heusch)
Subject: gcc.2.3.1 and ISC 3.0
Keywords: ISC gcc-2.3.1 floating point
Reply-To: heusch@cs.uni-duesseldorf.de (Peter Heusch)
Organization: Universitaet Duesseldorf
Distribution: gnu
Date: Tue, 10 Nov 1992 17:31:01 GMT

Hello world,

can anybody tell me what's wrong with floating point on Interactive SVR3, 3.0?

Just recently, I tried to compile gcc-2.3.1 on my AT/386. Everything went fine
until compiling enquire.c. When executing the resulting binary, the program
gave lots of error messages indicating, that results are not quite what was
expected in floating point arithmetic. Just when executing the following 
peace of code, enquire finally crashes:

long double a=634.....(lots of 0-s),b=2.0;
long double c=a*b;

With the default floating point emulator file /etc/emulator.dfl, the program
crashes earlier, but when compiling the given two lines as only lines in
the program, I get a SIGFPE. Now my question: 

a) Is this a bug in the emulator, or is it a bug in gcc-2.3.1
b) Will it help to install a FPU 80387?
c) Does anybody know about incorrect behaviur of the floating point emulator
   in ISC 3.0 (Their german distributor doesn't)


Many thanks


Peter
From: karl@claude.cs.umb.edu (Karl Berry)
Newsgroups: gnu.gcc.bug
Subject: gcc 2.3.1 miscellany
Date: 11 Nov 92 05:56:19 GMT
Article-I.D.: claude.199211111556.AA01978
Reply-To: karl@cs.umb.edu
Distribution: gnu
Organization: Gnus Not Usenet

* The GCC 2.3.1 distribution doesn't have a NEWS file.


* The install target doesn't install the info files, and the realclean
target doesn't remove usegcc.info*.


* The cp-parse.c and cp-parse.h files in the distribution were older than
cp-parse.y.


* The new node `Newlines in Args' in cpp.texi has a typo:

   result can can be incorrect line numbers, in error messages or

There should be only be one `can'.
Newsgroups: gnu.gcc.bug
From: joe@modcomp.COM (Joe Korty)
Subject: gcc2.3.1: configure --prefix bug & fix
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 19:26:10 GMT

The addition of the family of --prefix options to `configure' broke the
ability to specify prefix information in the `config/x-*' makefile fragments.
What happens is that, if no --prefix option is specified, the prefix is
always set to `/usr/local', irrespective of the value in the machine
configuration file.

The following patch causes configure to use --prefix if available, otherwise
uses the config/x-* file value if available, otherwise defaults the prefix
to /usr/local.  It also fixes a similar problem in --exec-prefix.

This problem is new to 2.3.1.

-- 
Joe Korty,  REAL/IX Operating Systems

MODCOMP, an AEG Company			Telephone: (305) 977-1820
1650 West McNab Road			Fax:	   (305) 977-1638
P.O. Box 6099				E-mail:	   uunet!modcomp!joe
Ft. Lauderdale, FL 33309-1088

diff -r -c /work3/joe/gcc-2.3.1-base/configure /work4/joe/gcc-2.3.1/configure
*** /work3/joe/gcc-2.3.1-base/configure	Sun Nov  1 03:25:32 1992
--- /work4/joe/gcc-2.3.1/configure	Tue Nov 10 10:54:48 1992
***************
*** 54,61 ****
--- 54,63 ----
  
  # Default prefix to /usr/local.
  prefix=/usr/local
+ prefix_name=SomeJunkString
  # Default is to let the Makefile set exec_prefix from $(prefix)
  exec_prefix='$(prefix)'
+ exec_prefix_name=SomeJunkString
  
  remove=rm
  hard_link=ln
***************
*** 132,137 ****
--- 134,140 ----
  	;;
       -prefix=* | --prefix=* | --prefi=* | --pref=* | --pre=* | --pr=* | --p=*)
  	prefix=`echo $arg | sed 's/-*p[a-z]*=//'`
+ 	prefix_name=prefix
  	;;
       -exec-prefix | --exec-prefix | --exec-prefi | --exec-pref | --exec-pre \
  	| --exec-pr | --exec-p | --exec- | --exec | --exe | --ex | --e)
***************
*** 141,146 ****
--- 144,150 ----
  	| --exec-pre=* | --exec-pr=* | --exec-p=* | --exec-=* | --exec=* \
  	| --exe=* | --ex=* | --e=*)
  	exec_prefix=`echo $arg | sed 's/-*e[-a-z]*=//'`
+ 	exec_prefix_name=exec_prefix
  	;;
       -with-gnu-ld | --with-gnu-ld | --with-gnu-l)
  	gnu_ld=yes
***************
*** 1256,1263 ****
  sed -e "s///" -e "s/^target=.*$/target=${target}/" \
      -e "s|^xmake_file=.*$|xmake_file=${host_xmake_file}|" \
      -e "s|^tmake_file=.*$|tmake_file=${tmake_file}|" \
!     -e "s|^prefix[ 	]*=.*|prefix = $prefix|" \
!     -e "s|^exec_prefix[ 	]*=.*|exec_prefix = $exec_prefix|" \
      -e "s|^FIXINCLUDES[ 	]*=.*|FIXINCLUDES = $fixincludes|" \
      Makefile.tem > Makefile.xx
  rm -f Makefile.tem
--- 1265,1272 ----
  sed -e "s///" -e "s/^target=.*$/target=${target}/" \
      -e "s|^xmake_file=.*$|xmake_file=${host_xmake_file}|" \
      -e "s|^tmake_file=.*$|tmake_file=${tmake_file}|" \
!     -e "s|^${prefix_name}[ 	]*=.*|prefix = $prefix|" \
!     -e "s|^${exec_prefix_name}[ 	]*=.*|exec_prefix = $exec_prefix|" \
      -e "s|^FIXINCLUDES[ 	]*=.*|FIXINCLUDES = $fixincludes|" \
      Makefile.tem > Makefile.xx
  rm -f Makefile.tem

Newsgroups: gnu.gcc.bug
From: michael@odie.cs.mun.ca (Mike Rendell)
Subject: Problem with mips-mips-riscos5bsd target, +fix
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 10:35:25 GMT

Environment: gcc 2.3.1 on Mips M/120 running Risc/os 5.00

When compiling gcc with target mips-mips-riscos5bsd, the compile fails
in stage 2 because the rusage structure is not defined.  This problem occurs
because _SYSTYPE_BSD43 is not defined in the CPP_PREDEFINES in
config/mips-5bsd.h (SYSTYPE_BSD43 is, but both are needed).  The
following diffs fix this problem and similar problems in the svr4 and
sysv environments.


*** mips-5bsd.h.orig	Sat Sep 26 19:32:54 1992
--- mips-5bsd.h	Wed Nov  4 14:37:37 1992
***************
*** 19,25 ****
  
  #define MIPS_BSD43
  
! #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_BSD43"
  
  #define SYSTEM_INCLUDE_DIR "/bsd43/usr/include"
  
--- 19,26 ----
  
  #define MIPS_BSD43
  
! #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_BSD43 \
! -D_mips -D_unix -D_host_mips -D_MIPSEB -D_R3000 -D_SYSTYPE_BSD43"
  
  #define SYSTEM_INCLUDE_DIR "/bsd43/usr/include"
  
*** mips-5svr4.h.orig	Sat Sep 26 19:32:56 1992
--- mips-5svr4.h	Wed Nov  4 14:37:50 1992
***************
*** 19,25 ****
  
  #define MIPS_SVR4
  
! #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_SVR4"
  
  #define SYSTEM_INCLUDE_DIR "/svr4/usr/include"
  
--- 19,26 ----
  
  #define MIPS_SVR4
  
! #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_SVR4 \
! -D_mips -D_unix -D_host_mips -D_MIPSEB -D_R3000 -D_SYSTYPE_SVR4"
  
  #define SYSTEM_INCLUDE_DIR "/svr4/usr/include"
  
*** mips-5sysv.h.orig	Sat Sep 26 19:32:57 1992
--- mips-5sysv.h	Wed Nov  4 14:37:56 1992
***************
*** 19,25 ****
  
  #define MIPS_SYSV
  
! #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_SYSV"
  
  #define SYSTEM_INCLUDE_DIR "/sysv/usr/include"
  
--- 19,26 ----
  
  #define MIPS_SYSV
  
! #define CPP_PREDEFINES "-Dmips -Dunix -Dhost_mips -DMIPSEB -DR3000 -DSYSTYPE_SYSV \
! -D_mips -D_unix -D_host_mips -D_MIPSEB -D_R3000 -D_SYSTYPE_SYSV"
  
  #define SYSTEM_INCLUDE_DIR "/sysv/usr/include"
  

--
Michael Rendell - Dept. of Comp. Sci., Memorial University of Newfoundland

Newsgroups: gnu.gcc.bug
From: djm@dagmar.cray.com (Dave Miller)
Subject: incompatibility in g++ version 2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 23:28:46 GMT

I've been using g++ to run through a course book on c++ from AT&T.  I've found
one incompatibility with the AT&T version.

In the course text it clearly specifies that the "=" operator does not need to
be overloaded/defined for a class to itself.  It states that because of
the compatibility with C and C's ability to assign a structure to another,
it is not necessary to do that definition.  We do have an AT&T version on
another machine here and I did verify that was true.

For example, given a class:

    class String {

    public:
	...

    private:
	char text[128];
    }

it is possible in a program to:

    String a, b;

    a = b;

without defining the operator.  This doesn't work in g++ but does in the AT&T
version.

Not a biggie, but I thought I could report it anyway.

Dave Miller
Cray Research, Inc.

Newsgroups: gnu.gcc.bug
From: linstee@dutecaj.et.tudelft.nl (Erik van Linstee)
Subject: problem linking file when similar dirname
Organization: Delft University of Technology, Dept. of Electrical Engineering
Distribution: gnu
Date: Tue, 10 Nov 1992 20:35:14 GMT

I just tried to link some files having names like
rcs*.exe (under OS/2). Previously there was no problem
though this time it gave me a rcs: access denied.
That was only natural since I just made a subdir named
rcs. However, the linked file should be named rcs.exe
instead of rcs, so whats the problem?
BTW. everything is fine again when the dir rcs is renamed.

Erik



-- 
Erik van Linstee   |   Delft University of Technology   |   I'll be back ... 
----
   We are god, 'cause only we can create the idea of his existence
   in our holy brains...  (Yello)


Newsgroups: gnu.gcc.bug
From: joe@modcomp.COM (Joe Korty)
Subject: gcc-2.3.1: g++ doesn't handle -l well
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 19:56:47 GMT

The script g++ fails to correctly link the below c++ program, since the place
it puts the -lg++ in the underlying call to gcc is *after* any user-specified
-l options, not before.  This causes link edit failures, since some routines
in -lg++ call routines in -lmath, and there is no way using g++ that -lmath
can be specified after the embedded -lg++.



	g++ complex.C -lmath			link failures
	gcc complex.C -lmath -lg++		what the above invokes
	gcc complex.C -lg++ -lmath		works

A possible ad-hoc is for g++ to append `-lg++ -lmath' to the command
line, not just `-lg++'.

This was run on an m88k system V release 3 style OS.

-- 
Joe Korty,  REAL/IX Operating Systems

MODCOMP, an AEG Company			Telephone: (305) 977-1820
1650 West McNab Road			Fax:	   (305) 977-1638
P.O. Box 6099				E-mail:	   uunet!modcomp!joe
Ft. Lauderdale, FL 33309-1088

*** /usr/nosupport/bin/g++	Tue Sep  8 17:38:59 1992
--- /usr/nosupport/bin/gpp	Thu Nov 12 14:53:43 1992
***************
*** 4,10 ****
  
  newargs=
  quote=no
! library=-lg++
  havefiles=
  
  for arg in $*;
--- 4,10 ----
  
  newargs=
  quote=no
! library='-lg++ -lmath'
  havefiles=
  
  for arg in $*;
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.gcc.bug
Subject: Re: .i files from C++
Date: 12 Nov 92 19:10:30 GMT
Distribution: gnu
Organization: U. C. Berkeley

In article <9211111842.AA14080@demidoff.cs.utk.edu> pozo@cs.utk.edu writes:
>After reading the man page for gcc/g++, I'm still not sure how to see
>the intermediate C code from g++.  What flag do I specify on the 
>command line? 

There is no intermediate C code from g++.  It goes straight to assembler,
as most non-cfront-derived C++ compilers do.

Furthermore, it appears, from work presented at the Usenix C++ Conference
in Portland, that there is a substantial performance penalty for any
attempt at a portable implementation of exceptions if you are required to
produce C code.  Unless major mistakes were made, this suggests that in
the future, compilers like cfront will fade away since they won't be able
to compete with straight-to-assembler implementations.


--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.gcc.bug
From: jdeifik@isi.edu (Jeff Deifik)
Subject: problem with make doc gcc-2.3.1 vax-dec-ultrix
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 01:04:39 GMT

I have gcc-2.3.1, configured for vax dec ultrix.
I have a vax 11/750 running ultrix-4.2.
When I say make doc, I get the message:
make: *** No way to make target `install1.texi'.  Stop.

I am using gnu make 3.62.
Any ideas?

Newsgroups: gnu.gcc.bug
From: jim@meiko.co.UK (James Cownie)
Subject: Performance feature
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 14:14:14 GMT

Using the cygnus-2.0.2 release of GCC running on Solaris 2.0 on a
SPARC I have observed the following non-fatal "feature".

Code in "do_jump (exp, if_false_label, if_true_label)" in the file
expr.c has the effect of narrowing bitwise and operations to smaller
modes than those written in the code. This occurs even if the machine
description macros set SLOW_BYTE_ACCESS to be 1.

The effect of this can be that code like this --

int Poll_Event (event)
unsigned  int *event;
{
   unsigned  int *a = &event[1];

   return (a[0] & 1) ? 1:0;
}
 
when compiled thus :-
gcc -S foo.c -O2 

generates code like this
	.file	"foo.c"
	.section	".text"
	.align 4
	.global Poll_Event
	.type	 Poll_Event,#function
Poll_Event:
	!#PROLOGUE# 0
	!#PROLOGUE# 1
	ldub [%o0+7],%o0
	retl
	and %o0,1,%o0
.LLfe1:
	.size	 Poll_Event,.LLfe1-Poll_Event
	.ident	"GCC: (GNU) cygnus-2.0.2"

which accesses store as a byte, rather than as an int (which was what
the user said, and which should be faster than the byte access).

The relevant compiler code is (as above) in "do_jump" in expr.c, and
looks like this

    case BIT_AND_EXPR:
      /* If we are AND'ing with a small constant, do this comparison in the
	 smallest type that fits.  If the machine doesn't have comparisons
	 that small, it will be converted back to the wider comparison.
	 This helps if we are testing the sign bit of a narrower object.
	 combine can't do this for us because it can't know whether a
	 ZERO_EXTRACT or a compare in a smaller mode exists, but we do.  */
      if (TREE_CODE (TREE_OPERAND (exp, 1)) == INTEGER_CST
	  && TYPE_PRECISION (TREE_TYPE (exp)) <= HOST_BITS_PER_INT
	  && (i = floor_log2 (TREE_INT_CST_LOW (TREE_OPERAND (exp, 1)))) >= 0
	  && (type = type_for_size (i + 1, 1)) != 0
	  && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (exp)))
	{
	  do_jump (convert (type, exp), if_false_label, if_true_label);
	  break;
	}
      goto normal;

I'd suggest that maybe this should be surrounded with
#if (!SLOW_BYTE_ACCESS)
...
#endif

but maybe there's a better solution ?

Thanks in advance. Keep up the good work.

-- Jim
James Cownie 
Meiko Limited
650 Aztec West
Bristol BS12 4SD
England

Phone : +44 454 616171
FAX   : +44 454 618188
E-Mail: jim@meiko.co.uk or jim@meiko.com


Newsgroups: gnu.gcc.bug
From: simon@lia.di.epfl.CH (Simon Leinen)
Subject: Re: gcc-2.3.1 breaks oleo-1.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 8 Nov 1992 18:42:00 GMT

In article <368@eileen.mga.COM> root@mga.COM (Operator) writes:

   gcc -O -c -g  -DSTDC_HEADERS=1 -DHAVE_X11_X_H=1 -DHAVE_UALARM=1 -DHAVE_SETITIMER=1 -DHAVE_RENAME=1 -DHAVE_VPRINTF=1  io_utils.c
   as: "/usr/tmp/cca23933.s", line 111: error: location counter not on word boundary

This happens inside a sequence of asm() statements, so it's not really
GCC's fault---try the patch below.
-- 
Simon.

--- 1.1	1992/11/08 18:38:47
+++ io_utils.c	1992/11/05 11:15:26
@@ -64,6 +64,9 @@
 
 #ifndef ASM_INF
 #if defined(__GNUC__) && ! defined(mips)
+#if defined(sparc)
+__asm (".align 4");
+#endif
 __asm (".globl ___plinf");
 __asm ("___plinf: .double 0rinf");
 __asm (".globl ___neinf");

Newsgroups: gnu.gcc.bug
From: mjhostet@slayer.mit.edu (Mathew J. Hostetter)
Subject: gcc 2.3.1: Trivial objective C code causes gcc to crash on signal 10
Reply-To: mjhostet@athena.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 7 Nov 1992 18:43:25 GMT

My system is a 68040 NeXT running NeXTSTEP 3.0, gcc 2.3.1.  Compiling  
this code with "gcc -x objective-c foo.c" causes gcc to crash on  
signal 10.

-Mat


typedef struct objc_class *Class;

typedef struct objc_object {
  Class isa;
} *id;

void
foo (id x)
{
  [x blah];
}
From: chaplin@keinstr.UUCP (Roger Chaplin)
Subject: Re: How to use 'return' in c?
Followup-To: gnu.gcc.bug
Organization: Keithley Instruments, Cleveland, Ohio
Distribution: gnu
Date: Fri, 6 Nov 1992 23:15:12 GMT

Rich Wenner (wenner@einstein.eds.com) wrote:
: In article <1992Nov4.231347.26999@u.washington.edu> chuckb@stein.u.washington.edu (Charles Bass) writes:
: :After several people wrote me on the use of EXIT_SUCCESS and
: :EXIT_FAILURE  and their inability to locate those files on their
: :systems I checked K&R 2ndEd for the definitive answer...
: 
: Since when is K&R2 the Standard?
: 
: :" void exit(int status)
: :... How status is returned to the environment is
: :implementation-dependent, but zero is taken as successful
: :termination.  The values EXIT_SUCCESS and EXIT_FAILURE may also
: :be used."                                              ^^^
: :
: :Because the word *may* is used I must assume that you either get
: :it or you don't depending on your compiler/OS.
: 
: Don't assume.  RTFS, which simply states that these macros are defined in
: stdlib.h.  See section 4.10.

<Sigh>.  I just retrieved and built gcc-2.3.1, and these *still* aren't
in there.

Notice that followups are directed to gnu.gcc.bug.

-- 
Roger Chaplin / Instruments Division Engineering / 14 million women will not
chaplin@keinstr.uucp / CI$: 76307,3506          / have the right to choose -
#include <disclaimer.h>                        / they have been aborted.
#include "disclaimer.h" /* cover all bases */ / 

Newsgroups: gnu.gcc.bug