HDTenEightyP/NetNews huggingface dataset:
From: pinard@icule.UUCP (Francois Pinard)
Subject: Problem with cp -pf and hard links
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 16:09:22 GMT

This relates to GNU fileutils 3.4, installed with GNU C 1.41 under
COFF encapsulation on this 386/ix 2.0.2 system.

The problem is that cp -pf destroy the hard link relationship of the
destination file, *if* that file was not writeable before the copy.

Here is the actual case.  I have ~/gnu/distrib/texinfo.tex (call it
$DESTIN) which is hard linked with texinfo.tex files in many
directories, used for making distributions.  $DESTIN has mode 444.
(This system does not have symbolic links.)  I am now unpacking a new
GNU package which provides a newer version of texinfo.tex, and want to
update not only $DESTIN from it, but also the hardlinked instances.

For reference, I have "cp() { /usr/local/gnubin/cp -i $*; }" in my
.bashrc, so all occurrences of cp imply -i.  If I merely execute:

	cp -pf texinfo.tex $DESTIN

with $DESTIN already existing with mode 444, then $DESTIN will receive
a copy of the newer texinfo with a hard link count of 1, while the
texinfo.tex's in the distribution directories stay undisturbed.

If I rather execute:

	chmod 644 $DESTIN
	cp -pf texinfo.tex $DESTIN

then $DESTIN will retain its previous hard link count and all copies
will be updated.  This is the behaviour I am expecting.

I would certainly need a cp, and even a mv, which reliably keeps the
previous hardlink relationships of the destination file, whatever the
destination file mode was.

-- 
Franc,ois Pinard       ``Happy GNU Year!''      pinard@iro.umontreal.ca
(514) 588-4656                                   ...!uunet!iros1!pinard
About the League for Programming Freedom?  Email me or lpf@uunet.uu.net

Newsgroups: gnu.utils.bug
From: krussell@dres.dnd.ca
Subject: gas-1.38.1 (sparc) incorrectly translating unimp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 07:05:31 GMT

gas-1.38.1
SparcStation 2
SunOS 4.1.1

I believe I have found a bug in gas-1.38.1 (and perhaps older
versions of gas as well).  If you run into an "Invalid Instruction"
error when executing a program assembled with gas, try patching gas
with the appended patch.  This bug bit me when I attempted to
build "perl-4.035" (I got an error when testing the "dbm" routines).

BUG SYNOPSIS
------------

  The "unimp const22" instruction is incorrectly translated in
  some cases.  The Sun-4 Assembly Language Reference Manual states:

      UNIMP         unimp   const22       Unimplemented instruction

  where gas-1.38.1 implies

      UNIMP         unimp   label         Unimplemented instruction

  The gas-1.38.1 implementation results in "22 bit PC relative
  immediate" addressing when "unimp n" is translated.  In some
  cases this can cause an "Invalid Instruction" error when the
  assembled program is run.

  The appended patch creates a new addressing mode (new for gas)
  called "22 bit Immediate" and instructs gas to use this mode
  when translating "unimp n".

BUG FIX
-------

diff -Nrc2 gas-1.38.1/sparc-opcode.h gas/sparc-opcode.h
*** gas-1.38.1/sparc-opcode.h	Thu Jun  7 14:22:10 1990
--- gas/sparc-opcode.h	Tue Dec 29 11:14:10 1992
***************
*** 59,62 ****
--- 59,63 ----
     h    22 high bits.
     i    13 bit Immediate.
+    I    22 bit Immediate.
     l    22 bit PC relative immediate.
     L    30 bit PC relative immediate.
***************
*** 498,502 ****
  { "tsubcctv",   0x80582000, 0x40a00000, "1,i,d", 0 },
  
! { "unimp",      0x00000000, 0x00000000, "l", 0 },
  
  { "iflush",     0x81d80000, 0x40202000, "1+2", 0 },
--- 499,503 ----
  { "tsubcctv",   0x80582000, 0x40a00000, "1,i,d", 0 },
  
! { "unimp",      0x00000000, 0x00000000, "I", 0 },
  
  { "iflush",     0x81d80000, 0x40202000, "1+2", 0 },
diff -Nrc2 gas-1.38.1/sparc.c gas/sparc.c
*** gas-1.38.1/sparc.c	Mon Oct 22 12:04:04 1990
--- gas/sparc.c	Tue Dec 29 11:20:11 1992
***************
*** 678,681 ****
--- 678,685 ----
  	    case 'i':   /* 13 bit immediate */
  	        the_insn.reloc = RELOC_BASE13;
