gimplify_parameters

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

This is the cause of the build failure (s-fileio.adb).

We can't just call gimplify_type_sizes in that context because it can make
variables in the current function that should be in the parent function (or
be nowhere, if the type is global, though the latter can occur only in Ada).

The way this was intended to work is that every type that is variably
modified would be in a DECL_EXPR; that was supposed to be the only place that
calls gimplify_type_sizes.

Now, in the case in the PR, the type is being defined as part of the
parameter list and is indeed supposed to be in the inner function and there
indeed doesn't seem to be any convenient place to put the DECL_EXPR.

The following C test case shows what's going wrong here and causes an ICE.
This is similar to the Ada case in question.

void f (int a)
{
  typedef struct {int b[a];} c;
  c cs;

  void g (c c) {};

  g (cs);
}

One approach would be to set a flag when gimplify_type_sizes has been called
on a type, but that would be wasteful of a flag and probably also cause
problems with global types in Ada (though the latter is easily fixable if it
occurs).

Fundmanentally, I see this as a front-end issue because the semantics of the
case in PR16417 is determined only by the C front-end.  So it needs to find
*some* way to represent what's going on.  One approach might be to extend the
type system to allow a TYPE_DECL inside the list of args and then
gimplify_parameters would only do the gimplify_type_sizes on things that had
a TYPE_DECL.  But that might be major surgery.  However, it seems clear
that the order of evaluation has to be "a", "type of c", "c".

So I don't have any good solution at the moment, but will keep trying to
come up with one.