HDTenEightyP/NetNews huggingface dataset:
From: nessus@mit.edu (Douglas Alan)
Subject: uid's and GNU format tar files
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 18:17:34 GMT

Hi.  A suggestion for gnutar: It should be possible to have an archive
store uid's rather than user names without going into old archive
format mode.  A user may want to copy files to a system without a
password file yet still gain the advantages provided by the new
archive format.  In fact, I need to do this very often because we do
not use yp or keep password files on our NFS servers.  The NFS servers
do not need to know the usernames of the owners of files -- only the
uid's.  However, it often happens that I need to copy directories
around on our NFS servers.

|>ouglas /\lan
   MIT Media Lab
   Systems Programming Group
   <nessus@mit.edu>

Newsgroups: gnu.utils.bug
From: carlton@husc11.harvard.edu (david carlton)
Subject: Re: INSTALL mode
Organization: Citizens for Boysenberry Jam
Distribution: gnu
Date: Thu, 5 Nov 1992 05:20:07 GMT

In article <199211042120.AA01473@claude.cs.umb.edu>, karl@claude.cs.umb.edu (Karl Berry) writes:

> Autoconf 1.2 chooses to make the mode used with INSTALL_DATA be 0644,
> and INSTALL_PROGRAM be the default, which I guess is 0755.  Perhaps it
> would be more consistent with GNU's goals to make the default modes
> include group write permission.

Ick.

> Failing that (or in addition), perhaps
> the modes could be made more easily overridable in make (or even
> overridable by setting variables before running configure), as in

> $(INSTALL_PROGRAM_MODE) = 775
> $(INSTALL_DATA_MODE) = 664
> $(INSTALL_PROGRAM) -m $(INSTALL_PROGRAM_MODE)
> $(INSTALL_DATA) -m $(INSTALL_DATA_MODE)

Why not just edit the definitions of INSTALL_DATA and INSTALL_PROGRAM
in the Makefile?  No sense abstracting needlessly.

david carlton
carlton@husc.harvard.edu

       Am I accompanied by a PARENT or GUARDIAN?

Newsgroups: gnu.utils.bug
From: timhu@ico.isc.com (Timothy Hu)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 07:14:43 GMT

I'm trying to install g++ v1.42.0 on an RS/6000 running AIX 3.2. There is no
entry in the config script for this machine.

Where do I go from here?

Thanks,
Tim


Newsgroups: gnu.utils.bug
From: ramsey@majorleague.npirs.purdue.edu
Subject: screen 3.2b doesn't process cursor key set/reset commands
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 18:22:57 GMT

The screen program (version 3.2b) doesn't process the cursor key set
and reset commands, it simply eats the escape sequence and goes on.

We have one application that sets the keypad to application and the
cursor keys to numeric (or cursor) mode. The screen program didn't
support this so I added "case 1:" to the "E[?" switch and simply pass
on the set or reset codes to the terminal, which has fixed this problem.

It would be nice if the application maintainer would take the intent
of this fix and apply it in a more correct form for this program.  I
don't feel printf's are appropriate, but didn't have the time to
explore the "best" way to make this change.