+ 	        goto immediate;
+ 
+ 	    case 'I':   /* 22 bit immediate */
+ 	        the_insn.reloc = RELOC_BASE22;
  
  		/*FALLTHROUGH*/

--

Kevin Russell (DND/DRES/DTD/MSS/TDG)                    krussell@dres.dnd.ca
(403) 544-4736     DRE Suffield, Box 4000, Medicine Hat, AB, Canada, T1A 8K6

Newsgroups: gnu.utils.bug
From: mitra@pandora.sf.ca.us (Mitra)
Subject: gdbm: alloca on SCO
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 24 Dec 1992 03:18:38 GMT

I'm trying to get GDBM working on a SCO Unix box (without ODT), 
unfortunately it calls alloca which is not available under SCO, 
does anyone know if this has been ported to SCO?

- Mitra

Newsgroups: gnu.utils.bug
From: aoki@physics.ucla.edu (Ken-ichiro Aoki)
Subject: wanted option in tar: rsh -l option
Summary: want to remote tar as another user
Keywords: rsh -l, tar,
Organization: UCLA Department of Physics
Distribution: gnu
Date: Sun, 27 Dec 1992 01:52:30 GMT

version: tar-1.11.1 on NeXTstep3.0

We use GNU tar all the time for clearing disk space and also
for tape backups. It would be of great help to us if we could
use rsh -l option when tar calls rmt; namely to do remote
tarring as another user.

The situation is as follows; we have a cluster of three
NeXT's and we have no backup device for it. However,
we have access to a tape drive on a sun network which we
use to back up. Currently we are backing up as joe-user
who has an account on both clusters, but ideally, we would
like to backup as root on the local machine and rsh rmt as a joe-user.

Btw, I should mention that GNU tar is wonderful; with ordinary
tar we won't be able to do remote tar's. (not without pipes
and pain at least.) not to mention the other niceties of GNU tar.

Sorry if this has been mentioned too many times or if this
feature is already available unbeknowest to us.

Happy holidays and thank you for your time.
-- 
                        ___Kenichiro Aoki. (aoki@physics.ucla.edu)

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Meaning of `diff - -' ?
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 21:23:21 GMT

This is GNU diff 2.0, installed with GNU C 1.41 under COFF
encapsulation on a 386/ix 2.0.2 system, waiting for Hurd :-).

The command `diff - -' exits right away with status 0 without reading
standard input at all.  By contrast, `diff - /dev/null' reads standard
input until end of file.

It is not clear from the documentation what `diff - -' really means.
I would suggest that this particular case be caught and diagnosed as
improper usage, and be also documented as such.

-- 
Franc,ois Pinard       ``Happy GNU Year!''      pinard@iro.umontreal.ca
(514) 588-4656                                   ...!uunet!iros1!pinard
About the League for Programming Freedom?  Email me or lpf@uunet.uu.net

Newsgroups: gnu.utils.bug
From: gumby@tweedledumb.cygnus.com (D V Henkel-Wallace)
Subject: strip problem with Sunos 4.1.2
Organization: /0h/users/gumby/.organization
Distribution: gnu
Date: Sun, 20 Dec 1992 19:42:12 GMT

   Date: Thu, 17 Dec 1992 13:01:32 GMT
   From: carson@cs.columbia.edu (Carson A. Gaspar)

   Package: GNU binutils 2.0
   OS: Sunos 4.1.2
   Compiler: gcc 2.2.2

   After I strip a dynamically linked executable, ldd claims it is
   statically linked.  The executable still works, so it obviously is
   using the shared libraries.  What's going on?

BFD doesn't realize it can write a dynamic file.  Change strip to copy
the value of the dynamic flag from the input bfd to the output one.
From: rocky@watson.ibm.com (Rocky Bernstein)
Newsgroups: gnu.utils.bug
Subject: tar cv not reporting file name (in 1.11.1)
Date: 24 Dec 92 15:27:56 GMT
Reply-To: rocky@watson.ibm.com
Distribution: gnu
Organization: GNUs Not Usenet

In gnu tar-1.11.1, when I issue:
tar cv something*

