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?)
