This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pass_stdarg problem when run after pass_lim


On 02-02-15 16:47, Michael Matz wrote:
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.


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
  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
- 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.

Thanks,
- Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]