I get blank lines for each file that is archived. Further
investigation reveals that the variable current_file_name
is not initialized on the create path; this is what print_header
uses. The fix I applied was to an assignment before calling
current_file_name = header->header.arch_name;


*** create.c	Thu Dec 24 19:56:04 1992
--- create.c~	Tue Sep  8 15:53:02 1992
***************
*** 1273,1283 ****
  		head = header;
  		/* hstat is already set up */
  		head_standard = f_standard;
- 		/* rocky@watson.ibm.com:
- 		   At this point, curr_file_name has not been initialized.
- 		   Initialize it.
-                 */
- 		current_file_name = header->header.arch_name;
  		print_header();
  	}

--- 1273,1278 ----
Newsgroups: gnu.gcc.bug
From: daveg@thymus.synaptics.COM (Dave Gillespie)
Subject: GCC 2.1 emits a bogus warning
Reply-To: daveg@synaptics.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 22 Dec 1992 14:27:06 GMT

While porting some code I got the warning,

> warning: class `foo' only defines private constructors and
> has no friends

which gave me a scare until I realized the class *did* have a
static member function which called "new foo" using the private
constructor.  In fact, I notice the warning even appears if I
put the function body using "new" right there in the class
definition!

This warning should probably be suppressed when there are
any public static member functions in the class.

A sample file:

--------
class foo {
  int x;
  foo(int y) { x = y; }
public:
  static foo *make(int a) { return new foo(a); }
};
--------

As far as I know, there is no way to get gcc to suppress this
warning, short of using "-w" to suppress all warnings.  It
would be nice if there were a way to suppress specific warnings,
e.g., a #pragma or special comment that would suppress all
warnings on the following line, or a command-line option that
would suppress all warning messages whose text contains a given
string.

								-- Dave

Newsgroups: gnu.gcc.bug
From: root@ibibel.glas.apc.ORG (Admin)
Subject: enquire fails : -( (Memory fault)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 23 Dec 1992 18:04:03 GMT

Dear sir,
ISC 3.0 (SDS 3.0), configure i386-isc, gcc 2.3.1 
		(there is NO gnu tools in /usr/local/bin & in the other places) 
enquire compiled with xgcc stage1 executed with -f opt(& without options too) 
fails with ~following msg:	memory fault
				core dumped
(when I compile enquire by cc (by hand) all just fine)
and that is the only error during building stage1 compiler.

xgcc stage1 compiled by cc from ISC's 3.0 SDS 3.0
xgcc stage2 fails to compile cse.c, varasm.c (& some others)
	with msg internal compiler's error got signal 11 (it's SIGSEGV)
	(or something like this)
almost all other stage3 object file mathch stage2 ones, 
but cp-method.o is *not*(it even differs in size from stage2 cp-method.o).

PS gcc2.3.1 comes non modifyed of course.
Thanx.
	Anton V.Tropashko (AGL)

Newsgroups: gnu.gcc.bug
From: jbotz@mtholyoke.EDU (Jurgen Botz)
Subject: Re: Bug in gcc-2.3.3 found while compiling Tk-3.0
Organization: Mount Holyoke College
Distribution: gnu
Date: Tue, 29 Dec 1992 15:34:53 GMT

In article <BzzHI7.HIr@mtholyoke.edu> I reported a bug in gcc-2.3.3, but
I was advised by rms that my bug report did not contain enough information
to be useful.  Sorry about that... I submitted it after having not gotten
any sleep in over 30 hours and I was a little out of it.  Here's a more
detailed report with a self contained example (extracted from Tk3.0 by
John Ousterhout, available from sprite.berkeley.edu)

gcc is version 2.3.3, built on a DECstation 3100 under Ultrix 4.2 with
"configure mips-dec-ultrix".  The version used was installed from the
third stage compilation.

Compiling the included example with optimization ("gcc -O -c test.c")
produces the following error message:

   test.c: In function 'TkBezierScreenPoint':
   test.c:54: fp_offset (16) or end_offset (-4) is less than zero.

Compiling the same file with gcc 2.3.2 ("gcc -V 2.3.2 -O -c test.c")
or with gcc 2.3.3 without optimization produces no error.  Brief
testing of Tk-3.0 with tkTrig.c compiled with 2.3.2 and everything
else with 2.3.3 (optimization on in both cases) seems to indicate that
2.3.2 compiles and optimizes this function correctly.

- Jurgen Botz, jbotz@mtholyoke.edu

--------- snip ----------------------------------------------------

/*
** Excerpt from tkTrig.c, tkCanvas.h & Xlib.h
**
** Tk is copyright 91, 92, Regents of the Univ. of California
*/

typedef struct {
    short x, y;
} XPoint;

#define SCREEN_X(canvasPtr, x) \
	(((int) ((x) + 0.5)) - (canvasPtr)->drawableXOrigin)
#define SCREEN_Y(canvasPtr, y) \
	(((int) ((y) + 0.5)) - (canvasPtr)->drawableYOrigin)

typedef struct {
    /* ... */
    int drawableXOrigin, drawableYOrigin;
    /* ... */
} Tk_Canvas;


void
TkBezierScreenPoints(canvasPtr, control, numSteps, xPointPtr)
    Tk_Canvas *canvasPtr;		/* Canvas in which curve is to be
					 * drawn. */
    double control[];			/* Array of coordinates for four
					 * control points:  x0, y0, x1, y1,
					 * ... x3 y3. */
    int numSteps;			/* Number of curve points to
					 * generate.  */
    register XPoint *xPointPtr;		/* Where to put new points. */
{
    int i;
    double u, u2, u3, t, t2, t3;

    for (i = 1; i <= numSteps; i++, xPointPtr++) {
	t = ((double) i)/((double) numSteps);
	t2 = t*t;
	t3 = t2*t;
	u = 1.0 - t;
	u2 = u*u;
	u3 = u2*u;
	xPointPtr->x = SCREEN_X(canvasPtr, (control[0]*u3
		+ 3.0 * (control[2]*t*u2 + control[4]*t2*u) + control[6]*t3));
	xPointPtr->y = SCREEN_Y(canvasPtr, (control[1]*u3
		+ 3.0 * (control[3]*t*u2 + control[5]*t2*u) + control[7]*t3));
    }
}







Newsgroups: gnu.gcc.bug
From: mitch@.UUCP (Mitchell N. Perilstein)
Subject: assignment from literal to double fails in 2.1
Organization: CAD Language Systems, Inc.
Distribution: gnu
Date: Sat, 2 Jan 1993 10:17:43 GMT

Assignment with type conversion from a literal to a double is broken.
gcc 2.1 on Sparc SunOS 4.1.2 and on RISC Ultrix 4.2 produces an
unexpected result: 

    convert int to double: -2147483648 -> -2147483648.000000
    convert lit to double: -2147483648 -> 2147483648.000000

I expected
    
    convert int to double: -2147483648 -> -2147483648.000000
    convert lit to double: -2147483648 -> -2147483648.000000

The vendor /bin/cc gave the second result on both platforms. Here is the
code. 

#define INT_MIN (-2147483648)	/* - (2^31) */

int main()
{
    double from_int, from_literal;
    int i;

    i = INT_MIN;
    from_int = i;
    printf("convert int to double: %d -> %f\n", i, from_int);

    from_literal = INT_MIN;
    printf("convert lit to double: %d -> %f\n", INT_MIN, from_literal);
}

Respectfully,
---
 Mitchell N. Perilstein   CAD Language Systems, Inc.   410-992-5700 x225 
 Member, League for Programming Freedom.  Mail lpf@uunet.uu.net for info.

Newsgroups: gnu.gcc.bug
From: beebe@math.utah.edu (Nelson H. F. Beebe)
Subject: "make doc" fails for gcc 2.3.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 01:29:02 GMT

The command "make doc" fails for gcc 2.3.3 because the file install1.texi
does not exist.  It is removed by the extraclean step, but nowhere created.


========================================================================
Nelson H. F. Beebe                      Tel: +1 801 581 5254
Center for Scientific Computing         FAX: +1 801 581 4148
Department of Mathematics, 105 JWB      Internet: beebe@math.utah.edu
University of Utah
Salt Lake City, UT 84112, USA
========================================================================

Newsgroups: gnu.gcc.bug
From: przemek@viewlogic.COM (Przemek Skoskiewicz)
Subject: fabs seems to be "broken" in 2.3.2...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 20:38:20 GMT

The following is a program that recreates the problem.  Basically, calling
fabs directly on any double number works fine.  But calling it the way I do
produces negative numbers for positive input.  This happens only with the
optimization; the debug version works fine.  This code has been around since
1.x versions of GCC and stopped working when we updated to 2.3.2 last week.
We've been using 2.2.2 for some time and I recompiled with that version and it
worked fine.  So, I suspect that the problem is with the new GCC version.

I've ran the code through cpp and all the parenthesis and macro substitutions
seemed all right.

I've compiled this code with `gcc foo.c -O4'.