file: ansi.c

    case '?':
      debug2("\\E[?%d%c\n",a1,c);
      if (c != 'h' && c != 'l')
	break;
      i = (c == 'h');
      switch (a1)
	{
#ifdef CERIS
	  /* CASE 1: process arrow keys */
	case 1:
	  if (i)
	    {
	      printf("\033[?1h");
	    }
	  else 
	    {
	      printf("\033[?1l");
	    }
	  break;
#endif /* CERIS */
	case 3:
	  i = (i ? Z0width : Z1width);
	  if ((Z0 || WS) && curr->width != i)
	    {
              ChangeWindowSize(curr, i, curr->height);
	      SetCurr(curr);
	      if (display)
		Activate(0);
	    }
	  break;



-Ed

Ed Ramsey Ramsey@CERIS.Purdue.EDU 317/494-0442 FAX/494-9727
CERIS (Center for Environmental and Regulatory Information Systems)
Network Services Manager/UNIX Systems Administrator

Newsgroups: gnu.utils.bug
From: joe@smt_6.b21.ingr.com (Joe Ryburn)
Subject: ISCREEN Port to Intergraph W/S
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 19:11:03 GMT

Gentlemen,

I am trying to port iscreen 3.2b to an Intergraph workstation. The CLIX
operating system is primarily SYSVR3, but with numerous BSD extensions,
including the full BSD socket functions. After running configure, iscreen
compiled cleanly except for a couple of type definitions which were
fixed by including a header file in screen.c

There are no significant problems exposed by examining the debug
output, but when screen executes I get the shell prompt at the top
of the screen and absolutely no keyboard input is accepted. I have
to kill screen from another window. I think that screen is blocking on
a read of the pty opened, but I'm hoping that someone may have already
ported the iscreen system to Intergraph and that someone there may know
about this port. In any case, I'm determined to continue trying to 
port iscreen to this platform, but any clues would be tremendously 
appreciated.


-- 

----------------------------------------------------------------
Joe Ryburn |  CIM Manager               | Intergraph Corporation
           |  Advanced Technology Group | Huntsville, AL 35894
----------------------------------------------------------------

Newsgroups: gnu.utils.bug
From: jwe@che.utexas.EDU (John Eaton)
Subject: Oleo-1.0 fails to compile in subdirectory
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 00:12:37 GMT

Using GNU make and gcc, oleo-1.0 fails to compile in a subdirectory.
The problem appears to be that the Makefile.in has the rule

  .c.o:
	  $(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) $<

instead of

  .c.o:
	  $(CC) -c $(ALL_CFLAGS) $(CPPFLAGS) -I$(srcdir) $<

as the other GNU utilities do (fileutils, shellutils, etc.).

--
John W. Eaton      | 4.3BSD is not perfect.  -- Leffler, et al. (1989).
jwe@che.utexas.edu |

Newsgroups: gnu.utils.bug
From: FJT19292%USA.DEcnet@usav01.glaxo.com (USA: :FJT19292)
Subject: Bug (?) in iscreen3.2b
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 8 Nov 1992 19:28:00 GMT

I have just finished getting iscreen version 3.2b to compile and work on
my Microport SysV/386 (5.3.2.3) system.  I won't bore you with the little
changes that I had to make in the header files, unless your interested.
But I did find a problem in the ansi.c code that I would like to share with
you: when a line feed and/or a return is sent to the screen when the alternate
character set (graphics character set) is selected, the line feed and return
are printed with their eight bit set instead of having the intended effect.

Here are the changes that I made to the ansi.c code (in diff style):

1877a
     if(GlobalCharset == '0') tputs(E0, 1, PutChar);
.
1878a
     if(GlobalCharset == '0') tputs(S0, 1, Putchar);
.
1899a
     if(GlobalCharset == '0') tputs(E0, 1,, Putchar);
.
1901a
     if(GlobalCharset == '0') tputs(S0, 1, PutChar);
.

The above listed problem normally only occured when graphics characters were
printed in the first 24 lines of a window, that is to say before the screen
rolled upwards.  However, whenever I used iscreen to run All-in-1 on the
local vax, I had the problem with almost every screen of text.

Frank (fjt19292@usav01.glaxo.com)
From: mjc-b@minster.york.ac.uk (Mike Convey)
Newsgroups: gnu.utils.bug
Subject: Bug report for patch 12g8
Date: 5 Nov 92 21:28:10 GMT
Distribution: gnu
Organization: GNUs Not Usenet

In get_some_switches(), optc is assigned to getopt_long(), however
optc is a char and getopt_long returns an int, so the -1 return
value is lost in the asignment.

Fix is to change type of optc to int.

Platform is AIX, using system compiler.

Mike
Newsgroups: gnu.utils.bug
From: nico@bredex.DE
Subject: File INSTALL is missing in regex-0.11.tar.Z
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 11:54:52 GMT

Hi folks,

in  README  for  regex-0.11.tar.Z  i find:
 > See the file INSTALL for compilation and installation instructions.
But where is it ?
I think you forgot it.

So could you fix this and send it to me ?

advTHANKSance

--------
Nico
                                 address: BREDEX GmbH
email:   nico@bredex.de                   Nicolai Josuttis
                                          Kastanienallee 2a 
phone:   +49 531 75480                    D-3300 Braunschweig
fax:     +49 531 796358                   Germany
--------

Newsgroups: gnu.utils.bug
From: jmessenger@cix.compulink.co.uk (John Messenger)
Subject: Binutils-2.0 Sun3-sunos3 configure problem]
Reply-To: jmessenger@cix.compulink.co.uk
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 18:01:00 GMT

