headers
Juan Manuel Guerrero | 9 Jan 21:08
Picon
Picon

test 145 failure

I have tried to compile todays cvs sources and test 145 of the testsuite failed.
The output of uname -a is:
  Linux localhost 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 i686 GNU/Linux
It is an OpenSUSE 10.0 system and the compiler used is:
  gcc 4.0.2
and the linker is:
  ld 2.16.91.0.2

The output of at-stderr is:
glr-regr18.y:26.18-24: result type clash on merge function `merge': <type2> != <type1>
glr-regr18.y:25.18-24: previous declaration
glr-regr18.y:27.13-19: result type clash on merge function `merge': <type3> != <type2>
glr-regr18.y:26.18-24: previous declaration

If more information is required, please contact me.

Regards,
Juan M. Guerrero
Attachment (testsuite.log.bz2): application/x-bzip2, 38 KiB
Permalink | Reply | 4 comments |
headers
Paul Eggert | 9 Jan 22:24
Favicon

Re: test 145 failure

Juan Manuel Guerrero <juan.guerrero <at> gmx.de> writes:

> If more information is required, please contact me.

If you run the test case manually like this:

cd tests
./testsuite -v -d 145

and then try to execute it under GDB, like this:

cd testsuite.dir/145
gdb ./input
r 900

what happens?  Perhaps you can get a stack backtrace after failure?
Permalink | Reply | 3 comments |
headers
Juan Manuel Guerrero | 10 Jan 00:13
Picon
Picon

Re: test 145 failure

Am Dienstag, 9. Januar 2007 22:24 schrieben Sie:
> Juan Manuel Guerrero <juan.guerrero <at> gmx.de> writes:
> 
> > If more information is required, please contact me.
> 
> If you run the test case manually like this:
> 
> cd tests
> ./testsuite -v -d 145
> 
> and then try to execute it under GDB, like this:
> 
> cd testsuite.dir/145
> gdb ./input
> r 900
> 
> what happens?  Perhaps you can get a stack backtrace after failure?

I have run the test case manually. The output is in testsuite.log.bz2.
The test case has been run from inside GDB again. A stack backtrace
has been produced. The GDB output is in gdb.out.bz2

If more info is needed, contact me again.

Regards,
Juan M. Guerrero
Attachment (testsuite.log.bz2): application/x-bzip2, 9 KiB
Attachment (gdb.out.bz2): application/x-bzip2, 2446 bytes
Permalink | Reply | 2 comments |
headers
Paul Eggert | 10 Jan 06:19
Favicon

Re: test 145 failure

Thanks.  I can reproduce the problem as follows, with CVS Bison on
Debian stable (with my own copy of GCC 4.1.1).  It sure looks like a
bug in the Bison skeleton.

It seems to be related to recent changes in the yacc.c skeleton.  OK,
guys, will someone who changed the skeleton recently like to look at
this problem?

$ cd tests
$ VALGRIND_OPTS='--leak-check=full --show-reachable=yes' ./testsuite PREBISON='valgrind -q'
PREPARSER='valgrind -q' -v -d 145
## --------------------------- ##
## GNU Bison 2.3a+ test suite. ##
## --------------------------- ##
145. torture.at:474: testing ...
./torture.at:483: bison -o input.c input.y
...
./torture.at:497: $PREPARSER ./input 900
stderr:
Starting parse
Entering state 0
Reading a token: Next token is token WAIT_FOR_EOF ()
Shifting token WAIT_FOR_EOF ()
Entering state 1
Return for a new token:
Reading a token: Next token is token WAIT_FOR_EOF ()
Shifting token WAIT_FOR_EOF ()
Entering state 1
...
Reading a token: Next token is token WAIT_FOR_EOF ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Van Holder | 11 Jan 17:08
Picon
Favicon

http://www.gnu.org/software/bison/

Carsten Clark wrote:
> Hi,
> 
> The main Bison page at http://www.gnu.org/software/bison/ contains an
> HTTPS link to the Bison Savannah repository that I think should be a
> plain HTTP link:
> 
> <p>
>   Test versions of Bison can be found on
>   <a
> href="ftp://alpha.gnu.org/gnu/bison/">ftp://alpha.gnu.org/gnu/bison/≤/a>
>   [via FTP]. The latest bleeding-edge version of the source code, along
>   with a revision history, can be found in the
>   <a href="https://savannah.gnu.org/projects/bison/">Bison
>   Savannah repository</a>.
>   Please note that we do not suggest using Bison sources from these
>   locations for production use.
> 
> Following the HTTPS link, my browser (Safari) complains about lack of a
> certificate.  If I use HTTP, I get the same page without the certificate
> warning.

No, it complains about the lack of a VALID certificate, because it is
a self-signed certificate (Issued By: Savannah Hackers) (plus, it
expires in a couple of days). So the https link is not wrong as such.

However, I agree that there is no real reason to use a https link on
the bison site when a http works just fine (and is less likely to cause
undue hassle for visitors).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Eggert | 11 Jan 18:53
Favicon

