[Bug ipa/65540] [5 Regression] internal error on s-fatllf.ads at -O2

hubicka at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Apr 1 02:58:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK,
hand written wrapper is produced as follows:
f3 (long double x)
{
  long double _3;

  <bb 2>:
  _3 = func2 (x_2(D)); [return slot optimization]
  <retval> = _3;
  return <retval>;

}

and create_wrapper produces:

func1 (long double x)
{
  long double retval.3;

  <bb 2>:
  retval.3_2 = func2 (x_1(D)); [return slot optimization] [tail call]
  return retval.3_2;

}

I suppose it is the tail call that fails here, but I think it is just missed
optimization we do not produce it in the first case because the parameter also
needs copying:
f3:
        subq    $72, %rsp
        .seh_stackalloc 72
        .seh_endprologue
        fldt    (%rdx)
        movq    %rcx, %r8
        leaq    32(%rsp), %rdx
        leaq    48(%rsp), %rcx
        fstpt   32(%rsp)
        call    func2
        movq    %r8, %rax
        fldt    48(%rsp)
        fstpt   (%r8)
        addq    $72, %rsp
        ret

compiling it as jmp func2 would definitly be an improvmeent!

We die expanding address of the first parameter:
#2  0x00000000104f6d5c in expand_expr_addr_expr_1 (exp=0x3fffaf921050,
target=target@entry=0x0, tmode=tmode@entry=DImode,
modifier=modifier@entry=EXPAND_NORMAL, as=as@entry=0 '\000')
    at ../../gcc/expr.c:7761
7761      gcc_assert (inner != exp);
(gdb) p debug_tree (exp)
 <ssa_name 0x3fffaf921050
    type <real_type 0x3fffaf8c1500 long double XF
        size <integer_cst 0x3fffaf880cf0 constant 128>
        unit size <integer_cst 0x3fffaf880d08 constant 16>
        align 128 symtab 0 alias set 1 canonical type 0x3fffaf8c1500 precision
80
        pointer_to_this <pointer_type 0x3fffaf8c16f8>>
    visited var <parm_decl 0x3fffafa80000 x>def_stmt GIMPLE_NOP

    version 1>
$1 = void

Where clearly we have problem of copying it to SSA name.

I suppose code in https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00423.html may
need to happen on non-aggregates, too



More information about the Gcc-bugs mailing list