Question on variable_size and function-at-a-time
Geoff Keating
geoffk@geoffk.org
Tue Apr 13 00:05:00 GMT 2004
Richard Henderson <rth@redhat.com> writes:
> On Sun, Apr 11, 2004 at 08:03:48AM -0400, Richard Kenner wrote:
> > It looks to me that the SAVE_EXPR for the size of C is computed inside the
> > "if (j == 2)" context so that if J is not 2, it will return undefined junk.
>
> Yep. Or worse, if the sizeof is only evaluated within a nested
> function. We will currently ICE on tree-ssa branch for that case.
>
> > How is this supposed to work?
>
> I have no idea. I don't even know what it *means*.
Ugh. I think I do know what it means after reading the C99 standard,
but I didn't realise this was part of C.
> In particular, at what point is the size of the type fixed? At the
> location of the typedef? At the first use? At the beginning of the
> function?
At the location of the typedef, each time that typedef is reached.
>From C99 6.7.7 paragraph 3:
Any array size expressions associated with variable length array
declarators are evaluated each time the declaration of the typedef
name is reached in the order of execution.
I believe it's wrong that we use SAVE_EXPR for array sizes for C. We
should instead create temporary variables to hold the size
declarations, and set them in the appropriate point in the instruction
stream.
> I think the first alternative makes the most sense, but frankly, I
> think there are lots of dumb corner cases that make no sense at all.
> I wouldn't be terribly unhappy if all this stupid dynamicly sized
> type stuff was dropped as a C extension. C99 style VLAs handle what
> people actually need; dynamicly sized structures are just too poorly
> specified to be useful.
>
> As for Ada, you'll just have to insert something somewhere appropriate
> that gets the SAVE_EXPR evaluated. Or, gasp, insert a temp variable
> yourself rather than rely on broken SAVE_EXPR semantics.
Yes. If timing of evaluation matters, use a temp variable.
--
- Geoffrey Keating <geoffk@geoffk.org>
More information about the Gcc
mailing list