Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!lnews.iecc.com!nerds-end
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Subject: Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' has no declared type
Date: Wed, 02 Nov 2011 12:33:46 -0400
Organization: A noiseless patient Spider
Lines: 104
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <11-11-013@comp.compilers>
References: <11-10-020@comp.compilers>
NNTP-Posting-Host: lnews.iecc.com
X-Trace: gal.iecc.com 1320288191 6065 64.57.183.34 (3 Nov 2011 02:43:11 GMT)
X-Complaints-To: abuse@iecc.com
NNTP-Posting-Date: Thu, 3 Nov 2011 02:43:11 +0000 (UTC)
Keywords: bison, parse
Posted-Date: 02 Nov 2011 22:43:11 EDT
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: x330-a1.tempe.blueboxinc.net comp.compilers:315

On Mon, 31 Oct 2011 14:15:31 +0100, Alessandro Basili
<alessandro.basili@cern.ch> wrote:

>I'm trying to get g21k (rev. 3.3.4) (Analog Devices's gcc port for SHARC
>architecture) to compile with my gcc (rev. 4.4.1).
>I'm having several problems with the package
>(http://code.google.com/p/g21k/) but trying to make it happen.
>
>Unfortunately now I'm stuck with a problem related to bison:
>
>> cd .; bison -v -d c-parse.y -o c-parse.c
>> c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' has no declared type
>> c-parse.y:1128.19-20: $$ for the midrule at $4 of `structsp' has no declared type
>> c-parse.y:1138.19-20: $$ for the midrule at $4 of `structsp' has no declared type
>> c-parse.y:1144.19-20: $$ for the midrule at $3 of `structsp' has no declared type
>
>To be honest is the first time I learned about bison and after some
>searching I found that $$ is not allowed anymore for a midrule, that is
>why I tried to change it into $<ttype>$ in the (what I believed)
>appropriate places, but then I got the following message:
>
>> cd .; bison -v -d c-parse.y -o c-parse.c
>> c-parse.y: conflicts: 10 shift/reduce
>> c-parse.y: expected 8 shift/reduce conflicts
>
>I believe I'm in the dark here.
>[How about showing us a snippet of the code that you changed? -John]

After our esteemed moderator pointed out something I overlooked the
first time (thanks John!), I think the following might work.

structsp:
	  STRUCT identifier '{'
		{ $$ = start_struct (RECORD_TYPE, $2);
		  /* Start scope of tag before parsing components.  */
		}
	  component_decl_list '}'
		{ $$ = finish_struct ($<ttype>4, $5);
		  /* Really define the structure.  */
		}
	| STRUCT '{' component_decl_list '}'
		{ $$ = finish_struct (start_struct (RECORD_TYPE, NULL_TREE),
				      $3); }
    :
	| UNION identifier '{'
		{ $$ = start_struct (UNION_TYPE, $2); }
	  component_decl_list '}'
		{ $$ = finish_struct ($<ttype>4, $5); }
	| UNION '{' component_decl_list '}'
		{ $$ = finish_struct (start_struct (UNION_TYPE, NULL_TREE),
				      $3); }
    :
	| ENUM identifier '{'
		{ $<itype>3 = suspend_momentary ();
		  $$ = start_enum ($2); }
	  enumlist maybecomma_warn '}'
		{ $$ = finish_enum ($<ttype>4, nreverse ($5));
		  resume_momentary ($<itype>3); }
	| ENUM '{'
		{ $<itype>2 = suspend_momentary ();
		  $$ = start_enum (NULL_TREE); }
	  enumlist maybecomma_warn '}'
		{ $$ = finish_enum ($<ttype>3, nreverse ($4));
		  resume_momentary ($<itype>2); }
    :


Notice that the second STRUCT and UNION alternations above have the
same form as the first but do not use a mid-rule clause.  This
suggests that there really is no need to execute start_struct() before
parsing component_decl_list.

I think that, for these, you can safely remove the mid-rules by
rewriting the alternations as

	  STRUCT identifier '{' component_decl_list '}'
		{ $$ = finish_struct (start_struct (RECORD_TYPE, $2), $4); }
and
	  UNION identifier '{' component_decl_list '}'
		{ $$ = finish_struct (start_struct (UNION_TYPE, $2), $4); }


The ENUM alternations I think can be fixed similarly, but the mid-rule
clause can't be removed entirely because it seems the calls to
(suspend|resume)_momentary() are required.  However, looking closely,
state is passed from suspend to resume through the token for the
opening brace rather than through the clause result.  So I think these
can be rewritten to

	  ENUM identifier '{'
		{ $<itype>3 = suspend_momentary (); }
	  enumlist maybecomma_warn '}'
		{ $$ = finish_enum (start_enum ($2), nreverse ($5));
		  resume_momentary ($<itype>3); }
and
	  ENUM '{'
		{ $<itype>2 = suspend_momentary (); }
	  enumlist maybecomma_warn '}'
		{ $$ = finish_enum (start_enum (NULL_TREE), nreverse ($4));
		  resume_momentary ($<itype>2); }


Hope this helps.
George