Hi, On Tue, 3 Feb 2015, Tom de Vries wrote:
> 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 Hah, yeah, that's the issue I remembered with create_tmp_var. This needs a change in how to represent the va_arg "call", because the LHS can't be a temporary that's copied to the real LHS afterwards. > - 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. I'll think about this. Ciao, Michael.
