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
