🚀 go-pugleaf

Hi.  I recently grabbed gcc-1.32.tar.Z from uunet, and wanted to
make sure you knew about the problems I've had getting it to run
on my AT&T 3B1.

1) In m68k.md there was a "clrl" statement which should have been
inside an #if so that SGS would see "clr.l".  Here's the context diff:

=========cut here================================
*** m68k.md	Wed Dec 14 13:51:28 1988
--- md	Fri Jan 27 03:19:09 1989
***************
*** 689,694
    "*
  {
    if (operands[1] == const0_rtx)
      return \"clrl %0\";
    return \"pea %a1\";
  }")

--- 689,697 -----
    "*
  {
    if (operands[1] == const0_rtx)
+ #if defined (MOTOROLA) || defined (SGS)
+     return \"clr.l %0\";
+ #else
      return \"clrl %0\";
  #endif
    return \"pea %a1\";
***************
*** 690,695
  {
    if (operands[1] == const0_rtx)
      return \"clrl %0\";
    return \"pea %a1\";
  }")
  

--- 693,699 -----
      return \"clr.l %0\";
  #else
      return \"clrl %0\";
+ #endif
    return \"pea %a1\";
  }")
  
==========cut here=======================

You might want to make sure I got the #if conditions correct for other
machines.


2) I haven't been able to find this one in the code, but the symptoms are
that sometimes things are popped off the stack with a "add.w &val,%sp"
instead of a "add.l".  (I also saw "addq.w" vs. "addq.l") I did a diff
between the output of a 1.21 and 1.32 compile of a program I was using to
test the new version, and the only thing I noticed (besides the different
labeling convention) was this problem and the use of more "text"
statements in the newer version.  The 1.21-compiled version ran fine; the
1.32-compiled version would abort with inappropriate error messages (the
one I traced was a "Not a typewriter" error that I was getting in the
middle of a "getopt" shared library call, with correct input...) which
would seem to point to a trashed stack pointer.


I suspect you already know about these, but just in case...  I don't
get any of the gnu newsgroups on my machine, so if it's possible
could you send me mail if the 2nd problem above is fixed?  I'm using
gcc to generate code for a monitor EPROM for a 68000 homebrew system,
and I'd really like to use the newer version with its better optimization
features since the code is significantly smaller than what the SGS
compiler puts out, and is much more readable (when debugging time
comes around) than that put out by the SGS compiler.  If nothing else,
I would probably at least notice a patch if it were put in the gnu
directory on uunet, since I check there fairly regularly.


Thanks, and keep up the good work!
Steve Barber
Michigan Technological University
steveb@shade.ann-arbor.mi.us, or
steveb%shade@mailgw.cc.umich.edu