Re: gimplify_parameters

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    So I see that Temp_File_Record is apparently a non-local varible sized
    structure.  I see that the Ada front end has done *some* stuff to try
    to make this work, like promoting portions of the computation into
    global variables.  E.g.
    system__file_io__temp_file_record__next___OFFSET.

Right.

    Not having managed to get a breakpoint set at the right place to watch
    things happen, I'm _presuming_ that there is still a SAVE_EXPR or
    three buried inside Temp_File_Record somewhere.  

No, there can't be because a SAVE_EXPR conceptually belongs to one
function and this is shared among all.

    I can't see any other way for D.935 to leak between the two functions.

The point is that Temp_File_Record is used as the type of a parameter in
*two* functions, so gimplify_parameters is being called with that type
*twice*.  The first time, nothing has gone wrong but it's updated DECL_OFFSET
to be a new variable in the context of that first function.

It's the *second* function where things get messed up because now DECL_OFFSET
contains a VAR_DECL from that first function but it gets gimplified again and
we make a new VAR_DECL whose initial value is derived from that first
VAR_DECL, in some brother function, which is wrong and is the cause of the ICE.

    Now, given that there is a SAVE_EXPR, and that SAVE_EXPR mechanisms

It has absolutely nothing to do with SAVE_EXPRs: there are none involved.


The handling of global variable-sized types took me *quite* a while to get
right and was probably the largest task in Gigi for the tree-ssa conversion
of Ada.  I tried numerous iterations.

What I ended up with was fairly straightforward: I left in the existing
mechanisms to have all the sizes and positions be expression that only
involve constants and readonly globals, so there's no multiple evaluation
issue within the type or decl itself.  There's no reason whatsoever to
gimplify a size or position of a global type (or decl): it can remain an
arbitrary GENERIC expression so long as it's readonly and has no
side-effects.  Instead, whenever such a size or position is used, a copy is
made and *that copy* is gimplified in the context of the function that uses it.