This is the mail archive of the
mailing list for the GCC project.
Re: pass_stdarg problem when run after pass_lim
- From: Tom de Vries <Tom_deVries at mentor dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 3 Feb 2015 10:40:42 +0100
- Subject: Re: pass_stdarg problem when run after pass_lim
- Authentication-results: sourceware.org; auth=none
- References: <54CA6BB1 dot 10502 at mentor dot com> <20150129172535 dot GN1746 at tucnak dot redhat dot com> <54CAB232 dot 1090005 at mentor dot com> <CAFiYyc1XB_6-P32CroiFbE2Of3j3vORu5d7ALuEgoN8F9yk0Tg at mail dot gmail dot com> <54CB61C8 dot 4060801 at mentor dot com> <alpine dot LNX dot 2 dot 00 dot 1501301322400 dot 18611 at wotan dot suse dot de> <54CF8AB8 dot 5040405 at mentor dot com> <alpine dot LNX dot 2 dot 00 dot 1502021628300 dot 18611 at wotan dot suse dot de>
On 02-02-15 16:47, Michael Matz wrote:
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:
argp.1 = argp_3(D);
argp.12_11 = &argp.1;
_12 = *argp.12_11;
_13 = _12 + 8;
*argp.12_11 = _13;
argp.3 = argp_3(D);
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
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 ->
- 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.