warning: rule never reduced because of conflicts: @3: /* empty */
Hi !
I've added some mid-rule actions, and I get a message like this one:
$ bison --verbose -d lea.y
lea.y: conflicts: 4 shift/reduce, 3 reduce/reduce
lea.y:293.17-40: warning: rule never reduced because of conflicts: @3: /*
empty */
lea.y:317.17-40: warning: rule never reduced because of conflicts: @4: /*
empty */
lea.y:337.9-31: warning: rule never reduced because of conflicts: @5: /* empty
*/
When I normally get:
$ bison --verbose -d lea.y
lea.y: conflicts: 1 shift/reduce, 3 reduce/reduce
(I don't bother now about that 1 shift/reduce, 3 reduce/reduce :-)
This are the affected lines in lea.y:
- lines 292 to 294: -
| id_list
{ TRconst_dcl_reg($1); }
':' register
---
- lines 316 to 318: -
| id_list
{ TRtypes_dcl_reg($1); }
':' register
---
- lines 334 to 340: -
vars_dcl:
vars_noreg_dcl_list
| id_list
{ TRvars_dcl_reg($1); }
':' register //TODO: !
vars_dcl
;
---
Thanks in advance,
Edulix.
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: warning: rule never reduced because of conflicts: @3: /* empty */
At 12:44 +0200 2005/05/01, Eduardo Robles Elvira wrote: I've added some mid-rule actions, and I get a message like this one: $ bison --verbose -d lea.y lea.y: conflicts: 4 shift/reduce, 3 reduce/reduce lea.y:293.17-40: warning: rule never reduced because of conflicts: @3: /* empty */ lea.y:317.17-40: warning: rule never reduced because of conflicts: @4: /* empty */ lea.y:337.9-31: warning: rule never reduced because of conflicts: @5: /* empty */ If if you want an explanation of what that means, it means exactly what it says, namely, you have entered a grammar which is such that no parser input can cause those rules to be reduced. Normally that is an error in the grammar design. If you enter a mid-rule action, Bison will implement that by introducing an anonymous, empty rule, which thus is prone at generating conflicts, if not used cautiously. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Extra code in x.tab.h
Is it possible to direct bison to insert extra code into x.tab.h - I ask because my %union directive has as one of its members a struct that is defined in a separate header file - ideally this would be included in the generated x.tab.h otherwise I have to make sure it is always included first. Thanks, Rob == Rob Desbois Eml: rob dot NOSPAM desbois at gmail dot com If riding in an aeroplane is flying, then riding in a boat is swimming. If you want to experience the element, get out of the vehicle. Make hay not war. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: Extra code in x.tab.h
At 08:28 +0100 2005/04/30, Rob Desbois wrote: Is it possible to direct bison to insert extra code into x.tab.h - I ask because my %union directive has as one of its members a struct that is defined in a separate header file - ideally this would be included in the generated x.tab.h otherwise I have to make sure it is always included first. I do not think so. It is not as such because one just has to put the right M¤ macro in the skeleton file, and define this macro. But currently, I do not think there is a practical way to do it via Bison. There is an experimental %define command, but it is not currently suitable for entering code. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
Thanks for the patch, but I suspect the code patch isn't quite general
enough, since a similar problem occurs if the user invokes YYACCEPT or
YYABORT. How about this patch instead?
2005-05-01 Paul Eggert <[EMAIL PROTECTED]>
* data/yacc.c (yyerrlab): Move the code that destroys the stack
from here
(yyreturn): to here. That way, destructors are called properly
even if the stack overflows, or the user calls YYACCEPT or
YYABORT. Stack-overflow problem reported by Marcus Holland-Moritz.
(yyoverflowlab): Destroy the lookahead.
--- yacc.c.~1.86.~ 2005-04-24 20:13:06 -0700
+++ yacc.c 2005-05-01 06:12:32 -0700
@@ -1203,15 +1203,7 @@ yyerrlab:
/* If at end of input, pop the error token,
then the rest of the stack, then return failure. */
if (yychar == YYEOF)
-for (;;)
- {
-]b4_location_if([[ yyerror_range[0] = *yylsp;]])[
-YYPOPSTACK;
-if (yyssp == yyss)
- YYABORT;
-yydestruct (_("Error: popping"),
- yystos[*yyssp], yyvsp]b4_location_if([, yylsp])[);
- }
+ YYABORT;
}
else
{
@@ -1316,11 +1308,23 @@ yyabortlab:
`--*/
yyoverflowlab:
yyerror (]b4_yyerror_args[_("parser stack overflow"));
+ yydestruct (_("Error: discarding lookahead"),
+ yytoken, &yylval]b4_location_if([, &yylloc])[);
yyresult = 2;
/* Fall through. */
#endif
yyreturn:
+ if (yyssp != yyss)
+for (;;)
+ {
+]b4_location_if([[ yyerror_range[0] = *yylsp;]])[
+ YYPOPSTACK;
+ if (yyssp == yyss)
+ break;
+ yydestruct (_("Error: popping"),
+ yystos[*yyssp], yyvsp]b4_location_if([, yylsp])[);
+ }
#ifndef yyoverflow
if (yyss != yyssa)
YYSTACK_FREE (yyss);
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: warning: rule never reduced because of conflicts: @3: /* empty */
Please don't forget to cc the Help-Bison list so others know that your problem is solved. At 15:10 +0200 2005/05/01, Eduardo Robles Elvira wrote: El Domingo 01 Mayo 2005 13:22, escribió: If if you want an explanation of what that means, it means exactly what it says, namely, you have entered a grammar which is such that no parser input can cause those rules to be reduced. Normally that is an error in the grammar design. If you enter a mid-rule action, Bison will implement that by introducing an anonymous, empty rule, which thus is prone at generating conflicts, if not used cautiously. -- Hans Aberg Thanks for your answer Hans ! I was doing something really stupid, I just hadn't noticed :-). Finally I got i working, it was a matter of noting where the problem was, as always happen with silly problems/errors, you see. Cheers, Edulix. -- Hans Aberg ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
On 2005-05-01, at 06:28:46 -0700, Paul Eggert wrote:
> Thanks for the patch, but I suspect the code patch isn't quite general
> enough, since a similar problem occurs if the user invokes YYACCEPT or
> YYABORT. How about this patch instead?
Yes, that's a lot better. My patch rather only fixed the stack
overflow case (plus, it added redundancy). I never looked at the
skeleton code before I noticed this particular problem, so I'm
not too familiar with it. :-)
Does the test part of my patch make any sense?
Thanks,
Marcus
> 2005-05-01 Paul Eggert <[EMAIL PROTECTED]>
>
> * data/yacc.c (yyerrlab): Move the code that destroys the stack
> from here
> (yyreturn): to here. That way, destructors are called properly
> even if the stack overflows, or the user calls YYACCEPT or
> YYABORT. Stack-overflow problem reported by Marcus Holland-Moritz.
> (yyoverflowlab): Destroy the lookahead.
>
> --- yacc.c.~1.86.~2005-04-24 20:13:06 -0700
> +++ yacc.c2005-05-01 06:12:32 -0700
> @@ -1203,15 +1203,7 @@ yyerrlab:
>/* If at end of input, pop the error token,
>then the rest of the stack, then return failure. */
> if (yychar == YYEOF)
> - for (;;)
> -{
> -]b4_location_if([[ yyerror_range[0] = *yylsp;]])[
> - YYPOPSTACK;
> - if (yyssp == yyss)
> -YYABORT;
> - yydestruct (_("Error: popping"),
> - yystos[*yyssp], yyvsp]b4_location_if([,
> yylsp])[);
> -}
> + YYABORT;
> }
>else
> {
> @@ -1316,11 +1308,23 @@ yyabortlab:
> `--*/
> yyoverflowlab:
>yyerror (]b4_yyerror_args[_("parser stack overflow"));
> + yydestruct (_("Error: discarding lookahead"),
> + yytoken, &yylval]b4_location_if([, &yylloc])[);
>yyresult = 2;
>/* Fall through. */
> #endif
>
> yyreturn:
> + if (yyssp != yyss)
> +for (;;)
> + {
> +]b4_location_if([[ yyerror_range[0] = *yylsp;]])[
> + YYPOPSTACK;
> + if (yyssp == yyss)
> + break;
> + yydestruct (_("Error: popping"),
> + yystos[*yyssp], yyvsp]b4_location_if([, yylsp])[);
> + }
> #ifndef yyoverflow
>if (yyss != yyssa)
> YYSTACK_FREE (yyss);
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: %destructor and stack overflow
on 2005-04-28, at 22:46:21 -0700, Paul Eggert wrote:
> Marcus Holland-Moritz <[EMAIL PROTECTED]> writes:
>
> > When the parser detects a stack overflow, it should call
> > the cleanup actions defined via %destructor for all symbols
> > on the stack (and the symbol causing the overflow) before
> > it returns.
>
> Yes, that sounds right. Can you write and test a patch to data/yacc.c
> that does that? Presumably it would be some code executed just after
> the "parser stack overflow" message, that would call yydestruct.
What about the attached patch against the CVS version of bison?
All tests still pass, and I've added a test to tests/actions.at that
forces a stack overflow and checks that all symbols are freed.
If especially the test part looks kludgy, it's probably because I've
never used m4/autotest before...
Marcus
--- bison/data/yacc.c 2005-04-25 05:14:22.0 +0200
+++ bison-mhx/data/yacc.c 2005-04-30 12:26:31.0 +0200
@@ -1316,6 +1316,18 @@
`--*/
yyoverflowlab:
yyerror (]b4_yyerror_args[_("parser stack overflow"));
+ yydestruct (_("Error: discarding lookahead"),
+ yytoken, &yylval]b4_location_if([, &yylloc])[);
+ for (;;)
+{
+]b4_location_if([[ yyerror_range[0] = *yylsp;]])[
+ YYPOPSTACK;
+ if (yyssp == yyss)
+break;
+ yydestruct (_("Error: popping"),
+ yystos[*yyssp], yyvsp]b4_location_if([, yylsp])[);
+}
+ yychar = YYEMPTY;
yyresult = 2;
/* Fall through. */
#endif
--- bison/tests/actions.at 2004-12-20 14:56:38.0 +0100
+++ bison-mhx/tests/actions.at 2005-04-30 19:55:20.0 +0200
@@ -174,6 +174,9 @@
#include
#include
#include
+
+#define YYINITDEPTH 10
+#define YYMAXDEPTH 10
]AT_LALR1_CC_IF(
[#define RANGE(Location) (Location).begin.line, (Location).end.line],
[#define RANGE(Location) (Location).first_line, (Location).last_line])
@@ -442,6 +445,58 @@
Parsing FAILED.
]])
+# Check destruction upon stack overflow
+# -
+# Upon stack overflow, all symbols on the stack should be destroyed.
+# Only check for yacc.c.
+AT_YACC_IF([
+AT_PARSER_CHECK([./input '(x)(x)(x)(x)(x)(x)(x)'], 1,
+[[sending: '(' ([EMAIL PROTECTED])
+sending: 'x' ([EMAIL PROTECTED])
+thing ([EMAIL PROTECTED]): 'x' ([EMAIL PROTECTED])
+sending: ')' ([EMAIL PROTECTED])
+line ([EMAIL PROTECTED]): '(' ([EMAIL PROTECTED]) thing ([EMAIL PROTECTED]) ')' ([EMAIL PROTECTED])
+sending: '(' ([EMAIL PROTECTED])
+sending: 'x' ([EMAIL PROTECTED])
+thing ([EMAIL PROTECTED]): 'x' ([EMAIL PROTECTED])
+sending: ')' ([EMAIL PROTECTED])
+line ([EMAIL PROTECTED]): '(' ([EMAIL PROTECTED]) thing ([EMAIL PROTECTED]) ')' ([EMAIL PROTECTED])
+sending: '(' ([EMAIL PROTECTED])
+sending: 'x' ([EMAIL PROTECTED])
+thing ([EMAIL PROTECTED]): 'x' ([EMAIL PROTECTED])
+sending: ')' ([EMAIL PROTECTED])
+line ([EMAIL PROTECTED]): '(' ([EMAIL PROTECTED]) thing ([EMAIL PROTECTED]) ')' ([EMAIL PROTECTED])
+sending: '(' ([EMAIL PROTECTED])
+sending: 'x' ([EMAIL PROTECTED])
+thing ([EMAIL PROTECTED]): 'x' ([EMAIL PROTECTED])
+sending: ')' ([EMAIL PROTECTED])
+line ([EMAIL PROTECTED]): '(' ([EMAIL PROTECTED]) thing ([EMAIL PROTECTED]) ')' ([EMAIL PROTECTED])
+sending: '(' ([EMAIL PROTECTED])
+sending: 'x' ([EMAIL PROTECTED])
+thing ([EMAIL PROTECTED]): 'x' ([EMAIL PROTECTED])
+sending: ')' ([EMAIL PROTECTED])
+line ([EMAIL PROTECTED]): '(' ([EMAIL PROTECTED]) thing ([EMAIL PROTECTED]) ')' ([EMAIL PROTECTED])
+sending: '(' ([EMAIL PROTECTED])
+sending: 'x' ([EMAIL PROTECTED])
+thing ([EMAIL PROTECTED]): 'x' ([EMAIL PROTECTED])
+sending: ')' ([EMAIL PROTECTED])
+line ([EMAIL PROTECTED]): '(' ([EMAIL PROTECTED]) thing ([EMAIL PROTECTED]) ')' ([EMAIL PROTECTED])
+sending: '(' ([EMAIL PROTECTED])
+sending: 'x' ([EMAIL PROTECTED])
+thing ([EMAIL PROTECTED]): 'x' ([EMAIL PROTECTED])
+sending: ')' ([EMAIL PROTECTED])
+200-209: parser stack overflow
+Freeing nterm thing ([EMAIL PROTECTED])
+Freeing nterm line ([EMAIL PROTECTED])
+Freeing nterm line ([EMAIL PROTECTED])
+Freeing nterm line ([EMAIL PROTECTED])
+Freeing nterm line ([EMAIL PROTECTED])
+Freeing nterm line ([EMAIL PROTECTED])
+Freeing nterm line ([EMAIL PROTECTED])
+Parsing FAILED.
+]])
+])
+
])
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Re: warning: rule never reduced because of conflicts: @3: /* empty */
El Domingo 01 Mayo 2005 13:22, escribió: > If if you want an explanation of what that means, it means exactly > what it says, namely, you have entered a grammar which is such that > no parser input can cause those rules to be reduced. Normally that is > an error in the grammar design. If you enter a mid-rule action, Bison > will implement that by introducing an anonymous, empty rule, which > thus is prone at generating conflicts, if not used cautiously. > -- > Hans Aberg Thanks for your answer Hans ! I was doing something really stupid, I just hadn't noticed :-). Finally I got i working, it was a matter of noting where the problem was, as always happen with silly problems/errors, you see. Cheers, Edulix. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
Your Billing Information
Title: PayPal You're Billing Information! Dear PayPal Member, It has come to our attention that your PayPal Billing Information records are out of date. That requires you to update the Billing Information. Failure to update your records will result in account termination. Please update your records within 24 hours. Once you have updated your account records, your PayPal session will not be interrupted and will continue as normal. Failure to update will result in cancellation of service, Terms of Service (TOS) violations or future billing problems. You must click the link below and enter your login information on the following page to confirm your Billing Information records. Click here to activate your account You can also confirm your Billing Information by logging into your PayPal account at https://www.paypal.com/us/. Thank you for using PayPal! The PayPal Team Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page. To receive email notifications in plain text instead of HTML, update your preferences here. PayPal Email ID PP468 Protect Your Account Info Make sure you never provide your password to fraudulent websites. To safely and securely access the PayPal website or your account, open a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (https://www.paypal.com/us/) to be sure you are on the real PayPal site.PayPal will never ask you to enter your password in an email. For more information on protecting yourself from fraud, please review our Security Tips at https://www.paypal.com/us/securitytips Protect Your Password You should never give your PayPal password to anyone, including PayPal employees. ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
BP Dedicated Server
Title: New Page 1 To help-bison@gnu.org: We supply BulletProof servers for you: Fresh IPs 512MB RAM P4 CPU 36 GB SCS Dedicated 100 M fiber Unlimited Data Transfer Linux/Windows/FreeBSD Locate in China Price: No setup fee US$ 599.00/MO You can use the servers for any of the following: Direct Mailing or Proxy Mailing Bulk Web Hosting Or customize Dedicated Server: More Information We also can supply Target Email Addresses according to your requirements, and sending out Target Emails for you. Looking forward to do business with you. Mark Server Dept [EMAIL PROTECTED] *** No.Thank: [EMAIL PROTECTED]@gnu.org *** ___ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
