HDTenEightyP/NetNews huggingface dataset:
From: pierre@la.tce.COM (Pierre Willard)
Subject: #define multi-lined strings
Reply-To: pierre@la.tce.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 19:06:08 GMT

There is a bug in the preprocessor of gcc 2.1 and 
gcc-1.40.

It is possible to write a #define which will generate several C lines
in the preprocessed file. This makes bad line numbers. This happens
when using a multi-lined string in a #define.

I guess the fix is for cpp to translate a mutli-lined string in a
#define into a one line string (ie use '\n').

In the example below, cpp should output :

"just\na little\nmulti-lined\nstring"; foo(x)

The following demonstrates the problem.

psi:/usr2/pierre:cat pw.c

#define FOOO x = "just
a little
multi-lined
string"; foo(x)

void
foo(char *x)
{

}

main()
{
char *x;

  FOOO;
}
psi:/usr2/pierre:gcc -E pw.c
# 1 "pw.c"






void
foo(char *x)
{

}

main()
{
char *x;

  x = "just
a little
multi-lined
string"; foo(x) ;
# 18 "pw.c"
}
psi:/usr2/pierre:gcc -v -g -O -o pw pw.c
Reading specs from /usr/local/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/sun4/2.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -D__OPTIMIZE__ -g pw.c /usr/tmp/cca24573.i
GNU CPP version 2.1 (sparc)
 /usr/local/lib/gcc-lib/sun4/2.1/cc1 /usr/tmp/cca24573.i -quiet -dumpbase pw.c -g -O -version -o /usr/tmp/cca24573.s
GNU C version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o pw.o /usr/tmp/cca24573.s
 /usr/local/lib/gcc-lib/sun4/2.1/ld -e start -dc -dp -o pw /lib/crt0.o -L/usr/local/lib/gcc-lib/sun4/2.1/ -L/usr/local/lib/ pw.o -lgcc -lc -lg -lgcc
psi:/usr2/pierre:gdb pw
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.5, Copyright 1992 Free Software Foundation, Inc...
(gdb) b main
Breakpoint 1 at 0x22cc: file pw.c, line 17.
(gdb) run
Starting program: /usr2/pierre/pw 

Breakpoint 1, main () at pw.c:17
17	  FOOO;
(gdb) n
Line number 20 out of range; pw.c has 18 lines.
(gdb) quit
The program is running.  Quit anyway? (y or n) y
psi:/usr2/pierre:

Let me know your comments.
Regards
Pierre Willard


Newsgroups: gnu.gcc.bug
From: kambiz@booboo.INdetech.COM (Kambiz Aghaiepour)
Subject: bug with dependency generation - fixed?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 01:43:00 GMT

Can someone please send me the patches to make this work?

--Kambiz 

------- Start of forwarded message -------
From: uunet!cygnus.com!mrs (Mike Stump)
To: prep.ai.mit.edu!bug-g++, indetech.com!kambiz
Subject: Re:  Bug with dependency generation g++2.2.2
Date: Tue, 1 Sep 92 18:59:03 PDT

I believe this problem has been fixed, you can ask over in bug-gcc if
it has for sure.

Yes, probably most people that use the extension .cxx have.

> Date: Fri, 28 Aug 92 17:29 PDT
> To: bug-g++@prep.ai.mit.edu
> From: Kambiz Aghaiepour   <kambiz@indetech.com>
> Message-Id: <KAMBIZ.92Aug28172309@booboo.indetech.com>

> System: sun4 (IPC) running sunOS 4.1.x with GNU gcc/g++ version 2.2.2

> Has anyone else experienced this problem?

> ------- Start of forwarded message -------
> From: tilman (Tilman Sporkert)
> To: kambiz (Kambiz Aghaiepour)
> Date: Tue, 4 Aug 92 13:13:41 PDT

> It appears that dependency generation with the new compiler is broken. The
> output of "g++ -MM" looks like:

>    allowance_tables.cxx.o : allowance_tables.cxx ../../tilman/util/ItiString.hxx \
>   ../../tilman/util/ItiObject.hxx ../../tilman/util/ItiObjMacros.hxx ../../tilman/main/r2drug_svc.hxx \


