Translation of D test gdc.test/runnable/testv.d that segfaults when compiled with -O2, and linking libraries in dynamically. --- // Compiled with -m32 -O2 int printf(const char*, ...); _Thread_local int a1[2] = {5,6}; _Thread_local int a2[3] = {5,6,7}; _Thread_local int a3[4] = {5,6,7,8}; int sum3(int* xx, int length) { int s = 0; for (int i = 0; i < length; i++) { int x = xx[i]; s += x; } return s; } int main() { printf("%d\n", sum3(a3, sizeof(a3) / sizeof(a3[0]))); return 0; } --- --- Dump of assembler code for function main: 0x08050c60 <+0>: lea 0x4(%esp),%ecx 0x08050c64 <+4>: and $0xfffffff0,%esp 0x08050c67 <+7>: pushl -0x4(%ecx) 0x08050c6a <+10>: push %ebp 0x08050c6b <+11>: mov %esp,%ebp 0x08050c6d <+13>: push %ecx 0x08050c6e <+14>: sub $0xc,%esp 0x08050c71 <+17>: mov %gs:0x0,%eax 0x08050c77 <+23>: lea -0x4(%esp),%esp => 0x08050c7b <+27>: movdqa -0x28(%eax),%xmm0 0x08050c83 <+35>: movdqa %xmm0,%xmm1 0x08050c87 <+39>: psrldq $0x8,%xmm1 0x08050c8c <+44>: paddd %xmm1,%xmm0 0x08050c90 <+48>: movdqa %xmm0,%xmm1 0x08050c94 <+52>: psrldq $0x4,%xmm1 0x08050c99 <+57>: paddd %xmm1,%xmm0 0x08050c9d <+61>: movd %xmm0,(%esp) 0x08050ca2 <+66>: push $0x80509f8 0x08050ca7 <+71>: call 0x8050a4c <printf@plt> 0x08050cac <+76>: mov -0x4(%ebp),%ecx 0x08050caf <+79>: add $0x10,%esp 0x08050cb2 <+82>: xor %eax,%eax 0x08050cb4 <+84>: leave 0x08050cb5 <+85>: lea -0x4(%ecx),%esp 0x08050cb8 <+88>: ret End of assembler dump. ---
The specific CPU config options of -m32 are: -mcpu=generic -march=pentium4 -mtune=generic
Are you using Solaris's ld or as? Or what version of binutils are you using? Yes it does matter here.
(In reply to Andrew Pinski from comment #2) > Are you using Solaris's ld or as? Or what version of binutils are you using? > Yes it does matter here. Configured gcc --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as ld version: Solaris Link Editors: 5.11-1.3159 as version: GNU Binutils: 2.30
I suppose that maybe solaris does not align TLS vars with custom DECL_ALIGN properly, but maybe you also did not have g:eed248bb8cc3091e8 in your tree?
(In reply to Richard Biener from comment #4) > I suppose that maybe solaris does not align TLS vars with custom DECL_ALIGN > properly, but maybe you also did not have g:eed248bb8cc3091e8 in your tree? I'm on r12-4811, but just doing a little bisect at the moment, as I don't see gcc-10 generating a movdqa instruction.
(In reply to Iain Buclaw from comment #5) > (In reply to Richard Biener from comment #4) > > I suppose that maybe solaris does not align TLS vars with custom DECL_ALIGN > > properly, but maybe you also did not have g:eed248bb8cc3091e8 in your tree? > I'm on r12-4811, but just doing a little bisect at the moment, as I don't > see gcc-10 generating a movdqa instruction. Not that there's a regressing commit anywhere, just a change exposed a problem with Solaris.
(In reply to Iain Buclaw from comment #6) > Not that there's a regressing commit anywhere, just a change exposed a > problem with Solaris. First commit it started occurring with -O2 is r12-4240. This gives an idea of which individual options to use explicitly.
(In reply to Iain Buclaw from comment #6) > Not that there's a regressing commit anywhere, just a change exposed a > problem with Solaris. First commit it started occurring with -O2 -ftree-vectorize is r10-4704.