bug-bison
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]