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

[Alessandro Basili]

This message has been previously posted on gnu.gcc.help with no answer
in three days.

Hi,

I'm not sure if this is the right place to talk about this issue, I'm
open to re-post this article on a more appropriate group upon suggestions.

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]

[Hans Aberg]

On 2011/10/31 14:15, Alessandro Basili wrote:
> ... 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.

Usually, it means that one has to get hold of the authors of the
package, to find out what they had in mind:

One can deliberately leave shift/reduce conflicts, in which case Bison
will issue a warning, which can be suppressed %expect (see section 3.7.8
"Suppressing Conflict Warnings" in the Bison manual).

However, there is no way to be sure of that. Especially when it say
expected 8, and you got 10. But the compile and parser will run.

Hans
[I made the obvious patches and also got 10 rather than 8. I agree,
give this decade-old code a try and see if it works. -John]

[Alessandro Basili]

On 10/31/2011 8:49 PM, Hans Aberg wrote:
> On 2011/10/31 14:15, Alessandro Basili wrote:
>> ... 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.
>
> Usually, it means that one has to get hold of the authors of the
> package, to find out what they had in mind:

unfortunately the author does not reply and I believe the current
maintainer is also not working on it.

> One can deliberately leave shift/reduce conflicts, in which case Bison
> will issue a warning, which can be suppressed %expect (see section 3.7.8
> "Suppressing Conflict Warnings" in the Bison manual).

thanks for pointing out.

> However, there is no way to be sure of that. Especially when it say
> expected 8, and you got 10. But the compile and parser will run.
>
> Hans
> [I made the obvious patches and also got 10 rather than 8. I agree,
> give this decade-old code a try and see if it works. -John]

what do you mean by obvious patches? I managed to compile and still have
a bunch of warning that I'm trying to get rid of. Here's what I'm left
with so far:

> c-common.c: In function decl_attributes':
> c-common.c:237: warning: assignment from incompatible pointer type
> expr.c: In function emit_block_move':
> expr.c:1587: warning: passing argument 1 of emit_library_call' makes pointer from integer without a cast
> expr.h:536: note: expected rtx' but argument is of type int'
> expr.c: In function clear_storage':
> expr.c:1734: warning: passing argument 1 of emit_library_call' makes pointer from integer without a cast
> expr.h:536: note: expected rtx' but argument is of type int'
> expr.c: In function emit_push_insn':
> expr.c:2233: warning: passing argument 1 of emit_library_call' makes pointer from integer without a cast
> expr.h:536: note: expected rtx' but argument is of type int'
> expr.c: In function expand_assignment':
> expr.c:3054: warning: passing argument 1 of emit_library_call' makes pointer from integer without a cast
> expr.c:2375: note: expected rtx' but argument is of type int'
> expr.c: In function store_expr':
> expr.c:3279: warning: passing argument 1 of emit_library_call' makes pointer from integer without a cast
> expr.c:2375: note: expected rtx' but argument is of type int'
> expr.c: In function expand_expr_1':
> expr.c:5013: warning: left shift count >= width of type
> expr.c:5017: warning: left shift count >= width of type
> cexp.y: In function parse_escape':
> cexp.y:797: warning: left shift count >= width of type
> cexp.y:799: warning: left shift count >= width of type
> cexp.y:827: warning: left shift count >= width of type
> cexp.y:829: warning: left shift count >= width of type

Giving it a try is a bit difficult, since I'm not sure how to check a
compiler! Assuming I manage to compile my application for the ADSP21010,
it would also be difficult to check that what I got is what I expect on
a systematic basis.

Any hint for verifying the compiler (and linker/assembler which I still
need to build!) would be of a great help.
[See the next message. -John]

[George Neuner]

On Mon, 31 Oct 2011 14:15:31 +0100, Alessandro Basili
<alessand...@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

[George Neuner]

On Wed, 02 Nov 2011 12:33:46 -0400, George Neuner
<gneu...@comcast.net> wrote:

Someone commented offline that my rewrite might not work *if* the
mid-rule start_struct call was needed for recursive structure
definitions. I had looked at the code for start_struct before posting
and it looks like it should handle that situation, but it's difficult
to be sure without building the whole compiler.

John had commented that he tried the obvious fix and got more errors,
so I had looked to eliminate the mid-rule clause. But, it turns out
that with bison 2.4.1, either of the versions below will eliminate the
errors.

STRUCT identifier '{'
{ $<ttype>$ = start_struct (RECORD_TYPE, $2); }

component_decl_list '}'
{ $$ = finish_struct ($<ttype>4, $5); }

or
STRUCT identifier '{'
{ $<ttype>3 = start_struct (RECORD_TYPE, $2); }
component_decl_list '}'
{ $$ = finish_struct ($<ttype>3, $5); }

The second version passes the state through the token for the opening
brace in case mid-rule results are somehow broken.

Remember, though, that just because bison is happy does not mean the
generated C code will work.

Hope this ... doesn't confuse the issue more.
George

[Alessandro Basili]

