Re: [lto][patch] remove local variables from types (after gimplification)

["Bill Maddox" <maddox@google.com>]

On Tue, Jun 24, 2008 at 1:26 PM, Rafael Espindola <espindola@google.com> wrote:
> 2008-06-24  Rafael Espindola  <espindola@google.com>
>
>        * calls.c (must_pass_in_stack_var_size_or_pad): Don't check if
>        TYPE_SIZE is NULL.
>        * expr.c (store_field): Don't check if TYPE_SIZE is NULL.
>        * tree.c (reset_type_lang_specific): Set both TYPE_SIZE_UNIT
>        and TYPE_SIZE or none of them. Don't set TYPE_MAX_VALUE to
>        NULL. call set_min_and_max_values_for_integral_type.

I updated to top of lto branch, and noticed the following test was
first to fail:

   FAIL: gcc.c-torture/compile/20020210-1.c  -O2 -flto  (internal
compiler error)

In this case, the failure is due to an attempt to stream out a SAVE_EXPR node.
I have a development sandbox that includes the patch, but is apparently choosing
a different order in which to stream out the nodes, and which exhibits a much
more interesting failure, encountering a local variable in a type.
The program is
trivial:

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

The problem is that the size of the *structure* type is variable, due
to the embedded
VLA.  While this program is not valid C99, it is apparently permitted
as a GNU extension,
and similar constructs arise in other languages, e.g. Ada.  Clearly we
are not catching
all of the occurrences of variables within types.  This may just be an
oversight, but I'd
like to know if it is generally the case that the middle-end/back-end
does not not need
this information, or whether the justification for erasing the size of
array types is specific
to the case of arrays.

--Bill