[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Bison (2002-10-20) creates empty structures and initializers
From: |
Akim Demaille |
Subject: |
Re: CVS Bison (2002-10-20) creates empty structures and initializers |
Date: |
22 Oct 2002 10:33:45 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) |
| The Sun ONE Studio 7 C compiler rejects 7 GLR-related test cases in
| the CVS (2002-10-20) Bison test suite because they create empty
| structures and/or initializers. Here is a log of the verbose part of
| the tests. This looks related to Akim's recent changes to data/glr.c.
|
| ## --------------------------- ##
| ## GNU Bison 1.75a test suite. ##
| ## --------------------------- ##
| 61. calc.at:532: testing Calculator %glr-parser ...
| calc.at:532: bison -o calc.c calc.y
| calc.at:532: $CC $CFLAGS $CPPFLAGS calc.c -o calc
| stderr:
| "calc.c", line 117: zero-sized struct/union
| cc: acomp failed for calc.c
| calc.at:532: exit code was 2, expected 0
| 61. calc.at:532: FAILED near `calc.at:532'
Thanks, this is the same problem as the one reported by Rein Tollevik:
when locations are not used and YYLTYPE is not #defined, then we
create an empty yyltype.
Rein suggests this patch:
*** drift/gnu/bison/data/glr.c:1.1.1.1 Mon Oct 21 21:29:25 2002
--- drift/gnu/bison/data/glr.c Mon Oct 21 23:09:59 2002
***************
*** 172,178 ****
int first_line;
int first_column;
int last_line;
! int last_column;])[
} yyltype;
# define YYLTYPE ]b4_ltype[
# define YYLTYPE_IS_TRIVIAL 1
--- 172,179 ----
int first_line;
int first_column;
int last_line;
! int last_column;],[
! int dummy;])[
} yyltype;
# define YYLTYPE ]b4_ltype[
# define YYLTYPE_IS_TRIVIAL 1
This problem is not new, it is just that new tests exhibit it, but
it's in there since the first GLR checkin. The other tests from Paul
H. `workaround' this problem by:
#define YYLTYPE int
so the problem fades away :(
I'm not sure how to solve this issue. I'm not fond _at all_ of
conditionalizing all the code that uses locations :(
Maybe this is the right time to try to have a single stack in GLR?
Instead of three.
struct stack_elem
{
YYSYMBOLTYPE type;
YYSTYPE val;
YYLTYPE loc;
}
That might make it much easier to conditionalize the third guy.