On 11/4/2011 5:56 PM, George Neuner wrote:
> On Wed, 02 Nov 2011 12:33:46 -0400, George Neuner
> <gneu...@comcast.net> wrote:
>
> Someone commented offline that my rewrite might not work *if* the
> mid-rule start_struct call was needed for recursive structure
> definitions. I had looked at the code for start_struct before posting
> and it looks like it should handle that situation, but it's difficult
> to be sure without building the whole compiler.

I'm trying to get the fixes done in order to build the compiler under
gcc-4.4.1. And indeed I got rid of all the errors and warnings except
for two types:

warning: left shift count >= width of type

warning: assignment from incompatible pointer type

and should get rid of those very soon.

>
[...]

>
> The second version passes the state through the token for the opening
> brace in case mid-rule results are somehow broken.

I realize I'm not able to follow, maybe I need to study some
fundamentals before go ahead and make changes to something I have no
idea what it is about.

>
> Remember, though, that just because bison is happy does not mean the
> generated C code will work.

That's another key point it worries me a lot. My goal is not to fix the
compiler, but start using it to build my program for the aforementioned
architecture. I would assume the shift/reduce conflicts is resulting
from an incorrect description of the language, but if I can be able to
understand what kind of construct of the language will trigger the
conflict I can probably avoid to use it in my program.

To be honest I never doubted the correctness of the compiler I was using
(how naive??) and now that I'm trying to build one I realize the
complexity behind and how shaky are the pillars on which my applications
are built upon.

>
> Hope this ... doesn't confuse the issue more.

I will give it a try, restoring the %expected to 8, but even if that
works I'm not sure I should stop understanding what are the shift/reduce
conflicts and how should I avoid those conflicts when I program.

[glen herrmannsfeldt]

Alessandro Basili <alessand...@cern.ch> wrote:
(snip)

> That's another key point it worries me a lot. My goal is not to fix the
> compiler, but start using it to build my program for the aforementioned
> architecture. I would assume the shift/reduce conflicts is resulting
> from an incorrect description of the language, but if I can be able to
> understand what kind of construct of the language will trigger the
> conflict I can probably avoid to use it in my program.

Shift/reduce conflicts are not unusual, and not necessarily bad.

They often come from ambiguities in the language being parsed,
nested if-then-else being a favorite example. In many languages
with if-then-else, the else is defined to go with the nearest if,
but the syntax description doesn't know that. Specifying that
resolves the shift/reduce conflict.

Still, it might be worth trying to understand where the
conflicts come from to be sure that it is part of the
language definition.

As I understand it, though, reduce/reduce conflicts are not so
usual, and should be considered errors.

-- glen

[George Neuner]

On Sun, 06 Nov 2011 19:24:32 +0100, Alessandro Basili
<alessand...@cern.ch> wrote:

>On 11/4/2011 5:56 PM, George Neuner wrote:
>
>> Remember, though, that just because bison is happy does not mean the
>> generated C code will work.
>
>That's another key point it worries me a lot. My goal is not to fix the
>compiler, but start using it to build my program for the aforementioned
>architecture.

I've worked with the SHARC 2106x, but not with g21k ... I used the
newer VisualDSP compiler, which is not based on GCC but is instead an
AKC derivative. VisualDSP is not free, however.

>I would assume the shift/reduce conflicts is resulting from an
>incorrect description of the language, but if I can be able to
>understand what kind of construct of the language will trigger the
>conflict I can probably avoid to use it in my program.

Not necessarily. Shift/reduce conflicts happen when there is a
potential for immediate reduction and also the potential to recognize
a longer expression. The classic example is the "dangling ELSE"
construct.

In C: if ( expr )
if ( expr )
:
else
:

Should this be parsed as (IF (IF ELSE)) or (IF (IF) ELSE)?

Without scoping braces the parser can't tell. Indentation may make it
clear to the programmer, but the C language doesn't recognize
indentation as being significant. And what if the code were all on
one line?

You get a different answer depending on whether the parser reduces the
inner IF immediately - attaching the ELSE to the outer IF, or shifts
the ELSE, attaching it to the inner IF.

In such cases - and unless told otherwise - Bison defaults to shifting
to try to match the longest sequence and issues a warning about the
ambiguity.

So a shift/reduce conflict is not necessarily an error. But, at the
same time, it is something more than a warning because it identifies
ambiguous syntax that potentially may be confusing for the *user* of
the language.

>To be honest I never doubted the correctness of the compiler I was using
>(how naive??) and now that I'm trying to build one I realize the
>complexity behind and how shaky are the pillars on which my applications
>are built upon.

The parsers created by Bison actually have well developed theory
behind them. But that doesn't mean that the grammar correctly
reflects the semantics of the language as intended by the developer.
In other words, grammars can have bugs. Developer tools also can have
bugs and Bison is no exception. At this point, Bison is pretty well
shaken out and what bugs it has tend to be esoteric ... but they still
can bite the unwary developer who attempts something clever.

>> Hope this ... doesn't confuse the issue more.
>
>I will give it a try, restoring the %expected to 8, but even if that
>works I'm not sure I should stop understanding what are the shift/reduce
>conflicts and how should I avoid those conflicts when I program.

George