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.
