Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ico!dougm
From: dougm@ico.UUCP (Doug McCallum)
Newsgroups: comp.emacs,comp.sys.att
Subject: Re: GNU emacs on a 3B2 (compiler bug!)
Message-ID: <1781@ico.UUCP>
Date: Sat, 24-Oct-87 23:41:50 EST
Article-I.D.: ico.1781
Posted: Sat Oct 24 23:41:50 1987
Date-Received: Mon, 26-Oct-87 05:54:02 EST
References: <806@mrstve.UUCP> <535@ambush.UUCP>
Reply-To: dougm@ico.UUCP (Doug McCallum)
Organization: Interactive Systems Corp., Boulder CO
Lines: 19
Keywords: emacs ATT 3B2
Xref: mnetor comp.emacs:2122 comp.sys.att:1598

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.