HDTenEightyP/NetNews huggingface dataset:
From: eggert@twinsun.COM (Paul Eggert)
Newsgroups: gnu.utils.bug
Subject: make 3.63's `make distclean' shouldn't remove make-stds.texi
Date: 25 Jan 1993 20:13:15 -0500
Organization: GNUs Not Usenet
Distribution: gnu

GNU make 3.63's Makefile.in says that `make distclean' should remove make-*.
But this removes make-stds.texi, which can't be reconstructed from the
rest of the distributed sources.  I don't see any other file that the pattern
make-* matches, so the following patch just dispenses with `rm make-*'.

===================================================================
RCS file: RCS/Makefile.in,v
retrieving revision 3.63
retrieving revision 3.63.1.1
diff -c -r3.63 -r3.63.1.1
*** Makefile.in	1993/01/23 00:27:19	3.63
--- Makefile.in	1993/01/23 21:39:06	3.63.1.1
***************
*** 190,196 ****
  	-rm -f make *.o core
  distclean: clean glob-realclean
  	-rm -f Makefile config.h config.status build.sh
! 	-rm -f TAGS tags make.info* make-* make.dvi
  	-rm -f make.?? make.??s make.log make.toc make.*aux
  realclean: distclean
  mostlyclean: clean
--- 190,196 ----
  	-rm -f make *.o core
  distclean: clean glob-realclean
  	-rm -f Makefile config.h config.status build.sh
! 	-rm -f TAGS tags make.info* make.dvi
  	-rm -f make.?? make.??s make.log make.toc make.*aux
  realclean: distclean
  mostlyclean: clean
From: root@osnome.che.wisc.edu (System Operator)
Newsgroups: gnu.utils.bug
Subject: Suggestion for GNU tar
Date: 25 Jan 1993 21:01:39 -0500
Organization: GNUs Not Usenet
Distribution: gnu

It would be nice if GNU tar could be configured to support gzip compression
as well as "compress" compression.

				Tom
From: jloup@chorus.FR (Jean-loup Gailly)
Newsgroups: gnu.utils.bug
Subject: gzip vs. zip (was: gzip0.8.1 will not unzip unix-zipped files)
Date: 26 Jan 1993 22:02:36 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: jloup@chorus.fr (Jean-loup Gailly)

Ken-ichiro Aoki <aoki@madonna.physics.ucla.edu> writes:

> when I use unix-zip and try to unzip using gunzip, I get the following.
>  g.zip: first entry not deflated or stored--can't extract

See comment in unzip.c:

   This version can extract files in gzip or pkzip format.
   For the latter, only the first entry is extracted, and it has to be
   either deflated or stored.

I apologize for forgetting to document this restriction in gzip.1 and
gzip.info. The intent was only to be able to extract old tar.zip files
containing a single deflated entry, made with:

  tar cf - . | zip > foo.tar.zip

Such files should now be replaced with tar.z files, made with:

  tar cfz foo.tar.z  .

To extract other zip files (with several members or different compression
methods), use unzip. zip and gzip serve different purposes and I don't
have the intention of merging them.

Since many people have asked me this question, here is a quick comparison
of zip and tar+gzip:

- "tar -z" (tar+gzip) compresses a tar file into a single stream. To
  extract one specific member (with "tar xfz foo.tar.z member) gunzip
  decompresses the whole tar.z file and passes that to tar. This method
  improves compression since gzip can take advantage of redundancy between
  files.

- zip compresses file members independently. unzip is then able to seek
  directly to the proper location for extraction of a single member.
  This method degrades compression but enables recovery in case of
  damage to a portion of the zip file. If a tar.z file is damaged, all
  data after the error is lost.

- the current version of zip does not store uid and gid, and compresses hard
  links several times. tar works correctly.

- unzip has many tricks to convert file names from one system to another,
  restore special file attributes (for VMS and OS/2), etc... gzip is
  only a data compression program, and I want to keep it simple.


I am thinking of adding an optional block size parameter to gzip to
improve error recovery (see the file TODO in the gzip 0.8.1 distribution).

> zip I used was Zip 1.0 (29 September 1991)

Get zip 1.9p1 and unzip 5.0p1:
         oak.oakland.edu:/pub/misc/unix/zip19p1.tar-z
         oak.oakland.edu:/pub/misc/unix/unz50p1.tar-z

Jean-loup Gailly
jloup@chorus.fr
From: scott@geom.umn.edu
Newsgroups: gnu.utils.bug
Subject: tar-1.11.1 subdir build bug
Date: 22 Jan 1993 21:05:32 -0500
Organization: GNUs Not Usenet
Distribution: gnu

  The line at 145 in "Makefile.in" should read:
	yacc $(srcdir)/getdate.y
building with subdirectories for each architecture causes "yacc"
to barf because it can't get at "getdate.y".
						Scott
From: bitbug@netcom.com (James Buster)
Newsgroups: gnu.utils.bug
Subject: Re: textutils-1.4: Macro use bug in src/pr.c
Date: 26 Jan 1993 22:24:27 -0500
Organization: Lynx Real-Time Systems, Inc.
Distribution: gnu

In article <9301210807.AA22827@minnie.yoshida.nuie.nagoya-u.ac.jp> sasayama@mickey.yoshida.nuie.nagoya-u.ac.jp (Kaz Sasayama) writes:
>I found a macro use bug in file src/pr.c of textutils-1.4.  The file
>src/pr.c has a line:
>
>              if (!ISDIGIT (*++s))

Unfortunately, Mr?/Ms? (I can't tell) Sasayama didn't give a description
of the symptoms of this bug. The symptoms are that `pr +N', where N
is a decimal integer, will always fail with the message
"pr: `+' requires a numeric argument".