#include "stdio.h"
#include "math.h"

typedef struct 
{
    unsigned short  line_number;
    union
    {
        struct
        {
            double data;
        } flonum;
        struct
        {
            long data;
        } fixnum;
    } storage_as;
} sexp, *sexpID;

#define FLONM(x)                    ((*x).storage_as.flonum.data)


static sexpID test(sexpID);
extern sexpID make_sexp(double);


sexpID make_sexp(number)
    double number;
{
    sexpID  x;

    x = (sexpID) malloc (sizeof (sexp));
    FLONM (x) = number;
    return (x);
}


static sexpID test(z)
    sexpID z;
{
    return (make_sexp (fabs (FLONM (z))));
}

/*
 * This macro is used very frequently in the code and originally caught the
 * problem--I thought that it was because it's a macro.  But then I wrote a
 * real function above, test, and it does the same thing.
 */
#define MATHLIB(proc, mathproc) \
    static sexpID proc(x) \
        sexpID x; \
    { \
          return (make_sexp (mathproc (FLONM (x)))); \
    }


MATHLIB (test1, fabs);


main()
{
    sexpID  xx;

    xx = (sexpID) malloc (sizeof (sexp));

    FLONM (xx) = 5;

    /*
     * Instead of printing `One: 5', both of these calls print `One: -5'.
     * Way too strange.
     */
    printf ("One: %g\n", FLONM (test1 (xx)));
    printf ("Two: %g\n", FLONM (test (xx)));
}



