home *** CD-ROM | disk | FTP | other *** search
Emacs RMAIL | 1988-07-11 | 4.7 KB | 139 lines |
- BABYL OPTIONS:
- Version: 5
- Labels:
- Note: This is the header of an rmail file.
- Note: If you are seeing it in rmail,
- Note: it means the file has no messages in it.
-
- 1,forwarded,,
- Summary-line: 1-Apr tower #["ASC::GUTHERY%slb-test.csnet"@RELAY.CS.NET: Bison Bug?]
- Received: by PREP.AI.MIT.EDU; Wed, 1 Apr 87 20:10:49 EST
- Date: Wed, 1 Apr 87 20:10:49 EST
- From: tower (Leonard H. Tower Jr.)
- Message-Id: <8704020110.AA00495@prep.ai.mit.edu>
- To: rms
- Subject: ["ASC::GUTHERY%slb-test.csnet"@RELAY.CS.NET: Bison Bug?]
- Reply-To: tower@prep.ai.mit.edu
- Organization: Project GNU, Free Software Foundation,
- 1000 Mass. Ave., Cambridge, MA 02138, USA +1 (617) 876-3296
- Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739
- Status: O
-
- *** EOOH ***
- Date: Wed, 1 Apr 87 20:10:49 EST
- From: tower (Leonard H. Tower Jr.)
- To: rms
- Subject: ["ASC::GUTHERY%slb-test.csnet"@RELAY.CS.NET: Bison Bug?]
- Reply-To: tower@prep.ai.mit.edu
- Organization: Project GNU, Free Software Foundation,
- 1000 Mass. Ave., Cambridge, MA 02138, USA +1 (617) 876-3296
- Home: 36 Porter Street, Somerville, MA 02143, USA +1 (617) 623-7739
-
- Date: Wed, 1 Apr 87 14:12 EDT
- From: "guthery%asc%slb-doll.csnet@relay.cs.net" <"ASC::GUTHERY%slb-test.csnet"@RELAY.CS.NET>
- To: gnu@PREP.AI.MIT.EDU
- Subject: Bison Bug?
- X-Vms-To: SDR::IN%"gnu@prep.ai.mit.edu"
-
- In the build_relations function in the lalr.c file in GNU Bison,
- the code
-
- length--;
- done = 0;
- while(!done) ...
-
- should, I believe, be replaced with
-
- length--;
- done = 0;
- if(length) while(!done) ...
-
- otherwise things like
-
- list: /* empty */ | item | list item;
-
- produce an internal error in map_goto.
-
- Cheers, Scott
-
-
-
-
- 1,,
- Return-Path: <rms@wheaties.ai.mit.edu>
- Received: by frosted-flakes.ai.mit.edu; Wed, 23 Sep 87 12:49:33 EDT
- Date: Wed, 23 Sep 87 12:49:33 EDT
- From: rms@wheaties.ai.mit.edu (Richard Stallman)
- Message-Id: <8709231649.AA18034@frosted-flakes.ai.mit.edu>
- To: rms
- Subject: Bison
-
- *** EOOH ***
- Return-Path: <rms@wheaties.ai.mit.edu>
- Date: Wed, 23 Sep 87 12:49:33 EDT
- From: rms@wheaties.ai.mit.edu (Richard Stallman)
- To: rms
- Subject: Bison
-
- Bison should have a feature to specify a prefix for all the names.
-
-
- 1,answered,,
- Received: from prep.ai.mit.edu by wheaties.ai.mit.edu; Thu, 31 Dec 87 00:31:49 EST
- Received: by PREP.AI.MIT.EDU; Thu, 31 Dec 87 00:26:53 EST
- Received: from balance.aca.mcc.com by MCC.COM with TCP; Wed 30 Dec 87 23:32:14-CST
- Date: Wed, 30 Dec 87 23:33:06 cst
- From: tiemann@mcc.com (Michael Tiemann)
- Posted-Date: Wed, 30 Dec 87 23:33:06 cst
- Message-Id: <8712310533.AA17290@balance.aca.mcc.com>
- Received: by balance.aca.mcc.com (4.12/ACA-V2.1)
- id AA17290; Wed, 30 Dec 87 23:33:06 cst
- To: rms@prep.ai.mit.edu
- Subject: -fomit-frame-pointer (and YYEMPTY)
- Status: RO
-
- *** EOOH ***
- Date: Wed, 30 Dec 87 23:33:06 cst
- From: tiemann@mcc.com (Michael Tiemann)
- Posted-Date: Wed, 30 Dec 87 23:33:06 cst
- To: rms@prep.ai.mit.edu
- Subject: -fomit-frame-pointer (and YYEMPTY)
-
- YYEMPTY is true iff there is no current lookahead symbol. Such a case
- arises after a shift, before the next call to yylex. Note that often,
- reductions can be performed in the absense of any lookahead symbols.
- By not reading the next symbol immediately after shifting, it is
- possible for the parser to change the state of the lexical analyzer
- before it goes after the next input symbol.
-
- On the -fomit-frame-pointer front, I could not reproduce the bug
- (which I only observed as a segmentation violation). When I could not
- reproduce it on SB-Prolog, I recompiled GCC with itself, using
- -fomit-frame-pointer. It did not blink. The total speed improvement
- was about 1-2%. However, someone is running a large experiment on the
- Balance which is keeping it from giving me "clean" readings. Here are
- the total times for each complete make:
-
- gcc -O: 3026.3u 757.1s 1:05:37 96% 3396+3848io 639pf+0w
- gcc -O -fomit-frame-pointer: 2981.8u 749.0s 1:04:41 96% 3415+3810io 628pf+0w
-
- These include the assembly and link times. Here are the two compiling
- the file expr.c:
-
- -O -fomit-frame-pointer -O alone
- time in parse: 47.660000 time in parse: 47.770000
- time in jump: 5.590000 time in jump: 5.830000
- time in cse: 13.860000 time in cse: 14.120000
- time in loop: 1.240000 time in loop: 1.230000
- time in flow: 15.940000 time in flow: 15.980000
- time in combine: 4.320000 time in combine: 4.520000
- time in local-alloc: 11.870000 time in local-alloc: 12.150000
- time in global-alloc: 15.310000 time in global-alloc: 15.840000
- time in final: 8.850000 time in final: 9.410000
- time in varconst: 0.510000 time in varconst: 0.690000
- time in symout: 0.000000 time in symout: 0.000000
- time in dump: 0.000000 time in dump: 0.000000
-
- Michael
-
-