[comp.sys.att] GNU emacs on a 3B2

storm@ambush.UUCP (Kim F. Storm) (10/22/87)

In article <806@mrstve.UUCP> rjk@mrstve.UUCP (Richard Kuhns) writes:

>I've got 2 problems running GNU emacs on a 3B2/400, System V Rel 3.1,
>4 MB RAM, and I'd greatly appreciate some help.

>First, substitute-command-keys doesn't work -- the only character it
>can substitute is RET (meaning, where I should normally get
>`C-X 4 B RET', all that comes out is RET).

My guess is that you have compiled GNU with "cc -O " which among other
problems causes substitute-command-keys to behave exactly as you describe.

Be shure that C_OPTIMIZE_SWITCH is defined to *nothing* in m-att3b.h, and
that you don't change it elsewhere.  To quote from m-att3b.h:

	-O has been observed to make correct C code in Emacs not work.
	So don't try to use it. 

When I got issue 4 of the 3B2 C compiler, I tried it anyway to see if the 
problems had gone away, but NO LUCK:

I got the problem you describe, and many others of a similar kind.

I tracked most of these problems (including yours) to the function
'mapconcat' which did not work, but I never figured out why (except
that it seems that nargs == -1, but ...).


Another effect of using -O was that the command-history contains a meaningless
expression like

	((eval-expression (quote eval-expression)) ...)

which I don't think I ever tracked down (perhaps it was mapconcat as well?).


Any comments from AT&T ?

--
Kim F. Storm, storm@ambush.uucp (or ..!mcvax!diku!ambush!storm)
AmbraSoft A/S, Rojelskaer 15, DK-2840 Holte, Denmark.  tel: +45 2424 111

dougm@ico.UUCP (Doug McCallum) (10/25/87)

In article <535@ambush.UUCP> storm@ambush.UUCP (Kim F. Storm) writes:
>In article <806@mrstve.UUCP> rjk@mrstve.UUCP (Richard Kuhns) writes:
>
...
>
>I tracked most of these problems (including yours) to the function
>'mapconcat' which did not work, but I never figured out why (except
>that it seems that nargs == -1, but ...).
>
>
>Another effect of using -O was that the command-history contains a meaningless
>expression like

I've seen the same problem on V.3 on a 386.  If the file fns.c is compiled
with -O, the problem is seen (on 18.40 but not 18.44).  What is happening
is that the call to Fconcat in mapconcat is getting expanded inline to
a direct call to concat.  During the expansion, the optimizer is blowing
the stack.  At least this is what happens on the 386 compiler.  This sounds
like a generic RCC optimizer bug.