http://www.gnu.org/software/bison/

Carsten Clark <cdc6d <at> ccri.com> writes:

> The main Bison page at http://www.gnu.org/software/bison/ contains an
> HTTPS link to the Bison Savannah repository that I think should be a
> plain HTTP link:

Thanks, I fixed that.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 11 Jan 21:52
Favicon

Re: [GNU Bison 2.1] testsuite: 83 failed

Michael McLaughlin <mmclaughlin1 <at> cox.net> writes:

> 83. calc.at:587: testing ...
> calc.at:587: bison -o calc.c calc.y
> calc.at:587: $CC $CFLAGS $CPPFLAGS $LDFLAGS -o calc calc.c $LIBS
> stderr:
> stdout:
> calc.at:587: $PREPARSER ./calc input
> stderr:
> calc.at:587: $PREPARSER ./calc input
> stderr:
> 1.2: syntax error
> calc.at:587: cat stderr
> calc.at:587: $PREPARSER ./calc input
> stderr:
> 1.2: syntax error
> mv: rename at-stderr to stderr: No such file or directory

It's a bit weird that you'd get that message, since the previous
command was supposed to create a file named 'at-stderr'.  I wouldn't
worry about it too much, though.  It looks like a build hiccup to me.

Perhaps you should consider upgrading to Bison 2.3, though.
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 12 Jan 23:21

Re: test 145 failure

Another ignored message.

On Tue, 9 Jan 2007, Joel E. Denny wrote:

> On Tue, 9 Jan 2007, Juan Manuel Guerrero wrote:
> 
> > I have tried to compile todays cvs sources and test 145 of the testsuite failed.
> 
> Thanks for reporting this.
> 
> The problem is that push parsers can't use alloca since the stacks can't 
> be locals.  I'll commit a patch soon to prevent push parsers from paying 
> attention to YYSTACK_USE_ALLOCA.
> 
> It turns out that Valgrind was actually detecting this problem on my 
> system before the seg fault, but we're still not using the right 
> combination of Valgrind flags in order to see it.  I'll look into it.
>
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 12 Jan 23:21

Re: test 145 failure

Another ignored message.

On Tue, 9 Jan 2007, Joel E. Denny wrote:

> On Tue, 9 Jan 2007, Joel E. Denny wrote:
> 
> > The problem is that push parsers can't use alloca since the stacks can't 
> > be locals.  I'll commit a patch soon to prevent push parsers from paying 
> > attention to YYSTACK_USE_ALLOCA.
> 
> I committed the following.
> 
> I hope I haven't missed any messages in this thread.  The mailing list is 
> slow again.
> 
> Index: ChangeLog
> ===================================================================
> RCS file: /sources/bison/bison/ChangeLog,v
> retrieving revision 1.1657
> diff -p -u -r1.1657 ChangeLog
> --- ChangeLog	9 Jan 2007 05:32:14 -0000	1.1657
> +++ ChangeLog	10 Jan 2007 00:44:45 -0000
> @@ -1,3 +1,13 @@
> +2007-01-09  Joel E. Denny  <jdenny <at> ces.clemson.edu>
> +
> +	Ignore YYSTACK_USE_ALLOCA for push parsers since the stacks can't be
> +	locals.  Reported by Juan Manuel Guerrero at
> +	<http://lists.gnu.org/archive/html/bug-bison/2007-01/msg00000.html>.
> +	* data/push.c: Enclose the #ifdef YYSTACK_USE_ALLOCA in b4_push_if.
> +	Fix some indentation also.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel E. Denny | 12 Jan 23:21

Re: test 145 failure

Another ignored message.

On Tue, 9 Jan 2007, Joel E. Denny wrote:

> On Tue, 9 Jan 2007, Joel E. Denny wrote:
> 
> > It turns out that Valgrind was actually detecting this problem on my 
> > system before the seg fault, but we're still not using the right 
> > combination of Valgrind flags in order to see it.  I'll look into it.
> 
> Rather, that test case was just ignoring stderr.  I committed the 
> following to fix that.  I think there are other test cases that need this 
> as well, but I'm going to be lazy and leave that to someone else.
> 
> Index: ChangeLog
> ===================================================================
> RCS file: /sources/bison/bison/ChangeLog,v
> retrieving revision 1.1658
> diff -p -u -r1.1658 ChangeLog
> --- ChangeLog	10 Jan 2007 00:50:55 -0000	1.1658
> +++ ChangeLog	10 Jan 2007 02:49:06 -0000
> @@ -1,5 +1,14 @@
>  2007-01-09  Joel E. Denny  <jdenny <at> ces.clemson.edu>
>  
> +	* tests/local.at (AT_PARSER_CHECK): Add a PRE argument to specify a
> +	command-line prefix.
> +	* tests/torture.at (Exploding the Stack Size with Alloca): Stderr is
> +	ignored, so use that PRE to set --log-fd=1 in VALGRIND_OPTS so we don't
> +	miss Valgrind messages.
> +	(Exploding the Stack Size with Malloc): Likewise.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane