Re: bison c-parse.y:1115.19-20: $$ for the midrule at $4 of `structsp' has no declared type

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

Return to the comp.compilers page.
Search the comp.compilers archives again.