headers
Michael Deutschmann | 8 Sep 04:32

[GNU Bison 2.3] testsuite: 103 104 failed

{I sent this message last August, but I recieved no response and the
message has not even appeared in the archives.  I suspect there may be
something in the list software that silently drops posts with large
attachments, so I've omitted the testsuite.log file this time.}

I've experienced some test failures after compiling bison 2.3, #103 and
#104.

I've investigated and found the cause.  The parser skeleton uses a local
version of the stpcpy() function, which is not standard but is present in
GLIBC, which only declares it if _GNU_SOURCE is defined.

The code tries to be clever and detect this circumstance automatically,
replacing the local yystpcpy() function with a reference to stpcpy() if
GLIBC is in use and _GNU_SOURCE is defined.  This avoids unneeded
namespace pollution, but takes advantage if the programmer already set
_GNU_SOURCE in his prologue region (between %{ and %}).

The trouble is, the C++ parser includes library headers before including
the prologue region.  After the first library header is loaded, the
setting of _GNU_SOURCE and related macros becomes effectively locked --
changing them will have no effect on what functions are declared.

So if _GNU_SOURCE is defined in the prologue of the .y file, it will have
no effect on the GLIBC headers.  But it will still be defined, fooling the
parser skeleton into assuming _GNU_SOURCE is in effect and stpcpy() is
available.

The code in tests #103/#104 effectively includes _GNU_SOURCE in the
headers (via "config.h").  The resulting C++ code attempts to use stpcpy()
(Continue reading)

Permalink | Reply | 17 comments |
headers
Paul Eggert | 11 Sep 19:48
Favicon

Re: Bison can not create LR table

zdprikryl <zdprikryl <at> seznam.cz> writes:

> If I write grammar like below, than bison prints this:
>
> conflicts: 1 reduce/reduce
> warning: rule never reduced because of conflicts: ireg_MOVE_INDIRECT_A: ireg
> warning: rule never reduced because of conflicts:
> ireg_MOVE_INDIRECT_DATA: ireg

Thanks for the bug report, but when I try to compile that test case
with Bison 2.3 using the command "bison test.y", Bison outputs:

   test.y:1.1-20: syntax error, unexpected identifier:

which is correct, as the %% is missing.  (Prepending %% causes
further problems.)

Please send us a complete, self-contained test case so that we can
reproduce the problem.  Thanks.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 11 Sep 20:03
Favicon

Re: calc++ example leaks

"Sander Brandenburg" <sander.brandenburg <at> gmail.com> writes:

> Below is a fix for the memory leaks. I'm only not sure the way I solve it is
> good practice, because keeping track of what needs to be deleted looks
> rather cumbersome.

Thanks for the bug report.  Yes, it is cumbersome, but I'm afraid that
for Bison right now that's life in the C++ city.  I installed this
patch to fix the upstream source (and some minor white space and
comment issues):

2006-09-11  Paul Eggert  <eggert <at> cs.ucla.edu>

	* doc/bison.texinfo (Calc++ Parser): Fix memory leak reported by
	Sander Brandenburg in
	<http://lists.gnu.org/archive/html/bug-bison/2006-09/msg00002.html>.
	Also, fix minor white space and comment issues.

--- doc/bison.texinfo.~1.203.~	2006-09-11 10:48:45.000000000 -0700
+++ doc/bison.texinfo	2006-09-11 10:53:30.000000000 -0700
@@ -7423,8 +7423,8 @@ factor both as follows.

 @comment file: calc++-driver.hh
 @example
-// Announce to Flex the prototype we want for lexing function, ...
-# define YY_DECL					\
+// Tell Flex the lexer's prototype ...
+# define YY_DECL                                        \
   yy::calcxx_parser::token_type                         \
   yylex (yy::calcxx_parser::semantic_type* yylval,      \
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Eggert | 11 Sep 21:00
Favicon

Re: [GNU Bison 2.3] testsuite: 103 104 failed

Thanks for reporting that.

This before-header and after-header business is wayyyy too
complicated!  Someone really ought to fix the underlying problem since
I hardly even understand the current rules myself, and I don't expect
users to understand it.  (Sheesh!  what a mess....)

Anyway, I installed the following patch, which should fix your
particular problem, and document the issues a bit better.

2006-09-11  Paul Eggert  <eggert <at> cs.ucla.edu>

	* data/glr.c (b4_shared_declarations): Put start-header first,
	before any #includes that we generate, so that feature-test
	macros work.  Problem reported by Michael Deutschmann in
	<http://lists.gnu.org/archive/html/bug-bison/2006-09/msg00004.html>.
	* data/lalr1.cc: Likewise.
	* doc/bison.texinfo (Prologue): Document that feature-test macros
	should be defined before any Bison declarations.
	* tests/actions.at (_AT_CHECK_PRINTER_AND_DESTRUCTOR): Put defns
	that depend on location.hh after, not before, Bison decls, since
	we now include location.hh after the first user prologue.

Index: data/glr.cc
===================================================================
RCS file: /cvsroot/bison/bison/data/glr.cc,v
retrieving revision 1.24
diff -p -u -r1.24 glr.cc
--- data/glr.cc	9 Jul 2006 20:36:33 -0000	1.24
+++ data/glr.cc	11 Sep 2006 18:54:42 -0000
(Continue reading)

Permalink | Reply | 15 comments |
headers
Paul Eggert | 11 Sep 21:03
Favicon

Re: bison tests failed on Mandriva 2006

S A Burns <santhburns <at> earthlink.net> writes:

> | gcc (GCC) 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)
> ...
> stack.hh:44: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:https://qa.mandriva.com/> for instructions.
> ...
>
/usr/lib/gcc/i586-mandriva-linux-gnu/4.0.1/../../../../include/c++/4.0.1/bits/stl_deque.h:134:
internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:https://qa.mandriva.com/> for instructions.

Thanks for reporting this, but it appears to be a bug in your
compiler, not in Bison itself.  Can you please report the bug to
Mandriva as suggested in the log?  Thanks.
Permalink | Reply | 0 comments |
headers
Paul Hilfinger | 11 Sep 21:29
Picon
Favicon

Re: Bison can not create LR table


With a few additions, I get the same result you did, but this grammar,
while it is LR(2), is not LR(1) or LALR(1).  Suppose that the input
contains

     MOV @ R 3 , #

At the crucial point, we'll have

   MOV @ R ireg

on the stack (right end is top) and "," as the lookahead.  This is not
enough data to decide whether to reduce to ireg_MOVE_INDIRECT_DIRECT,
ireg_MOVE_INDIRECT_A, or ireg_MOVE_INDIRECT_DATA.

Paul Hilfinger

    %term const_num

    %%

    inst: MOVE_INDIRECT_DIRECT | MOVE_INDIRECT | MOVE_INDIRECT_DATA ;

    MOVE_INDIRECT_DIRECT: "MOV" "@" "R" ireg_MOVE_INDIRECT_DIRECT ","
    dir_MOVE_INDIRECT_DIRECT
			  {
			  ...
			  };
    MOVE_INDIRECT: "MOV" "@" "R" ireg_MOVE_INDIRECT_A "," "A"
		    {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Deutschmann | 13 Sep 09:51

Re: [GNU Bison 2.3] testsuite: 103 104 failed

On Mon, 11 Sep 2006, you wrote:
> Thanks for reporting that.
>
> This before-header and after-header business is wayyyy too
> complicated!  Someone really ought to fix the underlying problem since
> I hardly even understand the current rules myself, and I don't expect
> users to understand it.  (Sheesh!  what a mess....)
>
> Anyway, I installed the following patch, which should fix your
> particular problem, and document the issues a bit better.

I can't test the patch, as it won't apply to bison-2.3.  Looking at the
rejections, it seems your development version has just drifted too much
from 2.3.

---- Michael Deutschmann <michael <at> talamasca.ocis.net>
Permalink | Reply | 8 comments |
headers
Paul Eggert | 13 Sep 21:50
Favicon

Re: [GNU Bison 2.3] testsuite: 103 104 failed

Michael Deutschmann <michael <at> talamasca.ocis.net> writes:

> I can't test the patch, as it won't apply to bison-2.3.  Looking at the
> rejections, it seems your development version has just drifted too much

OK, I just generated a new alpha version; please give it a try instead.

ftp://alpha.gnu.org/gnu/bison/bison-2.3a.tar.gz
Permalink | Reply | 6 comments |
headers
Paul Eggert | 13 Sep 21:58
Favicon

Bison test version 2.3a available

Bison test version 2.3a is now available.  An important change in 2.3a
is an experimental approach for replacing traditional Yacc prologue blocks.

Here is the URL:

ftp://alpha.gnu.org/gnu/bison/bison-2.3a.tar.gz

Here are the MD5 and SHA512 checksums:

64e334f0a44cb3bb5e8be6b122c97d4f 
bison-2.3a.tar.gz
d71147c289c695f9763e0e329189298e56116ead2f94e8aa6af6eaf16ebde2102cdd71008cd54f4dae587c7b14a86593541cee2bc5224e6d932aff2ec858ef5a
 bison-2.3a.tar.gz

To try this test version, please make sure you have GNU m4 1.4.6
<ftp://ftp.gnu.org/gnu/m4/m4-1.4.6.tar.gz> installed, and then execute
the following shell commands or their equivalents:

   wget ftp://alpha.gnu.org/gnu/bison/bison-2.3a.tar.gz
   gunzip <bison-2.3a.tar.gz | tar xf -
   cd bison-2.3a
   ./configure
   make
   make check

We particularly appreciate tests on unusual hosts.

Please report bugs to <bug-bison <at> gnu.org>.

Bison is a parser generator that is compatible with Yacc.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akim Demaille | 14 Sep 10:15
Picon
Picon
Picon
Gravatar

Re: calc++ example leaks

>>> "Paul" == Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

 > "Sander Brandenburg" <sander.brandenburg <at> gmail.com> writes:
 >> Below is a fix for the memory leaks. I'm only not sure the way I solve it is
 >> good practice, because keeping track of what needs to be deleted looks
 >> rather cumbersome.

 > Thanks for the bug report.  Yes, it is cumbersome, but I'm afraid
 > that for Bison right now that's life in the C++ city.

That the kind of things that is mandated by our current lack of
support for variants :(
Permalink | Reply | 0 comments |

Gmane