pass_stdarg problem when run after pass_lim

[Michael Matz]

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.