> Please note that it says "allowance_tables.cxx.o", not "allowance_tables.o"!
> ------- End of forwarded message -------
------- End of forwarded message -------

Newsgroups: gnu.gcc.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: missing warning?
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 10:53:12 GMT

The following (meaningless) two-line program does not get a warning when
compiled with -Wall on a 486 running Interactive Unix (configured as
`--with-gnu-as i386-isc').  (I doubt this is a machine-dependent
phenomenom.)

static void foo ();
void foo () { foo (); }

bash$ gcc -v -c -Wall /tmp/test.c
Reading specs from /usr/local/gnu/lib/gcc-lib/i386-isc/2.2.2/specs
gcc version 2.2.2
 /usr/local/gnu/lib/gcc-lib/i386-isc/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dunix -Di386 -D__unix__ -D__i386__ -D__unix -D__i386 -Wall /tmp/test.c /tmp/cca04478.i
GNU CPP version 2.2.2 (80386, BSD syntax)
 /usr/local/gnu/lib/gcc-lib/i386-isc/2.2.2/cc1 /tmp/cca04478.i -quiet -dumpbase test.c -Wall -version -o /tmp/cca04478.s
GNU C version 2.2.2 (80386, BSD syntax) compiled by GNU C version 2.2.1.
 /usr/local/gnu/lib/gcc-lib/i386-isc/2.2.2/as -o test.o /tmp/cca04478.s
bash$ 

Since having the `static' on only the definition provokes a warning, I
expected the converse -- having `static' only on the declaration -- to do
so also.

Apologies if I missed this in the documentation.

karl@cs.umb.edu

Newsgroups: gnu.gcc.bug
From: cohen@merak.greco-prog.fr (Henri Cohen)
Subject: Bug reports
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 16:48:42 GMT

Compiler version: gcc-2.2.2

1) The protoize program seems to have a bug in its parser: identifiers
starting with "const" are not interpreted correctly. For example
"constfoobar" is transformed into "obar". As far as I can tell,
constfoobar is a perfectly valid ANSI C or C++ identifier (const
itself is not of course).

2) I have been unable to make the stage 2 g++ compiler on a Sony
NeWS1200. In fact, the config file news.h does not contain a line
for this system (MC68030 with MC68882), but the impossibility of
compilation remains even when this line is added. Symptom: the stage 2
compilation and installation works fine, and when a not completely
trivial program is compiled, we get the message "Internal compiler
error 10". The stage 1 compiler (compiled using cc) partially works
(it crashes on some libg++ tests).

3) In the file math-68881.h:

	a) Function pow, there are 2 asm statements

              __asm ("fmove%.d %#0x7fffffffffffffff,%0"         /* quiet NaN */

For some machines this gives an assmbler warning: quad to d_float
conversion loses significance. This disappears if fmove%.d is
replaced by fmove%.x. Is this a correct modification?

	b) Function hypot (line 291), I always get the warning:
float or double assigned to integer data type. I cannot understand where
an integer data type is present. This occurs whenever a program is
compiled and linked, for example during the construction of the
libg++ library.

	Sincerely yours,

H. Cohen

cohen@alioth.greco-prog.fr
cohen@geocub.greco-prog.fr


Newsgroups: gnu.gcc.bug
From: walter@galena.UUCP (Walter Hunt)
Subject: gcc 2.2.2 and abort()
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 00:28:42 GMT

@	I recently compiled up gcc 2.2.2 for my machine, with the
    intent of doing some C++ programming. While compiling, I found one
    of the files in my distribution to be corrupted. There may have
    been further corruptions, but if there were, they resulted in
    valid 'C' code since a "make bootstrap" completed fine. This may
    or may not have anything to do with my results.

	I then retrieved libg++-2.0, in order to have some basic C++
    classes. While attempting to compile it, gcc (actually cc1plus)
    bombed out with an abort at line 207 of file cp-tree.c. (Like so:

(gdb) run
Starting program: /usr/local/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca28407.i -quiet -dumpbase BitSet.cc -version -o /usr/tmp/cca28407.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.

Program received signal 6, Abort
0xf775c120 in kill ()
(gdb) where
#0  0xf775c120 in kill ()
#1  0xf777447c in abort ()
#2  0x3a7b8 in break_out_calls (exp=0x1770b8) at cp-tree.c:207
#3  0x3a7e0 in break_out_calls (exp=0x1770c8) at cp-tree.c:217
#4  0x3a848 in break_out_calls (exp=0x1770e8) at cp-tree.c:234
#5  0x3464c in build_modify_expr (lhs=0x1770e8, modifycode=NOP_EXPR, 
    rhs=0x1770a8) at cp-typeck.c:5157
#6  0xe894 in yyparse () at cp-parse.y:1211
#7  0x7b9c0 in compile_file (name=0xf7fff992 "/usr/tmp/cca28407.i")
    at toplev.c:1638
#8  0x7e584 in main (argc=8, argv=0xf7fff8e4, envp=0xf7fff908) at toplev.c:3055
(gdb) 


	After some quick #if 0's, I determined that the line that was
    making it croak was line 768 of BitSettoa.cc, which contained:

      *fmt++ = (a & 1)? t : f;

	Changing the line (and two more just like it in the same
    routine) to either of:

      if (a & 1) *fmt++ = t;
      else *fmt++ = f;

	or

      *fmt = (a & 1)? t : f;
      fmt++;

	would compile fine.


	Does this happen with the "official" 2.2.2 (i.e. do I have a
    improperly built version)? Any chance of getting on a mailing list
    for patches?

	If it matters, I got all my sources from a uunet tape,
    purchased a couple months ago.


Walter Hunt					walter@optimage.com
OptImage Interactive Services Company, L.P.	walter@aimla.com
11040 Santa Monica Blvd., Suite #300		uunet!{optimage,aimla}!walter
Los Angeles, Ca. 90025				(310) 445-5718

Newsgroups: gnu.gcc.bug
From: brendan@cygnus.com (Brendan Kehoe)
Subject: [lah@unh.edu : 2.2.2 on RS/6000]
Reply-To: brendan@cygnus.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 08:27:27 GMT

------- Start of forwarded message -------
From: lah@unh.edu (Lance A. Hartford)
Subject: 2.2.2 on RS/6000
To: bug-g++@prep.ai.mit.edu
Date: Tue, 1 Sep 1992 18:31:04 GMT

I'm trying to compile gcc 2.2.2 on the RS/6000 running AIX 3.2.2. This
is the error that I am getting:

_muldi3
Assembler:
/tmp/ccLOsDM2.s: line 25: 1252-142 Syntax error.
make: 1254-004 The error code from the last command is 1. 

has anyone has an error like this compiling with 3.2.2? I read the
README.RS6000 file about the problem with /bin/as. Does that fix apply
to this problem? Thanks...
- --
________________________________________________________________________
| Lance A. Hartford             | Computer Science Junior              |
| UNH InterOperability Lab      | Internet: lah@unh.edu                |
| University of New Hampshire   | 32 Coe Drive, Durham NH 03824        |
|----------------------------------------------------------------------|
------- End of forwarded message -------

Newsgroups: gnu.gcc.bug
From: carlson@tis.llnl.gov (John Carlson)
Subject: Increment and assignment (sleepy programmers see section 3.1 of C FAQ)
Organization: Lawrence Livermore National Laboratory
Distribution: gnu
Date: Wed, 2 Sep 1992 10:38:37 GMT

int i = 0;
i = i++;
printf("%d\n", i);

Values of i:

Sun 4.1.1 cc compiler produces: 1
Sun C++ 2.1 produces: 1
Optimized gcc produces: 1
Unoptimized gcc 2.2.2 produces: 0
AT&T cc compiler produces: 0

Don't use i = i++.

It would be nice if the compiler warned me about it.

John Carlson
carlson@yottzumm.tis.llnl.gov

Newsgroups: gnu.gcc.bug
From: bjornw@colargol.edb.tih.no (Bjoern Wennberg)
Subject: gcc compiled program core dumps
Organization: Colargol, Trondheim College of Engineering
Distribution: gnu
Date: Fri, 28 Aug 1992 13:49:22 GMT

Hi!

I loaded down a maze generator posted on comp.lang.c (I have forgotten
the name of the author)

The program runs properly when compiled with cc but coredumps when
compiled with gcc
Here is the program:

char *M, A, Z, E = 40, J[40], T[40];
main (C)
{
  for (*J = A = scanf (M = "%d", &C); --E; J[E] = T[E] = E)
    printf ("._");
  for (; (A -= Z = !Z) || (printf ("\n|"), A = 39, C--); Z || printf (M))
    M[Z] = Z[A - (E = A[J - Z]) && !C & A == T[A] | 6 << 11 < rand () || !C & !Z ? J[T[E] = T[A]] = E, J[T[A] = A - Z] = A, "_." : " |"];
}

Compiling with gcc:
$gcc c.c
$a.out
2
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
|Segmentation fault (core dumped)

Compiling with cc:
$cc c.c
$a.out
2
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
| ._| . . ._| | |_._._. . ._|_._._._._. ._|_. ._|_._. ._| | . ._|_. | . ._._. |
|_._._|_|_._._._._._._._|_._._._._._._._._._._._._._._._._._|_._._._._|_._._|_|

Why does the program core dump when compiled with gcc ?

I have tried to different gcc's (both 2.2.2) a) i386v4 and b)isc

bjornw>

  -------------------------------------------------------------
| bjornw@colargol.edb.tih.no    Bj|rn Wennberg tlf.: 07-524946 |
| bjornw@edb.tih.no             Wesselsgt. 7                   |
|                               7043 TRONDHEIM, NORWAY         |
  -------------------------------------------------------------


Newsgroups: gnu.gcc.bug
From: attardi@di.unipi.IT (Giuseppe Attardi)
Subject: nested functions
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 10:56:59 GMT

In gcc 2.0 under SunOS 4.1.2, the following program crashes the compiler
with the message:

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


foo(int a)
{ int x;
  void bar (int z) { x = a; }
  bar(a);
}

while it works with the assignement 'x = z'.

The manual (sec. 7.4) says that "a nested function can access all the
variables of the containing function", and I interpret this as including
the parameter 'a'.


Newsgroups: gnu.gcc.bug
From: freeman@saul.cis.upenn.edu (Jon Freeman)
Subject: gcc for Solaris 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 28 Aug 1992 14:59:49 GMT

We've installed Solaris 2.0 on one of our Sparcstations and now
we need a compiler (even though the folks at Sun apparently thought
we wouldn't).  We have the source code for gcc, but we need a
compiler to compile it (!).  So, does any kind soul out there have
an executable for gcc 2.2.2 that we can ftp?  (Has gcc been ported
to Solaris 2.0 yet?)
			Many thanks,
			  Jon
			  (freeman@gradient.cis.upenn.edu)

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: WRONG LIST (was: Re:  Static member doesn't link)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 14:25:51 GMT

In the future please report all g++ bugs to the

        bug-g++@prep.ai.mit.edu

list, thanks.  If they are back-end bugs, they can be reported here,
but please let us know if you think the problem is in the back-end.

You don't need to resubmit this one.

> From: ken@tifsim.pac.sc.ti.com (Ken Costilow)
> Message-Id: <1992Jul23.164014.13951@ticipa.pac.sc.ti.com>
> Reply-To: kenneth@lobby.ti.com (Ken Costilow)
> Organization: Texas Instruments Process Automation Center
> Date: Thu, 23 Jul 1992 16:40:14 GMT
> Apparently-To: uunet!gnu-gcc-bug
> To: bug-gcc@prep.ai.mit.edu

> Hello everyone.

> I can`t compile classes with static data members. I was hoping this
> was simply one of gcc's many switches, but if so I have been unable
> to find it. 

> I'm using: Vax3800/Ultrix4.2, gcc 2.1, gas 1.38, binutils 1.9
> I have tried the standard ld, gnu ld, as, gas, using l



Newsgroups: gnu.gcc.bug
From: a.shepherd@xtel.co.uk (Alan Shepherd)
Subject: Undefined assembler symbols in .o files
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 16:26:01 GMT

Quite a while ago I sent a message reporting undefined assembler
symbols such as "L495" appearing in .o files.  I didn't receive any
acknowledgement or see any answer or patch in the newsgroup, although
I did see someone else reporting the same thing.

output from gcc -v

Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1.1/2.2.2/specs
gcc version 2.2.2

The problem seems to arise when using the -g flag and can be evidenced
by compiling the lates version of libg++.a.  I can't remember which
particular file other than it is one of the ones in iostream, but I
did report it before.

Alan Shepherd

---------
Alan Shepherd, X-Tel Services Ltd., University Park, Nottingham NG7 2RD.
Email: a.shepherd@xtel.co.uk, Phone: +44 (0) 602 412648 (Fax:790278)
X.400: C=GB;ADMD= ;PRMD=X-Tel Services;O=X-Tel;S=Shepherd;G=Alan


Newsgroups: gnu.gcc.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 21:19:40 GMT

    What I would really like to do, is turn off builtin functions, and the
    builtin function prototypes.

This is the wrong approach, for a basic philosophical reason.

You have found a feature which, in a particular case, fails to work.
To think that the solution is to turn off the feature is to assume
that it can *never* work.

But it is absurd to assume that.  We don't know why it does not work.
It may be failing for a trivial reason.  It is silly to give up on the
feature without first checking the possibility that it can easily be
fixed.

I can't tell you what to do.  Those of you who wish to give up on a
feature can do so.  But for those of you who are interested in what I
have to say, I urge you to take a constructive approach and help get
things fixed.

See the Bugs chapter of the GCC manual for a general guide to how to do this.

In the case of a type conflict with a built-in function, the main
useful thing for you to do is to find the declaration that conflicts
and tell us precisely what data types the conflicting declaration
uses.  Most importantly, find out what size_t is in the system headers.
From: eggert@twinsun.COM (Paul Eggert)
Subject: GCC 2.2.2 incorrectly multiplies some long long constants by 3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 08:32:48 GMT

GCC 2.2.2 (Sparc, SunOS 4.1.2) incorrectly multiplies some long long
constants by 3.  In the following example program, GCC miscomputes c3's
initial value to be 4294967294 instead of the correct value 8589934590,
so the program incorrectly exits with status 1.

	#define C 2863311530LL
	long long int c = C;
	long long int c3 = C * 3;

	main() { return c*3 != c3; }

Here is a workaround.

===================================================================
RCS file: fold-const.c,v
retrieving revision 2.2.2.3
diff -c -r2.2.2.3 fold-const.c
*** fold-const.c	1992/08/11 04:23:35	2.2.2.3
--- fold-const.c	1992/08/29 08:21:30
***************
*** 1045,1055 ****
  		  int2h = int2h * 2 + (temp < int2l);
  		  t = build_int_2 (temp, int2h);
  		  goto got_it;
- 		case 3:
- 		  temp = int2l + int2l + int2l;
- 		  int2h = int2h * 3 + (temp < int2l);
- 		  t = build_int_2 (temp, int2h);
- 		  goto got_it;
  		case 4:
  		  temp = int2l + int2l;
  		  int2h = int2h * 4 + ((temp < int2l) << 1);
--- 1045,1050 ----

Newsgroups: gnu.gcc.bug
From: carlson@tis.llnl.gov (John Carlson)
Subject: Increment isn't done before assigment in unoptimized version
Organization: Lawrence Livermore National Laboratory
Distribution: gnu
Date: Wed, 2 Sep 1992 09:01:55 GMT

Machine: Sparcstation 2
OS: Sun OS 4.1.1
Compiler: gcc-2.2.2


The follow program gives difference result when compiled with
and without the -O option to gcc.

#include <stdio.h>
main ()
{
	int i = 0;
	i = i++;
	printf("should be 1->%d\n", i);
}


The unoptimized version prints:

should be 1->0

The optimized version prints:

should be 1->1

Guess the moral of the story is to use the optimized version.
Either that or I was too tired when programming.
(Yeay! The program works now!)

John Carlson
carlson@yottzumm.tis.llnl.gov

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: WRONG LIST (was: Re:  A severe bug with statics members.)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 13:36:18 GMT

In the future please report all g++ bugs to the

        bug-g++@prep.ai.mit.edu

list, thanks.  If they are back-end bugs, they can be reported here,
but please let us know if you think the problem is in the back-end.

You don't need to resubmit this one.

> Message-Id: <9208221844.AA21654@life.ai.mit.edu>
> Date:         Sat, 22 Aug 92 14:34:04 COL
> From: Luis Armando Cobo <LCOBO%ANDESCOL.BITNET@mitvma.mit.edu>
> Organization: Universidad de Los Andes - Bogota, Colombia
> To: bug-gcc@prep.ai.mit.edu

> In a DECstation 5000/125 with ULTRIX 4.2, and gcc/g++ 2.2.2 and with
> this program:

>     class ONE {

Newsgroups: gnu.gcc.bug
From: kherron@ms.UKy.EDU (Kenneth Herron)
Subject: Gcc 2.2.2 Makefile (three problems)
Organization: University Of Kentucky, Dept. of Math Sciences
Distribution: gnu
Date: Tue, 1 Sep 1992 17:31:43 GMT

The FIRST problem:

Gcc's INSTALL document contains these comments:

       make CC="stage2/gcc -Bstage2/" CFLAGS="-g -O" install LANGUAGES="LIST"

     (Use the same value for `CC', `CFLAGS' and `LANGUAGES' that you
     used when compiling the files that are being installed.  One
     reason this is necessary is that some versions of Make have bugs
     and recompile files gratuitously when you do this step.  If you
     use the same variable values, those files will be recompiled
     properly.
[...]
     On some systems, this command will cause recompilation of some
     files. This is usually due to bugs in `make'.  You should either
     ignore this problem, or use GNU Make.

Well, I AM using gnu make (v. 3.60) and under gmake -n, gmake acts as
if it will recompile everything.  When run without -n, doesn't actually 
recompile anything, but it clearly thinks some targets are out of date, 
cc1 for example.

I traced the problem to the various insn-* rules, eg:

	insn-config.h: stamp-config ;
	stamp-config : md genconfig $(srcdir)/move-if-change
		./genconfig md > tmp-config.h
		$(srcdir)/move-if-change tmp-config.h insn-config.h
		touch stamp-config

>From these two rules, insn-config.h is always out of date, since its
dependency is built after it is.  Several things list insn-* files
as dependencies so they get rebuilt after the (empty) ruleset for
insn-config.h runs.  I'd go so far as to say that gnu make is buggy
for not actually performing the compiles it says are needed when run
with -n.

It seems either of these two changes avoid this problem:

        insn-config.h: stamp-config
		sleep 1; touch insn-config.h
        stamp-config : md genconfig $(srcdir)/move-if-change
                ./genconfig md > tmp-config.h
                $(srcdir)/move-if-change tmp-config.h insn-config.h
                touch stamp-config

        insn-config.h: stamp-config
        stamp-config : md genconfig $(srcdir)/move-if-change
                ./genconfig md > tmp-config.h
                $(srcdir)/move-if-change tmp-config.h insn-config.h
                touch stamp-config && sleep 1 && touch insn-config.h


The SECOND problem:

When run with gnu make, a bogus 

	cat install.sh > install

command pops up at the end of "make install".  I believe this is coming
from a builtin rule since there's no such command in the makefile.

The THIRD problem:

The ruleset for install-limits-h writes to the source directory.  It would
be nice if one could make install from a read-only filesystem or without
write permission to the current directory.  I fixed it here by putting
tmp-limits.h in /tmp.

Newsgroups: gnu.gcc.bug