headers
Tom Lane | 4 Oct 17:02
Picon

[GNU Bison 2.3] testsuite: 129 failed

You probably know about this already, but both 2.2 and 2.3 fail "make
check" when built on a current Fedora Core 5 / x86_64 machine.  I've
attached testsuite.log as requested by the script.  Will be happy to
do more investigation if you tell me what to look at.

			regards, tom lane


## ------------------------- ##
## GNU Bison 2.3 test suite. ##
## ------------------------- ##

testsuite: command line was:
  $ ./testsuite 

## ----------- ##
## ChangeLogs. ##
## ----------- ##

testsuite: ../ChangeLog:
| 2006-06-05  Paul Eggert  <eggert <at> cs.ucla.edu>
| 
| 	* NEWS: Version 2.3.
| 	* configure.ac (AC_INIT): Likewise.
| 
| 2006-05-30  Paul Eggert  <eggert <at> cs.ucla.edu>
| 
| 	* data/glr.c (YYRECOVERING): Define to be a function-like macro
| 	with no arguments, not as an object-like macro.  This is for
| 	compatibility with data/yacc.c.  Problem reported by John P. Hartmann in
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul Eggert | 5 Oct 21:14
Favicon

Re: [GNU Bison 2.3] testsuite: 129 failed

Tom Lane <tgl <at> sss.pgh.pa.us> writes:

> You probably know about this already,

No, sorry, I don't.  Thanks for reporting it.

What happens when you try this?

$ cd tests
$ ./testsuite -v -d 129
$ cd testsuite.dir/129
$ gcc -g -DYYDEBUG -o foo expect2.c
$ gdb ./foo
(gdb) b main
(gdb) r
(gdb) p yydebug=1
(gdb) c

On my machine, the last command generates the following output, which
is correct.  Evidently your machine does something different and we
need to find out why.

Continuing.
Starting parse
Entering state 0
Reducing stack 0 by rule 1 (line 23):
-> $$ = nterm program ()
Entering state 1
Reading a token: Next token is token A ()
Shifting token A ()
(Continue reading)

Permalink | Reply | 7 comments |
headers
Tom Lane | 5 Oct 21:27
Picon

Re: [GNU Bison 2.3] testsuite: 129 failed

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:
> What happens when you try this?

I get the same output as you up until the error recovery phase:
where you show

> syntax error, unexpected '+', expecting A or B
> Error: popping token '+' ()
> Error: popping nterm e ()
> Shifting token error ()
> Entering state 3
> Error: discarding token '+' ()
> Reading a token: Next token is token $end ()
> Error: discarding token $end ()
> Reading a token: Next token is token $end ()
> Cleanup: popping token error ()
> Cleanup: popping nterm program ()
> Cleanup: popping token $end ()
> Program exited with code 01.

I get

syntax error, unexpected '+', expecting A or B
Error: popping token '+' ()
Error: popping nterm e ()
Shifting token error ()
Entering state 3
Error: discarding token '+' ()
Reading a token: Next token is token $end ()
Error: discarding token $end ()
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tom Lane | 5 Oct 22:22
Picon

Re: [GNU Bison 2.3] testsuite: 129 failed

I wrote:
> Not sure what to make of this, but happy to look where you tell me to.

Actually, having traced through it, the problem is obvious: yylex() is
called more than four times and starts to return machine-dependent
garbage after the fourth call.

static int
yylex (void)
{
  static int toknum = 0;
  static int tokens[] =
    {
      1000, '+', '+', -1
    };

  return tokens[toknum++];
}

I suppose this is a bug in the testsuite case, not in bison itself.

			regards, tom lane
Permalink | Reply | 5 comments |
headers
Paul Eggert | 6 Oct 01:19
Favicon

Re: [GNU Bison 2.3] testsuite: 129 failed

Tom Lane <tgl <at> sss.pgh.pa.us> writes:

> Actually, having traced through it, the problem is obvious: yylex() is
> called more than four times and starts to return machine-dependent
> garbage after the fourth call.

OK, but why is yylex being calling more than four times?  It's called
only four times on my host.  So there is some _other_ bug that the
yylex issue is a symptom of.

The problem is, how do we isolate that bug?  One way to do it
is to use GDB to trace through the same test on both a working
host (e.g., Debian stable) and your non-working one, and see
where the two behaviors start to diverge.
Permalink | Reply | 4 comments |
headers
Tom Lane | 6 Oct 01:24
Picon

Re: [GNU Bison 2.3] testsuite: 129 failed

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:
> OK, but why is yylex being calling more than four times?  It's called
> only four times on my host.

Are you really sure of that?  I count five "Reading a token" in your
debug printout.

I see it being called more than 4 times on both an x86 and x86_64
machine --- but the former passes the testsuite, apparently because
whatever happens to be right after the static array looks like an EOF
symbol.

			regards, tom lane
Permalink | Reply | 3 comments |
headers
Paul Eggert | 6 Oct 07:58
Favicon

Re: [GNU Bison 2.3] testsuite: 129 failed

Tom Lane <tgl <at> sss.pgh.pa.us> writes:

> Paul Eggert <eggert <at> CS.UCLA.EDU> writes:
>> OK, but why is yylex being calling more than four times?  It's called
>> only four times on my host.
>
> Are you really sure of that?

No, I guess you're right.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 6 Oct 09:00
Favicon

Re: [GNU Bison 2.3] testsuite: 129 failed

OK, I think I figured out the problem.  Thanks again for reporting it.
I installed this:

2006-10-05  Paul Eggert  <eggert <at> cs.ucla.edu>

	Fix test failure reported by Tom Lane in
	<http://lists.gnu.org/archive/html/bug-bison/2006-10/msg00000.html>
	and try to make such failures easier to catch in the future.
	* data/glr.c (YYTRANSLATE): Don't check for nonpositive arg;
	that's now the caller's responsibility.
	(yyprocessOneStack, yyrecoverSyntaxError, yyparse):
	Set yychar = YYEOF if it's negative.
	* tests/actions.at (yylex): Abort if asked to read past EOF.
	* tests/conflicts.at (yylex): Likewise.
	* tests/cxx-type.at (yylex): Likewise.
	* tests/glr-regression.at (yylex): Likewise.
	* tests/input.at (yylex): Likewise.
	* tests/regression.at (yylex): Likewise.
	* tests/torture.at (yylex): Likewise.

Index: data/glr.c
===================================================================
RCS file: /cvsroot/bison/bison/data/glr.c,v
retrieving revision 1.188
diff -p -u -r1.188 glr.c
--- data/glr.c	11 Aug 2006 19:50:14 -0000	1.188
+++ data/glr.c	6 Oct 2006 06:48:45 -0000
@@ -346,8 +346,7 @@ static YYSTYPE yyval_default;
 #define YYMAXUTOK   ]b4_user_token_number_max[
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel E. Denny | 15 Oct 00:42

warnings -> errors in lib

$(WERROR_CFLAGS) was recently added to AM_CFLAGS in lib/Makefile.am.  
This breaks --enable-gcc-warnings because of a number of "discards 
qualifiers" warnings in lib.
Permalink | Reply | 1 comment |
headers
Paul Eggert | 15 Oct 06:31
Favicon

Re: warnings -> errors in lib

"Joel E. Denny" <jdenny <at> ces.clemson.edu> writes:

> $(WERROR_CFLAGS) was recently added to AM_CFLAGS in lib/Makefile.am.  
> This breaks --enable-gcc-warnings because of a number of "discards 
> qualifiers" warnings in lib.

Thanks for mentioning that; the change was inadvertent, and I undid
it.
Permalink | Reply | 0 comments |

Gmane