https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #37 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #36)
>
> I considered pointers to arrays:
>
> struct P {
> int n;
> char (*buf)[.n];
> };
>
Okay.
Then for the field "buf", it has a pointer type, the size of this field is a
compile-time constant. where in the IR do you put the ".n" (the size of the
array this pointer points to). That's the place I am trying to understand from
your patch or from the IR dump of a working small testing case.
> the FAM case needs more work and I guess there are
> still many other problems with the patch.
>
For the FAM case, since the field itself is an ARRAY type, then the ".n" can be
naturally put to the SIZE of the type of the field.
Another thing I'd like to point out, for the original intention of this PR, FAM
case is more important than the pointer to array case, I think. So, should we
focus on FAM first?
>
> The comments in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
>
> imply that the size information does not survive long enough
need to study this a little bit more.
> But the size expression is evaluated each time when the member is
> accessed.
How to represent this in IR?
> Maybe the size expressions should be limited to very simple
expressions without side effects.
agreed. but I think we might want to focus on FAM first.
