Hi Martin, On Thu, Aug 08, 2024 at 09:39:59AM GMT, Martin Uecker wrote: > > $ /opt/local/gnu/gcc/lengthof/bin/gcc zero.c > > zero.c:18:12: error: variably modified ‘Z’ at file scope > > 18 | static int Z[__lengthof__(Y)]; > > | ^ > > > > > > See that D, which is identical to Z, does not cause an error. > > There's one case of [0] resulting in a constant expression, and another > > in a VLA. Can you please help investigate why it's happening? > > This seems to be another bug where we incorrectly set > C_TYPE_VARIABLE_SIZE and this also affects sizeof: > > https://godbolt.org/z/a8Ej6c5jr > > Strangely it seems related to the function declaration > with the unspecified size before. I will look into this, > I am just working on some checking functions that make sure > that those bits are consistent all the time because I also > missed some cases where I need to set C_TYPE_VARIABLY_MODIFIED > > I filed a new bug: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116284
Huh, that's obscure! Thanks! :-)
>
> ...
>
> > | ^
> >
> > If I make [0] always result in a constant expression (and thus break
> > some [*] cases), by doing
> >
> > - var = var || (zero && C_TYPE_VARIABLE_SIZE (type));
> >
> > Then the problem disappears. But I'm worried that it might be hiding
> > the problem instead of removing it, since I don't really understand why
> > it's happening. Do you know why?
> >
> > Anyway, I'll remove that line to support [0]. But it would be
> > interesting to learn why this problem triggers.
>
> You need the line to support variable size arrays.
Not really. 'zero' is only true for [0] and for [*], but nor for
[zero], right?
All vla tests seem to pass if I remove that line. The only issue will
be that
void f(char (*a)[*], int (*x)[__lengthof__(*a)]);
will result in 'int (*x)[0]' until you change the implementation of [*],
but I think we can live with that small detail.
> Please just uncomment
> your test with a reference to the bug for now and I will try fix this ASAP.
I'll send v6 in a moment; feel free to insist in this if you disagree
after seeing it, but I think it works well without the line.
>
> Martin
Cheers,
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
