On Mon, Sep 2, 2013 at 3:02 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>> >
>> > Well, there is still fallout from this change so I'm not convinced
>> > this will stay
>> > this way. Also we stream the function-decl that refers to these fields in
>>
>> As far as I know there are two problems
>> 1) problem with the thunk expansion not getting DECL_ARGUMENTS/DECL_RESULT
>> addressed by this patch
>> 2) ICE in gcc.dg/torture/pr8081.c
>> Here the problem is in variable type of return value that gets streamed
>> twice and we end up with duplicate.
>>
>> As mentioned earlier, I want to handle this by introducing
>> variable_sized_function_type_p that will make those go specially the
>> old way (with DECL_ARGUMENTS/DECL_RESULT in the global stream).
>>
>> I did not send the patch, because I think the variable sized parameters
>> were handled incorrectly before my changes, too, and the fix is not
>> so trivial. It just makes us
>> not ICE the same way as before. The testcase is:
>> /* { dg-do run } */
>>
>> extern void abort (void);
>> int
>> main (int argc, char **argv)
>> {
>> int size = 10;
>> typedef struct
>> {
>> char val[size];
>> }
>> block;
>> block a, b;
>> block __attribute__((noinline))
>> retframe_block ()
>> {
>> return *(block *) &b;
>> }
>> b.val[0] = 1;
>> b.val[9] = 2;
>> a=retframe_block ();
>> if (a.val[0] != 1
>> || a.val[9] != 2)
>> abort ();
>> return 0;
>> }
>> So here the size is not parameter of the function, it is a local vairable
>> (later turned into structure) that gets into local function stream.
>
> ^^^ reading my email, perhaps in this case the correct fix is to make
> tree-nested to fix-up the TYPE_SIZE? It knows how to access the
> frame variables from outer function via the invisible link pointer
> passed and it knows how to update gimple. That may also fix the issue
> with debug info.
But we still refer to the local entity from TREE_TYPE of the function decl,
no?
As for debug info we probably have to insert proper DEBUG_STMTs that
tell us how to construct those. Don't we do this kind of dance already?
All the gimplfied type-sizes in TYPE_SIZE are basically 'useless', they
exist only for the gimplfiers sake and as 'marker' that the type has
variable size.
All references to the size are explicit in the code (and I believe
debug info has
to be emitted before gimplifying or doesn't properly handle such variadic types
at all). That's some huge cleanup opportunity (I suppose NULLifying TYPE_SIZE
doesn't work).
Richard.