cd binutils-2.0
./configure sun3-sunos3

This gives an error with respect to the ld/ subdirectory indicating
that 'sun' is an unknown 'm68k' vendor.

./configure sun3    works OK
From: Henrik.Bakman@csd.uu.SE (Henrik B}kman  CSD)
Newsgroups: gnu.utils.bug
Subject: sed
Date: 6 Nov 92 14:19:24 GMT
Article-I.D.: woody.199211061219.AA02901
Distribution: gnu
Organization: GNUs Not Usenet

Program: sed 1.11
OS: SunOS 4.1.2
Machine: Sun4c
C-compiler: gcc 2.2.2
----------------------------------------
Problem: When I do

		echo foo bar | sed 'y/ /\n/'

	I get

		sed: Extra characters after command

	When I run the same command with Sun's version
	of sed it changes all spaces to newlines.

	I don't know if this is a bug or a "feature".
	Maybe there is a SysV-behaviour and a BSD-behaviour?

----------------------------------------------------------------------
Henrik Bakman           Adress: Box 520          Tel: +46 18 181044
System Manager                  751 20 UPPSALA   Fax: +46 18 521270
Computing Science Dep.          SWEDEN           Email: hb@csd.uu.se
Uppsala University
From: jxt@stc06.ctd.ornl.gov (TOLLIVER J S)
Newsgroups: gnu.utils.bug
Subject: Problem with Gnu make on SGI with CC
Date: 12 Nov 92 17:29:44 GMT
Reply-To: jxt@stc06.ctd.ornl.gov (TOLLIVER J S)
Distribution: gnu
Organization: Oak Ridge National Laboratory

I've built GNU make 3.62 on a Silicon Graphics Indigo under IRIX 4.0.1.
I'm using it to compile C++ code using SGI's C++ compiler (basically
just cfront and cc). But I am having the following strange problem.

CC in an action line with -I options (like -I/usr/include/X11) fails with the
error:

	CC: can't execute /usr/lib/acpp

Leaving out all -I options works. Putting in any fails. Of course, the compile
will not be successful without the -I's since there will be missing include
files, but at least the "can't execute /usr/lib/acpp" error does not occur.
Other options that get passed on to cpp, like -DFUNCPROTO, do work.

Entering the exact same action line interatively, including -I options, also
works.

I can't say whether this is a problem with Gnu make or with SG CC, but it first
appeared after installing Gnu make. I.e., it DOES NOT occur with SG's native
make. It also does not occur with the same Gnu make on an HP 9000/730 machine
using HP's C++ compiler. (Please don't suggest using gcc/g++. That's not an
option for this project.)

One more thing, although I can repeatedly generate the error with my real
4000-line makefile, I cannot reproduce it with a simple test case and a
simple makefile. Something about the complexity and/or length of the makefile
seems to be related, but I know not what.

If anyone has any ideas, I would greatly appreciate any help received.

Thanks,
Johnny Tolliver
Oak Ridge National Laboratory
jxt@ornl.gov
Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: getdate.y
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 06:02:47 GMT

getdate.y in fileutils 3.4 and shellutils 1.8 still doesn't compile an
IBM RT running AOS (4.3BSD) with gcc 2.3.1.  The problem is unchanged
from the last release getdate.y was in (tar 1.11.1, I think): <time.h>
is included twice, once by virtue of the #include <sys/time.h> (which in
turn includes <time.h>) around line 40 of getdate.y:

#if !defined (USG) && !defined (sgi) && !defined (__386BSD__)
#include <sys/time.h>
#endif

and again by virtue of the #include <time.h> around line 76:

#if	defined(BSD4_2) || defined(BSD4_1C) || (defined (hp9000) && !defined (hpux))
#include <sys/time.h>
#else
#if defined(_AIX)
#include <sys/time.h>
#endif
#include <time.h>
#endif	/* defined(BSD4_2) */


