From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5632 invoked by alias); 26 Apr 2002 18:46:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5552 invoked from network); 26 Apr 2002 18:46:09 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 26 Apr 2002 18:46:09 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g3QIk4d15749; Fri, 26 Apr 2002 13:46:04 -0500 Date: Fri, 26 Apr 2002 11:50:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200204261846.g3QIk4d15749@duracef.shout.net> To: dave@hiauly1.hia.nrc.ca, jsm28@cam.ac.uk Subject: Re: bison 1.33 problem with mainline c-parse.in: yyfree_stacks Cc: gcc@gcc.gnu.org X-SW-Source: 2002-04/txt/msg01455.txt.bz2 The red herring ... I did build my bison 1.33 with --disable-nls. But I rebuilt bison 1.33 and the gcc build still fails. I'm not an "intl" expert, but it looks like intl/plural.y is part of the intl library that goes with the bison executable and is not part of bison.hairy or bison.simple. It just happens to be a bison program so it gets processed with bison. In bison-1.33.tar.gz, intl/plural.c was built with bison 1.28. That is why we see the simple "yyfree_stacks" in it. The bison story ... "yyfree_stacks" in bison.simple disappeared between bison 1.30 and bison 1.31. In the CVS version of bison, Paul Eggert removed it in 1.53.2.8 of src/bison.simple (this is on a branch and the file has been moved to data/bison.simple since then, what fun). It looks like part of a big memory-management cleanup. cvs log entry appended. Here is the logic flow: yyss, yyvs, yyls are initialized to point to auto arrays. yyoverflow can change these pointers to point to heap arrays. yyfree_stacks tracks whether yyss, yyvs, yyls point to auto or heap. if yyfree_stacks is true, you may call realloc() to grow the stacks. if yyfree_stacks is true, yyparse() must call free() before returning. The old parser does: yyacceptlab: if (yyfree_stacks) { free (yyss); free (yyvs); #if YYLSP_NEEDED free (yyls); #endif } return 0; But the new parser does: yyreturn: #ifndef yyoverflow if (yyss != yyssa) YYSTACK_FREE (yyss); #endif return yyresult; It's hard to write a yyoverflow that works with both versions of bison.simple. yyoverflow can have its own local version of "yyfree_stacks" and ignore the one that belongs to yyparse. But this produces a memory leak with old-style bison.simple that needs to see "yyfree_stacks" set to 1. What to do ... gcc/configure already checks the version of bison. Perhaps write yyoverflow for the new parser only (bison 1.31 or later) and then require bison 1.31 in gcc/configure? gcc/configure could also pass the bison version in a configuration variable to c-parse.in, so that c-parse.in could have code for both cases. Right now, the code works only with old bison (bison 1.30 or earlier) and there is no check. Oy! Michael C === # cvs log src/bison.simple revision 1.53.2.8 date: 2001/11/30 02:47:56; author: eggert; state: Exp; lines: +93 -67 (YYSTACK_REALLOC): Remove. (YYSTACK_ALLOC): Resurrect this macro, with its old meaning. (YYSTACK_FREE, YYSTACK_GAP_MAX, YYSTACK_BYTES, YYSTACK_RELOCATE): New macros. (union yyalloc): New type. (__yy_memcpy): Last arg is size_t, not unsigned int, to remove an arbitrary restriction on hosts where size_t is wider than int. (yyparse): Don't dump core if alloca or malloc fails; instead, report a parser stack overflow. Allocate just one block of memory for all three stacks, instead of allocating three blocks; this typically is faster and reduces fragmentation. Do not limit the number of items in the stack to a value that fits in 'int', as this is an arbitrary limit on hosts with 64-bit size_t and 32-bit int.