Changing the above code fragment to:
		++s;
		if (!ISDIGIT (*s))
seems to fix the problem.
-- 
				James Buster
			     bitbug@netcom.com
From: jason@jarthur.claremont.edu (Jason Merrill)
Newsgroups: gnu.utils.bug
Subject: Re: gzip0.8.1 will not unzip unix-zipped files
Date: 26 Jan 1993 21:44:45 -0500
Organization: Minimal
Distribution: gnu

>>>>> aoki@madonna.physics.ucla.edu (Ken-ichiro Aoki) writes:

> when I use unix-zip and try to unzip using gunzip, I get the following.
>   g.zip: first entry not deflated or stored--can't extract

> zip I used was
>   Zip 1.0 (29 September 1991)

There's your problem; Zip 1.0 uses the Implosion method, which is
incompatible with Deflation.  gzip only understands Deflation, so is unable
to decompress the file.  You should upgrade to Zip 1.9 and UnZip 5.?.

--
Jason Merrill					jason@jarthur.claremont.edu
From: jason@jarthur.claremont.edu (Jason Merrill)
Newsgroups: gnu.utils.bug
Subject: Makefile.in patch for gzip 0.8.1
Date: 26 Jan 1993 21:44:10 -0500
Organization: Minimal
Distribution: gnu

When I ran 'make check', it created _gztest.z, then died with and Error 1
message.  This is due to the result of the test(1) being carried forward; I
added an 'else true', and now it checks out happily.

*** Makefile.in~	Fri Jan 22 03:21:30 1993
--- Makefile.in	Mon Jan 25 22:53:56 1993
***************
*** 161,168 ****
  check:	all
  	./gzip < $(srcdir)/texinfo.tex > _gztest.z
  	@if test `wc -c < _gztest.z` -ne 30890; then \
! 	   echo FAILED gzip test: incorrect size; rm -f _gztest*; exit 1; fi
! 	rm -f _gztest
  	./gzip -d _gztest.z
  	@if cmp _gztest $(srcdir)/texinfo.tex; then \
  	   echo gzip test OK; else \