More generally, the problem is that Autoconf does not define symbols
like BSD4_2 or BSD4_1C (in this case, defining BSD4_2 solves the
problem, since <sys/time.h> is protected against multiple inclusion).
Personally, I think those ``system macros'' like BSD4_2 are doomed to
failure; I don't know what feature getdate.y is trying to include in
those lines, but whatever it is, surely it would be better to test for
it specifically.

Newsgroups: gnu.utils.bug
From: bas@phys.uva.NL (Bas de Bakker)
Subject: GNU tar 1.11.1 sort of a bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 12:51:53 GMT

In GNU tar 1.11.1 the configure script checks for the presence of
bison. If it's there it inserts in the Makefile:

YACC = bison -y

But it then uses in the getdate.c entry from Makefile.in

        yacc getdate.y

instead of

        $(YACC) getdate.y

Seems strange to me...

Bas de Bakker.

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU sed 1.12 installation
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 7 Nov 1992 21:59:40 GMT

This pertains to GNU sed 1.12 installation, using GNU C 1.41 under
COFF encapsulation, on this 386/ix 2.0.2 system, waiting for Hurd :-).

The installation went easily, save for a few compiler warnings:

----->
sed.c: In function main:
sed.c:406: warning: argument passing between incompatible pointer types
sed.c:413: warning: argument passing between incompatible pointer types
sed.c: In function compile_string:
sed.c:481: warning: argument passing between incompatible pointer types
-----<

Here is a diff which gets rid of them:

--- 1.1	1992/11/07 21:50:18
+++ sed-1.12/sed.c	1992/11/07 21:51:59
@@ -233,7 +233,7 @@
 void add1_buffer P_ ((VOID * bb, int ch));
 char *get_buffer P_ ((VOID * bb));
 
-void compile_string P_ ((unsigned char *str));
+void compile_string P_ ((char *str));
 void compile_file P_ ((char *str));
 struct vector *compile_program P_ ((struct vector * vector));
 void bad_prog P_ ((char *why));
@@ -473,12 +473,12 @@
    Compile the command, and add it to the end of 'the_program' */
 void
 compile_string (str)
-     unsigned char *str;
+     char *str;
 {
   prog_file = 0;
   prog_line = 0;
-  prog_start = prog_cur = str;
-  prog_end = str + strlen (str);
+  prog_start = prog_cur = (unsigned char *) str;
+  prog_end = (unsigned char *) str + strlen (str);
   the_program = compile_program (the_program);
 }

-- 
Franc,ois Pinard        ``Vivement GNU!''       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: patrick@wwtc.timeplex.com (Patrick D. Wildi)
Subject: i960 toolchain linker problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 16:48:21 GMT

Hi

I am trying to set up a GNU toolchain for cross-compiling i960 code
on a sun4c (sunos 4.1.1).

I use the following configurations for these tools:

GCC (2.2.2):    --host=sun4 --target=i960 --nfp
GAS (1.92.3):   --host=sun4 --target=i960-nindy
Binutils (2.0): --host=sun4  (using LDEMULATION=gld960, GNUTARGET=b.out.big to run gld)


Is this the correct configuration? Would it be better to use a coff format?
Does the coff configuration work for all tools?

It seems to me that GCC and GAS work ok. But the linker always fails with a
this segmentation error:
	
>	lewis [ld] setenv LDEMULATION gld960
>	lewis [ld] gdb ld.new
>	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) run -b b.out.big -o tt.o bite.o
>
>	Program received signal 11, Segmentation fault
>	0x2ec94 in b_out_get_relocated_section_contents (in_abfd=0xa9060,
>    	seclet=0xa9428, data=0xaf028 "V1.0x7") at bout.c:1155
>	1155            switch (reloc->howto->type)
>	(gdb) where
>	#0  0x2ec94 in b_out_get_relocated_section_contents (in_abfd=0xa9060,
>	    seclet=0xa9428, data=0xaf028 "V1.0x7") at bout.c:1155
>	#1  0x1b8c4 in rel (abfd=0xa9060, seclet=0xa9428, output_section=0xa9288,
>	    data=0xaf028 "V1.0x7") at seclet.c:86
>	#2  0x1b944 in seclet_dump_seclet (abfd=0xa9060, seclet=0xa9428,
>	    section=0xa9288, data=0xaf028 "V1.0x7") at seclet.c:110
>	#3  0x1babc in seclet_dump (abfd=0xa9060, data=0xaf028 "V1.0x7")
>	    at seclet.c:146
>	#4  0x12c0c in write_relaxnorel (output_bfd=0xa9060, data=0xaf028 "V1.0x7")
>	    at relax.c:162
>	#5  0xe244 in ldwrite () at ldwrite.c:414
>	#6  0xc2f4 in main (argc=6, argv=0xf7fff83c) at ldmain.c:254
>	(gdb) p *reloc
>	$1 = {sym_ptr_ptr = 0xabdec, address = 32, addend = 0, howto = 0x440}
>	(gdb) p *reloc->howto
>	$2 = Cannot access memory at address 0x440.

