Am Tue, 14 May 2013 18:59:14 +0200 schrieb "Iain Buclaw" <ibuc...@ubuntu.com>:
> core.exception.AssertError@libphobos/src/std/range.d(2995): This is a weird bug: This is what happens: Struct Take consists of an int and a size_t. In between those two we have 4 bytes padding on x86_64. If GCC returns this struct from a function it just ignores the padding and the padding remains 'unchanged' from the 'original' value. Test case: http://dpaste.dzfl.pl/cce31911 Cannot reproduce with dpaste gdc 2.060 so this might be a regression. Some ASM: Optimized & inlined: -------------- 0x000000000040265a <+26>: movl $0x1,(%rsp) 0x0000000000402661 <+33>: movq $0x5,0x8(%rsp) 0x000000000040266a <+42>: movl $0x1,0x10(%rsp) 0x0000000000402672 <+50>: movq $0x5,0x18(%rsp) 0x000000000040267b <+59>: callq 0x401bc0 <memcmp@plt> -------------- Notice how gcc uses movl & movq. 0x4(%rsp) is not being accessed / initialized. Not optimized: -------------- 0x000000000040267b <+27>: callq 0x4025e0 <_D5range4takeFimZS5range4Take> 0x0000000000402680 <+32>: mov %eax,%ecx 0x0000000000402682 <+34>: mov %rdx,%rax 0x0000000000402685 <+37>: mov %ecx,-0x50(%rbp) 0x0000000000402688 <+40>: mov %rax,-0x48(%rbp) -------------- Here GCC uses the 4 byte registers for the int. We could force all local variables to be initialized to .init to fix this specific case, but I'm not sure if that would fix this bug completely. We also have to consider that the variables could be temporaries.... I wonder how C/C++ deals with this.