--- 161,169 ----
  check:	all
  	./gzip < $(srcdir)/texinfo.tex > _gztest.z
  	@if test `wc -c < _gztest.z` -ne 30890; then \
! 	   echo FAILED gzip test: incorrect size; rm -f _gztest*; exit 1; else\
! 	   true; fi
! 	rm -f _gztest			# Why?
  	./gzip -d _gztest.z
  	@if cmp _gztest $(srcdir)/texinfo.tex; then \
  	   echo gzip test OK; else \

match.S wouldn't compile in a subdirectory because $(CPP) couldn't find
match.S in the current directory...

***************
*** 223,229 ****
  gzip$O getopt$O: getopt.h
  
  match$O: match.S
! 	$(CPP) match.S > _match.s
  	$(CC) -c _match.s
  	mv _match$O match$O
  	rm -f _match.s
--- 224,230 ----
  gzip$O getopt$O: getopt.h
  
  match$O: match.S
! 	$(CPP) $(srcdir)/match.S > _match.s
  	$(CC) -c _match.s
  	mv _match$O match$O
  	rm -f _match.s

--
Jason Merrill					jason@jarthur.claremont.edu
From: sherman@unx.sas.COM (Chris Sherman)
Newsgroups: gnu.utils.bug
Subject: bug in gnu-tar
Date: 26 Jan 1993 21:55:13 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Problem 1:
This one is probably know, but when I do the following:

   gtar cvf machine:/dev/tape/device .
   gtar cvf /dev/tape/device .

It should list the files as they are being processed.  But all I get is blank
lines.  The amount the screen scrolls is the same as if it printed out the 
lines like it should have.  It looks like the 'puts("\n")' are getting
hit, just not the useful printf's.

This is on HP/UX, 8.07, long file names.  Stuff like such as 

   gtar tvf machine:/dev/tape/device

works just fine.


Problem 2:

I'm going to try to copy the gtar directory to the /tmp disk, into a directory
called thing.

  mkdir /tmp/thing
  gtar cf - . | ( cd /tmp/thing ; ~/stuff/gtar/gtar xvf - )

Here is what happened (slightly reformatted for mail):

------------------------------------
./
Reading .
tar-1.11.tar.Z
/s/dizzy.unx.sas.com/local/u/sherman/stuff/gtar/gtar: couldn't change
access and modification times of t_qF
Xx-,4W~XphzV.Zv{QLBWugDK.kGr2F#6xfoL@C<.LY4qSFY^Wu;s||!UU`7o1d['BTuOh8_
</GKYF*}F:z : No such file or directory

