This is the mail archive of the gcc-bugs@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]

[Bug target/61949] [4.10 regression] SEGV compiling gcc.dg/pch/import-[12].c


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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com
          Component|middle-end                  |target

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, I can reproduce similar code it on i?86-linux with -msse2
-fno-omit-frame-pointer.  Does Solaris 10 properly align the stack for
stack-realignment to work?  That is, does

void *
md5_read_ctx (const struct md5_ctx *ctx, void *resbuf)
{
  md5_uint32 buffer[4] __attribute__((aligned(16)));

  buffer[0] = SWAP (ctx->A);
  buffer[1] = SWAP (ctx->B);
  buffer[2] = SWAP (ctx->C);
  buffer[3] = SWAP (ctx->D);

  memcpy (resbuf, buffer, 16);

  return resbuf;
}

work reliably to align buffer to 16 bytes?  On x86_64-linux with -m32 I get

md5_read_ctx:
.LFB3:
        .cfi_startproc
        pushl   %ebp
        .cfi_def_cfa_offset 8
        .cfi_offset 5, -8
        movl    %esp, %ebp
        .cfi_def_cfa_register 5
        subl    $24, %esp
        movl    8(%ebp), %edx
        movl    12(%ebp), %eax
        movl    (%edx), %ecx
        movl    %ecx, -24(%ebp)
        movl    4(%edx), %ecx
        movl    %ecx, -20(%ebp)
        movl    8(%edx), %ecx
        movl    12(%edx), %edx
        movl    %ecx, -16(%ebp)
        movl    %edx, -12(%ebp)
        movaps  -24(%ebp), %xmm0
        movups  %xmm0, (%eax)
        leave
        .cfi_restore 5
        .cfi_def_cfa 4, 4
        ret

which should be aligned if the incoming stack is aligned to 16 bytes.

Ok interestingly we do build an unaligned TImode load from the builtin
folder but then expansion concludes that the load is aligned after all
because the VAR_DECL has 16byte alignment:

Breakpoint 6, expand_expr_real_1 (exp=<mem_ref 0x7ffff6df5280>, 
    target=0x7ffff6e003d8, tmode=TImode, modifier=EXPAND_NORMAL, alt_rtl=0x0, 
    inner_reference_p=false) at /space/rguenther/src/svn/trunk/gcc/expr.c:9730
9730            if (mem_ref_refers_to_non_mem_p (exp))
 <mem_ref 0x7ffff6df5280
    type <integer_type 0x7ffff6df45e8 unsigned TI
        size <integer_cst 0x7ffff6c2efd8 constant 128>
        unit size <integer_cst 0x7ffff6c49000 constant 16>
        align 32 symtab 0 alias set -1 canonical type 0x7ffff6c50930 precision
128 min <integer_cst 0x7ffff6c491e0 0> max <integer_cst 0x7ffff6c3e618
0xffffffffffffffffffffffffffffffff>>

    arg 0 <addr_expr 0x7ffff6d4dfe0
        type <pointer_type 0x7ffff6df42a0 type <array_type 0x7ffff6df4000>
            public unsigned SI
            size <integer_cst 0x7ffff6c2ec30 constant 32>
            unit size <integer_cst 0x7ffff6c2ec48 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0x7ffff6df4348>

        arg 0 <var_decl 0x7ffff6deb1b0 buffer type <array_type 0x7ffff6df4000>
            used BLK file /space/rguenther/src/svn/trunk/libiberty/md5.c line
68 col 14 size <integer_cst 0x7ffff6c2efd8 128> unit size <integer_cst
0x7ffff6c49000 16>
            align 128 context <function_decl 0x7ffff6dedc00 md5_read_ctx>
            (mem/c:BLK (plus:SI (reg/f:SI 78 virtual-stack-vars)
        (const_int -16 [0xfffffffffffffff0])) [3 buffer+0 S16 A128])>
        /space/rguenther/src/svn/trunk/libiberty/md5.c:75:19>
    arg 1 <integer_cst 0x7ffff6d71d98 type <pointer_type 0x7ffff6df4540>
constant 0>>

if that's the same on solaris10/x86 then for some reason expansion cannot
align that stack local as it says it is aligned.  You can also see this
from the expansion of the buffer[0] store:

(insn 8 7 0 (set (mem/c:SI (plus:SI (reg/f:SI 78 virtual-stack-vars)
                (const_int -16 [0xfffffffffffffff0])) [3 buffer+0 S4 A128])
        (reg:SI 91)) /space/rguenther/src/svn/trunk/libiberty/md5.c:70 -1
     (nil))

see how it says A128.

So eventually the backend is wrong in handing out such large alignment
to stack locals or the code that is supposed to dynamically re-align
the stack doesn't trigger or doesn't work.

Please do some more digging on the Solaris side.  Target issue, stack
alignment related (HJ?)


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