This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: pass_stdarg problem when run after pass_lim
- From: Michael Matz <matz at suse dot de>
- To: Tom de Vries <Tom_deVries at mentor dot com>
- 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: Mon, 2 Feb 2015 16:47:05 +0100 (CET)
- 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>
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.
Ciao,
Michael.