Can anybody give me a hint what is wrong in my setup?

Thanks Patrick.

-------------------------------------------------------------------
Patrick D. Wildi		Phone:    (310)443-5727
Ascom Timeplex 			FAX:      (310)443-5582
10920 Wilshire Blvd.		Internet: patrick@wwtc.timeplex.com
Los Angeles, CA 90024		UUCP:     uunet!uncng!patrick
-------------------------------------------------------------------

Xref: sparky gnu.utils.bug:2022 gnu.gcc.bug:2675
From: Ken Raeburn <raeburn@cygnus.com>
Newsgroups: gnu.utils.bug,gnu.gcc.bug
Subject: new gas version coming...
Followup-To: gnu.utils.bug
Date: 8 Nov 1992 22:21:25 -0500
Organization: Project GNU, Free Software Foundation,
    675 Mass. Ave., Cambridge, MA  02139, USA +1 (617) 876-3296
Distribution: world
NNTP-Posting-Host: life.ai.mit.edu
To: bug-gnu-utils@prep.ai.mit.edu
Cc: bug-gcc@prep.ai.mit.edu

I have recently taken over maintenance of the GNU assembler for the FSF.
It's been a while since the last release, so I'm sending out this note to
let people know that work on the assembler is continuing.
	I aim to have a new version available for general release in early
'93.  It will be a merged version of the FSF gas currently in testing
(1.92.3) and some work that's been ongoing at Cygnus, further refining and
enhancing support for a few of the targets.
	It will also include as many bug fixes and enhancements as I have
time to integrate.
	A new version should be going out to pre-alpha testers/developers
within a couple weeks or so.

A related project I've been working on has been the conversion of the
assembler to use the BFD library used by GDB and binutils; it should
simplify development and maintenance work for the toolchain as a whole once
the conversion is complete.  I don't know yet whether that will be folded
in for this release; it has a way to go before it's ready for general use.
(If anyone is interested in assisting in the development work on this,
please send me mail.)

So keep those bug reports coming in...

Newsgroups: gnu.utils.bug
From: will@westford.ccur.COM
Subject: Bogus compare coming from `simplify_condition()'
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 16:45:48 GMT

The following suggestion allows something useful to be done 
with a bit field produced by a signed extraction compared against zero.

The RTL pattern

    (set (reg:SI n)
         (ashiftrt:SI (ashift (reg:SI)     ;; from a bit field extraction
                              (const_int))
                      (const_int)))
    (set (cc0)
         (compare (reg:SI n)
                  (const_int 0)))

was being munged by `simplify_condition()' into 

   (set (cc0)
        (subreg:BLK (reg:SI n) 0))