/nfs/dizzy.unx.sas.com/local/u/sherman/stuff/gtar/gtar: cannot change mode
of fi;s||!UF
Xx-,4W~XphzV.Zv{QLBWugDK.kGr2F#6xfoL@C<.LY4qSFY^Wuq>EZJdU`7o1d['BTuOh8_</GKYF*}F:z
to 420 : No such file or directory Makefile

/nfs/dizzy.unx.sas.com/local/u/sherman/stuff/gtar/gtar: couldn't change
access and modification times of you have the freedom to distribute copies
of free software (and charge for this service if you wish), that you
receive source code or can get it if you want it, that you can change the
software or use pieces of it
------------------------------------

And it promptly took off and started listing the rest of the contents of
the tar file.

This is a major crash.  Oh, 3 files did make it into /tmp/thing before I 
stopped it: COPYING, Makefile, and tar-1.11.tar.Z.  All of them were the
right size and contents, but the wrong time stamp.


Anyway, thought you would like to know...

-- 
     ____/     /     /     __  /    _  _/    ____/
    /         /     /     /   /      /     /          Chris Sherman
   /         ___   /        _/      /          /
 _____/   __/   __/   __/ _\    _____/   _____/           sherman@unx.sas.com
From: eggert@twinsun.COM (Paul Eggert)
Newsgroups: gnu.utils.bug
Subject: Re: Patch + RCS = ?
Date: 25 Jan 1993 20:13:15 -0500
Organization: Twin Sun Inc, El Segundo, CA, USA
Distribution: gnu

neal@ctd.COMsat.COM (Neal Becker) writes:

   It is easy enough if you only have one directory, then you just use
   rcsdiff.  The only problem is, rcsdiff doesn't have a -r switch!  So,
   what about making a patch from multiple directories?

A simple way is the (Bourne) shell command:
	rcsdiff `
		find . -name '*,v' -print |
		sed 's|,v$||; s|RCS/||' |
		sort
	`
For a more complete solution, you can use CVS (also distributed by the FSF).

   Also, what's the status of rcsclean in 5.6?

The same as in earlier versions of RCS: it's experimental.
The source is available, but the program is not installed by default.
Please send bug reports or questions to rcs-bugs@cs.purdue.edu.
From: faith@cs.unc.edu (Rik Faith)
Newsgroups: gnu.utils.bug
Subject: make 3.63
Date: 25 Jan 1993 20:49:26 -0500
Organization: The University of North Carolina at Chapel Hill
Distribution: gnu

I'm working with a set of nested makefiles which depend on variables being
passed in the environment.  So, I put a

.EXPORT_ALL_VARIABLES:

in the top level Makefile, and all seemed to be well.  However, in a
Makefile 3 levels down, a builtin rule is used to convert a .c file into a
.o file, with the following error being generated:

  gcc -DKERNEL -Wall -O6 -fomit-frame-pointer -m486
  "-DMAX_SCSI_HOSTS=(1+0)" -c hosts.c -o

  gcc: argument to `-o' is missing
  make[3]: *** [hosts.o] Error 1


The following builtin rule is being used for this:

%.o: %.c
#  commands to execute (built-in):
        $(COMPILE.c) $< $(OUTPUT_OPTION)

*but*

OUTPUT_OPTION = -o

*instead of*

OUTPUT_OPTION = -o $@



The NEWS file for make 3.63 says:

* The value of a recursively expanded variable is now expanded when putting
  it into the environment for child processes.  This change was made for
  compatibility with Unix make.

which appears to be the reason for the anomaly described above.

Is there any way to make version 3.63 work EXACTLY like version 3.62?  I'd
prefer not to "unexport OUTPUT_OPTION" because the makefile should still be
allowed to work with make 3.62.

This set of changes seem too drastic to make for a minor revision, IMHO,
since they seem to break expected builtin rule behavior in unexpected ways.

-- 
Rik Faith: faith@cs.unc.edu
What I tell you three times is true.  --Dodgson
From: junio@shadow.TWinsun.COM (Jun Hamano)
Newsgroups: gnu.utils.bug
Subject: GNU make 3.63: configure.in fix
Date: 25 Jan 1993 20:29:39 -0500
Organization: GNUs Not Usenet
Distribution: gnu

In make.h, SYS_SIGLIST_DECLARED is used to avoid the type
conflict, but this preprocessor macro is not defined
automatically by configure.  The following patch fixes this
problem.

Note that I added acconfig.h file so that SYS_SIGLIST_DECLARED is
included in generated config.h.in.  Also, HAVE_UNION_WAIT is
added since autoheader reported it is not covered the acconfig.h
came with autoconf.  Our autoheader might be of a bit different
version from what `make' maintainers are using.

-- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 --
diff -c -r1.1 configure.in
*** configure.in	1993/01/24 08:48:29	1.1
--- configure.in	1993/01/24 08:49:06
***************
*** 43,48 ****
--- 43,53 ----
  	 	 [union wait status; return wait (&status);],
  		 AC_DEFINE(HAVE_UNION_WAIT))
  