Viewlogic Systems, Inc.                         Przemek Skoskiewicz
293 Boston Post Road West
Marlborough, MA 01752-4615, USA
email: przemek@viewlogic.com

Newsgroups: gnu.gcc.bug
From: ler@lerami.lerctr.ORG (Larry Rosenman)
Subject: 2.3.3 amix bad float constant?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 06:58:21 GMT

I just ran into a bad float constant being generated by gcc 2.3.3
configured for amix....

for the constant 1.15 2.3.3 generated:  0x2800c5865

					  1.40.5 generated: 0x3ff2666666666666

the 2nd one is correct, the first one is some very small number...

any ideas ?

I may have a bad copy of one or more of the config files....


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

Newsgroups: gnu.gcc.bug
From: mycroft@hal.gnu.ai.mit.edu (Charles Hannum)
Subject: Floating point bug on 386BSD
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 23 Dec 1992 05:56:52 GMT

While building stage 1 on a machine running 386BSD:

bsdsux # ./xgcc -B./ -O0 -c foo.c
./xgcc: Internal compiler error: program cc1 got fatal signal 6
bsdsux # ./xgcc -DSECOND -B./ -O0 -c foo.c
foo.c: In function `fprop':
foo.c:30: floating constant out of range
bsdsux # 

`foo.c' originally came from `enquire.c'; the build failed because `enquire'
wouldn't compile properly.

Note that this happens with both 2.3.2 and the sources in /gd2/cc.

-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----
int fprop (int bits_per_byte) ;
void  efprop (int fprec, int dprec, int lprec) ;
 
int main(void) {
}
 
void fStore (float a, float *b)  { *b=a; }
#if SECOND
float fSum (float a, float b) { return 0.0; }
float fDiff (float a, float b) { return 0.0; }
float fMul (float a, float b) { return 0.0; }
#else
float  fSum  (float   a,  float   b)  {float  r; fStore (a+b, &r); return (r); }
float  fDiff  (float   a,  float   b) {float  r; fStore (a-b, &r); return (r); }
float  fMul  (float   a,  float   b)  {float  r; fStore (a*b, &r); return (r); }
#endif
int fprop (bits_per_byte) int bits_per_byte; {
	 
	volatile  int
		f_mant_dig;
	volatile  float 
		a, b, base;
	 
	b=1.0;
	do { b=fSum (b, b); } while ((base=fDiff (fSum (a, b), a)) == 0.0 );
	 
	f_mant_dig=0; b=1.0;
	do { f_mant_dig++; b=fMul (b, base); }
	while (fDiff (fDiff (fSum (b, 1.0 ), b), 1.0 ) == 0.0 );
	return f_mant_dig;
}
void  efprop (fprec, dprec, lprec) int fprec, dprec, lprec; {
	 
	volatile  int eprec;
	volatile  double base;
	volatile  float  d, oldd, dbase, one, zero;
	 
		eprec=0; d=1.0; dbase=base; one=1.0; zero=0.0;
			do { eprec++; oldd=d; d=d*dbase; }
			while ((((d+one)-d)-one) == zero && d>oldd);
}
-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----



Newsgroups: gnu.gcc.bug
From: eggert@bi.TWinsun.COM (Paul Eggert)
Subject: minor permissions problem in gcc 2.3.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Dec 1992 20:05:28 GMT

A file in gcc 2.3.3 is distributed with the executable bit turned on,
even though it's  not executable.  The following shell command patches this:

	chmod a-x config/xm-m68k.h


Newsgroups: gnu.gcc.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: gcc 2.3.3 bootstrap on IBM RT
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 15:03:28 GMT

gcc 2.3.3 does not bootstrap properly on an IBM RT running bsd 4.3.
I did:
	configure romp-aos
        make LANGUAGES=c

and got the same error as with 2.3.2 compiling obstack.c:

    hc -Hnocpp -c  -DIN_GCC     -I. -I. -I./config obstack.c
    E "obstack.h",L134/C1:	Can't open "stddef.h": No such file or directory

The problem is that the hc compiler defines __STDC__, yet does not
provide <stddef.h>.  It works to include gstddef.h, though, so I changed
obstack.h to use gstddef.h if STDDEF_H_MISSING is defined, and defined
it in config/x-romp.  Perhaps there is a better fix altogether.

I also added -w to x-romp.  hc's warnings are not useful.

karl@cs.umb.edu

Tue Dec 29 07:28:32 1992  Karl Berry  (karl@red.cs.umb.edu)

	* x-romp (CC): Include -w.

	* x-romp (CC): Include -DSTDDEF_H_MISSING.
        * obstack.h [STDDEF_H_MISSSING && IN_GCC]: Include gstddef.h
          instead of <stddef.h>.

*** ./ORIG/obstack.h	Sat Dec 26 01:55:47 1992
--- ./obstack.h	Tue Dec 29 06:04:53 1992
***************
*** 120,126 ****
     don't already have ptrdiff_t get it.  */
  
  #if defined (__STDC__) && ! defined (offsetof)
! #if defined (__GNUC__) && defined (IN_GCC)
  /* On Next machine, the system's stddef.h screws up if included
     after we have defined just ptrdiff_t, so include all of gstddef.h.
     Otherwise, define just ptrdiff_t, which is all we need.  */
--- 120,126 ----
     don't already have ptrdiff_t get it.  */
  
  #if defined (__STDC__) && ! defined (offsetof)
! #if (defined (__GNUC__) || defined (STDDEF_H_MISSING)) && defined (IN_GCC)
  /* On Next machine, the system's stddef.h screws up if included
     after we have defined just ptrdiff_t, so include all of gstddef.h.
     Otherwise, define just ptrdiff_t, which is all we need.  */
*** ./ORIG/x-romp	Mon Jul 27 20:00:31 1992
--- ./x-romp	Tue Dec 29 06:10:54 1992
***************
*** 2,8 ****
  # being used.  -Hnocpp makes hc use its builtin preprocessor instead of
  # /lib/cpp.  gcc doesn't use <sys/ioctl.h>, so it doesn't matter whether
  # fixincludes has been run.
! CC=hc -Hnocpp
  
  # The default `make' on the RT doesn't define MAKE, so do it here.
  MAKE=make
--- 2,14 ----
  # being used.  -Hnocpp makes hc use its builtin preprocessor instead of
  # /lib/cpp.  gcc doesn't use <sys/ioctl.h>, so it doesn't matter whether
  # fixincludes has been run.
! # 
! # hc's warnings do nothing but obscure the output, hence the -w.
! # 
! # hc defines __STDC__, yet <stddef.h> is missing, so we tell obstack.h
! # to use gstddef.h instead.
! # 
! CC=hc -Hnocpp -w -DSTDDEF_H_MISSING
  
  # The default `make' on the RT doesn't define MAKE, so do it here.
  MAKE=make

Newsgroups: gnu.gcc.bug