by adding the line denoted by /* WRA */ in the following 
test in `simplify_condition()'

       case ASHIFTRT:
	  /* If OP0 is a sign extension and CODE is not an unsigned comparison,
	     do the comparison in a narrower mode.  */
	  if (! unsigned_comparison_p
	      && GET_CODE (XEXP (op0, 1)) == CONST_INT
	      && GET_CODE (XEXP (op0, 0)) == ASHIFT
	      && XEXP (op0, 1) == XEXP (XEXP (op0, 0), 1)
	      && (tmode = mode_for_size (mode_width - INTVAL (XEXP (op0, 1)),
					 MODE_INT, 1)) != VOIDmode
/* WRA */     && tmode != BLKmode  
	      && ((unsigned) const_op <= GET_MODE_MASK (tmode)
		  || (unsigned) - const_op <= GET_MODE_MASK (tmode)))
	    {
	      op0 = gen_lowpart_for_combine (tmode, XEXP (XEXP (op0, 0), 0));
	      continue;
	    }

the RTL was reduced to the "correct" zero_extraction pattern.

    (set (cc0)
         (zero_extract (reg:SI n) ..))
                       
----------------------------------------------------------------------
	     ___________     William Athanasiou, Software Engineer
	    /  ________/__   ...!{harvard,decvax,uunet}!masscomp!will
	   /__/_______/  /   will@westford.ccur.com
  Concurrent /__________/    Phone:  (508) 392-2647
Computer Corporation	     FAX: Fax? We don't need no stinkin Faxes!
----------------------------------------------------------------------


Newsgroups: gnu.gcc.bug
From: dsr@lns598.tn.cornell.edu (Daniel S. Riley)
Subject: Minor bug in config/alpha.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 13:12:38 GMT

Reading specs from /usr/local/lib/gcc-lib/alpha-dec-osf1/2.3.1/specs
gcc version 2.3.1
 /usr/local/lib/gcc-lib/alpha-dec-osf1/2.3.1/cpp -lang-c -v -undef -D__GNUC__=2 -Dunix -D__osf__ -D__alpha -D__alpha__ -D_LONGLONG -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__ -D__osf__ -D__alpha -D__alpha__ -D___LONGLONG__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__ -D__unix -D__osf__ -D__alpha -D__alpha__ -D___LONGLONG -D__SYSTYPE_BSD -D___SYSTYPE_BSD -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C asdf.c /tmp/cc005249.i
GNU CPP version 2.3.1
 /usr/local/lib/gcc-lib/alpha-dec-osf1/2.3.1/cc1 /tmp/cc005249.i -quiet -dumpbase asdf.c -version -o asdf.s
GNU C version 2.3.1 compiled by GNU C version 2.3.1.

gcc 2.3.1 configured for alpha-osf1 produces invalid assembly for code
with greater than 32kbytes of auto variables, e.g. something like

main() { long asdf[8100]; } /* yes, this is a complete example */

produces assembly with the sequence

	.frame $15,0,$26
	stq $26,0($30)
	stq $15,8($30)
	.mask 0x4008000,-64816
	add $30,$28,$15

There is no "add" instruction.  This appears to be a minor typo in alpha.c,
which I believe can be fixed with this patch:

*** config/alpha.c.orig	Mon Nov  2 12:38:45 1992
--- config/alpha.c	Thu Nov  5 17:22:11 1992
***************
*** 1359,1365 ****
        if (frame_size == 32768)
  	fprintf (file, "\tlda $15,16384($30)\n\tlda $15,16384($15)\n");
        else if (frame_size > 32768)
! 	fprintf (file, "\tadd $30,$28,$15\n");
        else
  	fprintf (file, "\tlda $15,%d($30)\n", frame_size);
      }
--- 1359,1365 ----
        if (frame_size == 32768)
  	fprintf (file, "\tlda $15,16384($30)\n\tlda $15,16384($15)\n");
        else if (frame_size > 32768)
! 	fprintf (file, "\taddq $30,$28,$15\n");
        else
  	fprintf (file, "\tlda $15,%d($30)\n", frame_size);
      }

--
Dan Riley                          Internet:   dsr@lns598.tn.cornell.edu
Wilson Lab, Cornell University     HEPNET/SPAN: lns598::dsr (44630::dsr)
	      "Distance means nothing/To me." -Kate Bush

Newsgroups: gnu.gcc.bug
From: mattes@azu.informatik.uni-stuttgart.de (Eberhard Mattes)
Subject: GCC 2.3.1 %u sequence fails 8.3 file systems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 22:49:02 GMT

GCC 2.3.1 expands the %u sequence in specs to ccXXXXXX where XXXXXX is
replaced by mktemp() with some other characters. Then, a number is
appended to make the name unique. On file systems which truncate file
names to 8 characters, the `unique' temporary file names created by
this method are not unique. This breaks the following GCC invokation,
for instance:

  gcc file1.c file2.c

as the object file for file1.c is overwritten by the object file for
file2.c.

Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)

Newsgroups: gnu.gcc.bug