+ dnl Check to see if sys_siglist is declared in the header.
+ AC_COMPILE_CHECK(sys_siglist declaration,
+ [#include <signal.h>], [void *p = sys_siglist;],
+ AC_DEFINE(SYS_SIGLIST_DECLARED))
+ 
  # The presence of the following is not meant to imply
  # that make necessarily works on those systems.
  AC_DYNIX_SEQ

diff -c -r1.1 acconfig.h
*** acconfig.h	1993/01/24 08:54:36	1.1
--- acconfig.h	1993/01/24 08:54:47
***************
*** 0 ****
--- 1,5 ----
+ /* Define if `union wait' is the type of the first arg to wait functions.  */
+ #undef HAVE_UNION_WAIT
+ 
+ /* Define if `sys_siglist' is declared in <signal.h> */
+ #undef SYS_SIGLIST_DECLARED
From: bitbug@netcom.com (James Buster)
Newsgroups: gnu.utils.bug
Subject: Re: textutils-1.4: new bug in pr
Date: 26 Jan 1993 22:23:24 -0500
Organization: Lynx Real-Time Systems, Inc.
Distribution: gnu

In article <9301241828.AA12129@ask.cs.cornell.edu> cliff@cs.cornell.edu (Cliff Krumvieda) writes:
>We've found a small bug in GNU textutils-1.4's pr that wasn't present
>in 1.3.  For some reason, pr hangs with the -2 and -a options:

My copy of textutils-1.4 pr doesn't exhibit this problem.
-- 
				James Buster
			     bitbug@netcom.com
From: andre@cs.pitt.edu (Andre Srinivasan)
Newsgroups: gnu.utils.bug
Subject: gnu make 3.63
Date: 25 Jan 1993 20:59:06 -0500
Organization: GNUs Not Usenet
Distribution: gnu

the config.h erroneously defines HAVE_UNION_WAIT for hpux 8.0.7
(hp9000/s7x0).  it should be undefined, as wait takes an int *.

								-andre.

---
Andre Srinivasan  : We are Microsoft.  
Neurophysiology   :	Resistance is futile. 
Children's Hosp.  :		Prepare to be assimulated.
andre@cs.pitt.edu :			-from somewhere out in netland
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: gnu.utils.bug
Subject: Suggestion for GNU tar
Date: 28 Jan 1993 22:13:32 -0500
Organization: Gnus Not Usenet
Distribution: gnu

   Resent-Date: 26 Jan 93 13:01:10 GMT
   Resent-Message-Id: <9301270257.AA05969@raisin-nut>
   Original-To: gnu-utils-bug@chorus.fr
Path: chorus!octave.chorus.fr!jloup
   From: jloup@chorus.fr (Jean-loup Gailly)
   Sender: gnulists@ai.mit.edu
   Newsgroups: gnu.utils.bug
   Date: 26 Jan 93 13:01:10 GMT
   References: <9301251633.AA17768@osnome.che.wisc.edu>
   Reply-To: jloup@chorus.fr (Jean-loup Gailly)
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   root@osnome.che.wisc.edu writes:

   > It would be nice if GNU tar could be configured to support gzip compression
   > as well as "compress" compression.

   Future versions of tar will support gzip. A *non official* patch
   for tar 1.11.1 is given in the gzip 0.8.1 distribution. With this
   patch, "tar -z" uses gzip, "tar -Z" uses compress.

The CURRENT version of tar supports gzip.  Simply install gzip as
`compress' and it will work without a hitch.

It is a very bad thing to use compress now that there is a better
alternative.  Anyone using compress is deliberately helping the patent
holders--change now, before you get sued!

	-mib
From: G.Joly@cs.ucl.ac.uk (Gordon Joly)
Newsgroups: gnu.utils.bug
Subject: Strip deletes a.out's if linked.
Date: 26 Jan 1993 22:05:42 -0500
Organization: GNUs Not Usenet
Distribution: gnu

On SUN4, SunOS 4.1.1, gcc 2.3.3 compiled, strip version 1.94 (?)

porridge:gjoly/c[21] cc -o simple simple.c
porridge:gjoly/c[22] ln simple notso
porridge:gjoly/c[23] file simple notso
simple:		sparc demand paged dynamically linked executable not stripped
notso:		sparc demand paged dynamically linked executable not stripped
porridge:gjoly/c[24] ls -l simple notso
-rwxrwxr-x  2 gjoly       24576 Jan 26 09:21 notso
-rwxrwxr-x  2 gjoly       24576 Jan 26 09:21 simple
porridge:gjoly/c[25] strip simple notso
strip: simple: Error 0
porridge:gjoly/c[26] ls -l simple notso
-rwxrwxr-x  2 gjoly           0 Jan 26 09:21 notso
-rwxrwxr-x  2 gjoly           0 Jan 26 09:21 simple
porridge:gjoly/c[27] file  simple notso
simple:		empty
notso:		empty
porridge:gjoly/c[28] 



I discovered this when I tried to strip:

porridge:gjoly/Local/bin[126] ll gcc*
-rwxr-xr-x  2 gjoly      114688 Jan  7 16:37 gcc
-rwxr-xr-x  2 gjoly      114688 Jan  7 16:37 gcc-sparc-sun-sunos4.1.1
porridge:gjoly/Local/bin[127] 

Gordon,
____

Gordon Joly      Phone  +44 71 387 7050 ext 3703      FAX  +44 71 387 1397
Internet: G.Joly@cs.ucl.ac.uk        UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly
Computer Science, University College London, Gower Street, LONDON WC1E 6BT
From: laprade@trantor.harris-atd.com (Ken Laprade)
Newsgroups: gnu.utils.bug
Subject: GNU indent 1.5 dumps core with `-ts0'
Date: 22 Jan 1993 21:43:21 -0500
Organization: GNUs Not Usenet
Distribution: gnu

On a Sun 4 running SunOS 4.1.1, I got a `floating exception' when I set the
`-ts0' option.  I was hoping that would defeat the use of tabs altogether.
Whatever the interpretation, it should not dump core.

The traceback led to an inline function in dump_line() at io.c, line 244.

-Ken-
From: karl@talos.HQ.ILeaf.COM
Newsgroups: gnu.utils.bug
Subject: GNU stty on Solaris 2.1
Date: 25 Jan 1993 20:09:04 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: karl@hq.ileaf.com

GNU stty (in shellutils 1.8) on Solaris 2.1, compiled with gcc 2.3.3,
doesn't accept the `rows' option.  /bin/stty does.
From: eks@vki68.aar-vki.DK (Eigil Krogh Sorensen)
Newsgroups: gnu.gcc.bug
Subject: gcc.info (additional information).
Date: 21 Jan 1993 18:15:17 -0500
Organization: GNUs Not Usenet
Distribution: gnu

This might not be the right address to use for this mail, but I don't
know where else to send it.

It's just for info.


In the gcc.info files following gcc-2.3.3 in Node: Installation Problems
you write:



   * On System V release 3, you may get this error message while
     linking:

          ld fatal: failed to write symbol name SOMETHING
           in strings table for file WHATEVER

     This indicates that the disk is full or your ULIMIT won't allow
     the file to be as large as it needs to be.

and


   * On the Tower models 4N0 and 6N0, by default a process is not
     allowed to have more than one megabyte of memory.  GNU CC cannot
     compile itself (or many other programs) with `-O' in that much
     memory.

     To solve this problem, reconfigure the kernel adding the
     following line to the configuration file:

          MAXUMEM = 4096



 The last thing must be done on a System V release 3 Version 5.1,
Motorola too.

On this system it's quit confusing.  ulimit gives the answer 
32768, but nevertheles you only have 1024 because MAXUMEM default
is set to that. So, on this system you must reconfigure the kernel
too changing MAXUMEN to e.g 4096 or more.


Just thought i would mention it because it caused me much trouble.


  -- Eigil Krogh Sorensen.
From: CSC_TED%UHDBIT.BITNET@mitvma.mit.edu (TED KOUBIAR)
Newsgroups: gnu.gcc.bug
Subject: help installing GCC-2.3.3
Date: 25 Jan 1993 21:15:54 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Hello:

I am trying to install [ gcc ] on a DECstation 5000/25.   I ran configure
and the target is [ mips-ultrix4.2 ].  It creates the Makefile and when I
run make it does a lot of work and after a while i get an error message:

please let me know if there is a solution.

thanks
---
Ted Koubiar

ted@dt.uh.edu

*******************************************************************************
>>>configure --target=mips-ultrix4.2

Linked `config.h' to `./config/xm-mips.h'
Linked `tm.h' to `./config/mips.h'
Linked `md' to `./config/mips.md'
Linked `aux-output.c' to `./config/mips.c'
Linked `tconfig.h' to `./config/xm-mips.h'
Linked `hconfig.h' to `./config/xm-mips.h'
Merged x-mips.
Merged t-mips.
Created `Makefile'.
Links are now set up for target mips-mips-ultrix4.2.

now running make..........


cc -Wf,-XNg1500 -Olimit 3000 -O1  -DIN_GCC   -g     -I. -I. -I./config
       -DGCC_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/mips-ultrix4.2/`sed -e
       's/.*\"\([^ \"]*\)[ \"].*/\1/' < ./version.c`/include\"
       -DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/lib/g++-include\"
       -DLOCAL_INCLUDE_DIR=\"/usr/local/include\"    -DCROSS_INCLUDE_DIR=\"
       /usr/local/lib/gcc-lib/mips-ultrix4.2/`sed -e 's/.*\"\([^ \"]*\)[ \"].*/\
   1/'
       < ./version.c`/sys-include\"    -DTOOLDIR=\"/usr/local/mips-ultrix4.2/\"
       -c `echo ./cccp.c | sed 's,^\./,,'`
cc -Wf,-XNg1500 -Olimit 3000 -O1  -DIN_GCC   -g     -I. -I. -I./config -c
        ./cexp.c
cc -Wf,-XNg1500 -Olimit 3000 -O1 -c  -DIN_GCC   -g     -I. -I. -I./config
        version.c
cc -Wf,-XNg1500 -Olimit 3000 -O1 -c  -DIN_GCC   -g     -I. -I. -I./config
        obstack.c
cc -Wf,-XNg1500 -Olimit 3000 -O1  -DIN_GCC   -g   -o cccp cccp.o cexp.o
        version.o obstack.o ` case "cc -Wf,-XNg1500 -Olimit 3000 -O1" in "cc -Wf
   ,
        -XNg1500 -Olimit 3000 -O1") echo  ;; esac `  -lmld
*** Error code 1
ld:
Can't locate file for: -lmld

stop

*******************************************************************************
From: adda@acri.FR (Serge Adda)
Newsgroups: gnu.gcc.bug
Subject: emit_store_flag
Date: 22 Jan 1993 21:44:32 -0500
Organization: Advanced Computer Research Institute
Distribution: gnu

I think there are 2 problems in emit_store_flag,
1 minor and 1 major.

the minor: subtarget is declared twice; so debugging is difficult.

the major: the call to compare_from_rtx at line 2802 could invert
the comparison; so icode should be reset using the comparison code
of comparison.  I wrote my MD file using the example in the docu-
mentation. So the compare_from_rtx, in fact, actually stores both 
operands with an order which doesn't corespond to the old code.
I know I can fix the problem if I store the new code and compare
it with the old one during the generation of the comparison
pattern; but it is better to fix the problem in the emit_store_flag
function.



Serge Adda - A.C.R.I. Compiler Team
email: adda@acri.fr