and what is the 16 byte struct bug?

http://forum.dlang.org/post/nqqujtblyvxvtrlsbcpx@forum.dlang.org

import std.datetime;
import std.range;
import std.stdio;

struct DateRate {
  Date date;
  double value = 0.0;
}

struct RateCurve {
  private immutable(DateRate)[] _data;
}

struct CFS {
  double initialValue;
  RateCurve growth;
}

void main() {
  auto s = CFS(1.0);
  // auto s = CFS(1.0, RateCurve()); // crashes
  // auto s = CFS(1.0, RateCurve([])); // works
  writeln(s);
}

Ok - pretty sure this is not related to 16-byte structs, since if I just remove one of the fields it still crashes. I opened an issue - and here is a simplified version:

http://d.puremagic.com/issues/show_bug.cgi?id=11440

import std.stdio;

struct Y {
  private immutable(int)[] _data;
}

struct CFS {
  double x = 5;
  Y growth;
}

void main() {
  auto s = CFS(1.0);      // crash
  //auto s = CFS(1, Y()); // crash
  //auto s = CFS(1, Y([])); // works
  writeln(s);
}

On Monday, 4 November 2013 at 19:24:11 UTC, Daniel Davidson wrote:
> Ok - pretty sure this is not related to 16-byte structs, since if I just remove one of the fields it still crashes. I opened an issue - and here is a simplified version:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=11440
>
> import std.stdio;
>
> struct Y {
>   private immutable(int)[] _data;
> }
>
> struct CFS {
>   double x = 5;
>   Y growth;
> }
>
> void main() {
>   auto s = CFS(1.0);      // crash
>   //auto s = CFS(1, Y()); // crash
>   //auto s = CFS(1, Y([])); // works
>   writeln(s);
> }

What do you mean by crash ?

>> void main() {
>>  auto s = CFS(1.0);      // crash
>>  //auto s = CFS(1, Y()); // crash
>>  //auto s = CFS(1, Y([])); // works
>>  writeln(s);
>> }
>
> What do you mean by crash ?

It's segfaults. It doesn't happen if you change 1.0 literal to
some other value,
say 2.0. It's a truly bizarre bug.

Here's a slightly simplified case:

import std.stdio;

struct Y {
     int[] _data;
}

struct CFS {
     double x;
     Y growth;
}

void main() {
     auto s = CFS(2.0);
     writefln("%x", s.growth._data.length); // prints
3ff0000000000000
}

It doesn't happen with -O, or when compiled with LDC or GDC.

> It doesn't happen with -O, or when compiled with LDC or GDC.

And it doesn't happen when building with -m32 (I'm on x86_64
linux).

OK.

Now usual question to try to understand what is going wrong.

Can you try on 32/64 bits ? Also, what happen with GDC and LDC ?

On Monday, 4 November 2013 at 22:27:39 UTC, deadalnix wrote:
> OK.
>
> Now usual question to try to understand what is going wrong.
>
> Can you try on 32/64 bits ? Also, what happen with GDC and LDC ?

The code I posted above prints 3ff0000000000000 when built with
dmd on x86_64 without any flags. It prints 0 if I build with LDC
or GDC, or if I build with DMD and add either -O flag or -m32.

On Monday, 4 November 2013 at 22:42:35 UTC, jerro wrote:
> On Monday, 4 November 2013 at 22:27:39 UTC, deadalnix wrote:
>> OK.
>>
>> Now usual question to try to understand what is going wrong.
>>
>> Can you try on 32/64 bits ? Also, what happen with GDC and LDC ?
>
> The code I posted above prints 3ff0000000000000 when built with
> dmd on x86_64 without any flags. It prints 0 if I build with LDC
> or GDC, or if I build with DMD and add either -O flag or -m32.

Then it look like a dmd backend bug. Can you post the generated assembly ?

> Then it look like a dmd backend bug. Can you post the generated assembly ?

000000000043050c <_Dmain>:
   43050c:       push   %rbp
   43050d:       mov    %rsp,%rbp
   430510:       sub    $0x40,%rsp
   430514:       movabs $0x3ff0000000000000,%rax
   43051b:
   43051e:       mov    %rax,-0x40(%rbp)
   430522:       movsd  -0x40(%rbp),%xmm0
   430527:       rex.W movsd %xmm0,-0x30(%rbp)
   43052d:       xor    %edx,%edx
   43052f:       mov    %rax,-0x10(%rbp)
   430533:       mov    %rdx,-0x8(%rbp)
   430537:       mov    %rax,-0x28(%rbp)
   43053b:       mov    %rdx,-0x20(%rbp)
   43053f:       mov    0x28022(%rip),%rdx
   430546:       mov    0x28013(%rip),%rsi
   43054d:       mov    -0x28(%rbp),%rdi
   430551:       callq  430874 <void
std.stdio.writefln!(immutable(char)[],
ulong).writefln(immutable(char)[], ulong)>
   430556:       xor    %eax,%eax
   430558:       leaveq
   430559:       retq

On Monday, 4 November 2013 at 22:56:48 UTC, jerro wrote:
>> Then it look like a dmd backend bug. Can you post the generated assembly ?
>
> 000000000043050c <_Dmain>:
>    43050c:       push   %rbp
>    43050d:       mov    %rsp,%rbp
>    430510:       sub    $0x40,%rsp
>    430514:       movabs $0x3ff0000000000000,%rax
>    43051b:
>    43051e:       mov    %rax,-0x40(%rbp)
>    430522:       movsd  -0x40(%rbp),%xmm0
>    430527:       rex.W movsd %xmm0,-0x30(%rbp)
>    43052d:       xor    %edx,%edx
>    43052f:       mov    %rax,-0x10(%rbp)
>    430533:       mov    %rdx,-0x8(%rbp)
>    430537:       mov    %rax,-0x28(%rbp)
>    43053b:       mov    %rdx,-0x20(%rbp)

>    43053f:       mov    0x28022(%rip),%rdx
>    430546:       mov    0x28013(%rip),%rsi

What are these ? What are they referering to ?

>    43054d:       mov    -0x28(%rbp),%rdi
>    430551:       callq  430874 <void
> std.stdio.writefln!(immutable(char)[],
> ulong).writefln(immutable(char)[], ulong)>
>    430556:       xor    %eax,%eax
>    430558:       leaveq
>    430559:       retq

This calls writefln, this is not what your code does just above. Are you sure you are posting the right assembly ? Do you use the inline flag ?