pass_stdarg problem when run after pass_lim

[Tom de Vries]

On 02-02-15 16:47, Michael Matz wrote:
> Hi,
>
> On Mon, 2 Feb 2015, Tom de Vries wrote:
>
>> I've minimized the vaarg-4a.c failure, and added it as testcase to the patch
>> series as gcc.target/x86_64/abi/callabi/vaarg-4.c.
>>
>> The problem is in this code:
>> ...
>>    e = va_arg (argp, char *);
>>    e = va_arg (argp, char *);
>> ...
>>
>> which is translated into:
>> ...
>>    <bb 2>:
>>    argp.1 = argp_3(D);
>>
>>    <bb 5>:
>>    argp.12_11 = &argp.1;
>>    _12 = *argp.12_11;
>>    _13 = _12 + 8;
>>    *argp.12_11 = _13;
>>
>>    <bb 6>:
>>    argp.3 = argp_3(D);
>>
>>    <bb 7>:
>>    argp.13_15 = &argp.3;
>>    _16 = *argp.13_15;
>>    _17 = _16 + 8;
>>    *argp.13_15 = _17;
>>    _19 = MEM[(char * *)_16];
>>    e_8 = _19;
>> ...
>
> That looks like non-x86-64 ABI code.  It builds with -mabi=ms, and it
> seems the particular path taken therein doesn't write back to the aplist
> if it's not locally created with va_start, but rather given as argument.
> Or rather, if it is not addressible (like with x86-64 ABI, where it's
> either addressible because of va_start, or is a pointer to struct due to
> array decay).  The std_gimplify_va_arg_expr might need more changes.
>

I've managed to fix that, using these lines in std_gimplify_va_arg_expr:
...
       if (TREE_CODE (tmp) == ADDR_EXPR
           && TREE_OPERAND (tmp, 0) != valist)
         {
           /* If we're passing the address of a temp, instead of the addres of
              valist, we need to copy back the value of the temp to valist.  */
           assign = gimple_build_assign (valist, TREE_OPERAND (tmp, 0));
           gimple_seq_add_stmt (pre_p, assign);
         }
...
[ I've pushed the current state (now based on a current commit) to 
vries/expand-va-arg-at-pass-stdarg again. ]

Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so I've 
disabled that by default for now.

I've done a non-bootstrap and bootstrap build using all languages.

The non-bootstrap test shows (at least) two classes of real failures:
- gcc.c-torture/execute/20020412-1.c, gcc.target/i386/memcpy-strategy-4.c and
   gcc.dg/lto/20090706-1_0.c.
   These are test-cases with vla as va_arg argument. It ICEs in
   force_constant_size with call stack
   gimplify_va_arg_expr -> create_tmp_var -> gimple_add_tmp_var ->
   force_constant_size
- most/all va_arg tests with flto, f.i. gcc.c-torture/execute/stdarg-1.c.
   It segfaults in lto1 during pass_stdarg, in gimplify_va_arg_internal when
   accessing have_va_type which is NULL_TREE after
   'have_va_type = targetm.canonical_va_list_type (have_va_type)'.

I don't think the flto issue is difficult to fix.  But the vla issue probably 
needs more time than I have available right now.

Thanks,
- Tom