Re: [Tinycc-devel] [BUG] Nested array/struct/union initialization problem

[Marc Andre Tanner]

Dave Dodge wrote:
> On Wed, Sep 26, 2007 at 02:46:45AM -0500, Rob Landley wrote:
> > Anyway, the first thing I'd do is try to pare the test case down to
> > something smaller.
>
> struct foo{
>     union{
>         int i;
>     };
> };
>
> static struct foo f = {
>     { .i = 0 }
> };
>
> > I'm currently looking at unary() for one of the other issues
>
> I took a brief look at it earlier.  I traced it this far (line numbers
> in tcc.c are a bit off due to the inserted trace code):

Hi,

Have you made any progress on the issue?

>   decl_initializer called from decl_initializer_alloc:8136
>   decl_initializer called from decl_designator:7598
>   decl_initializer called from decl_initializer:7911
>   expr_const1 called from init_putv:7641
>   expr_eq called from expr_const1:7129
>   uneq() called from expr_prod:6802
>   unary called from uneq:6779
>   unary:6368 tok=46
>   unary:6612 t=46
>   foo.c:8: unary: 6615: identifier expected
>
> Basically I think it's entering the big switch in unary() with the '.'
> as the token, which drops to the default case.  Give the union a field
> name in the struct, _or_ remove the ".i=" from the initializer, and it
> takes it with this trace:

As can be seen from your trace bellow (or with gdb: break unary; run; 
bt;) it calls 2 times decl_designator instead of decl_designator 
followed by decl_initializer.

If i set a breakpoint at line 7573 where decl_initializer is called and 
then examine the data i get the following for the bug case:

 (gdb) p *type
 $1 = {t = 256, ref = 0x4001f9b0}

 (gdb) p **cur_field
 $2 = {v = 536871987, r = 0, c = 0, type = {t = 0, ref = 0x4001f9b0},
  next = 0x0, prev = 0x80824f0, prev_tok = 0x0}

If the union is named the data is as follows:

 (gdb) p *type
 $1 = {t = 263, ref = 0x8082510}

 (gdb) p **cur_field
 $2 = {v = 536871988, r = 0, c = 0, type = {t = 7, ref = 0x8082510},
  next = 0x0, prev = 0x80824f0, prev_tok = 0x0}

Note that type->t and (**cur_field)->type->t both differ by VT_STRUCT 
which is defined as 7. So i think there is a bug in the parsing code 
which leds it to think that it isn't a struct/union.

Because of this the if on line 7821 doesn't evaluate to true

        } else if ((type->t & VT_BTYPE) == VT_STRUCT &&
                        (sec || !first || tok == '{')) {

instead the else if branch on line 7887 matches

        } else if (tok == '{') {

and the error continues...

>   decl_initializer called from decl_initializer_alloc:8136
>   decl_initializer called from decl_designator:7598
>   decl_initializer called from decl_designator:7598
>   expr_const1 called from init_putv:7641
>   expr_eq called from expr_const1:7129
>   uneq() called from expr_prod:6802
>   unary called from uneq:6779
>   unary:6368 tok=179
>
> Note that this time the token is 179, even when you merely name the
> union and leave the ".i=" in place.
>
>                                                   -Dave Dodge

Would be nice if someone could help me fix this thing.

Thanks,
Marc

--
 Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0