Comment #0 by kevin.lamonte — 2014-04-16T10:06:26Z
Encountered this working on a templated matrix library at https://github.com/klamonte/eng. Here is a reduced test case:
----
import std.conv;
import std.complex;
import std.stdio;
public class foo(T) {
private T [] data;
public this(size_t length, T item) {
data = new T[length];
version (X86_64) {
static if ((is(T == Complex!(float))) ||
(is(T == Complex!(double))) ||
(is(T == Complex!(real)))
) {
for (auto i = 0; i < data.length; i++) {
data[i] = to!(T)(item);
}
} else {
data[0 .. $] = to!(T)(item);
}
} else {
data[0 .. $] = to!(T)(item);
}
}
}
unittest {
auto test = new foo!(Complex!(double))(20, Complex!(double)(3, -4));
stdout.writefln("test %s", test.data[10]);
auto test2 = new foo!(float)(20, 1.23);
stdout.writefln("test2 %s", test2.data[10]);
}
public void main() {
stdout.writeln("Hello.");
}
----
Normal output via 'dmd -unittest test.d -oftest ; ./test':
----
test 3-4i
test2 1.23
Hello.
----
Remove the version(X86_64) guard so that the line 'data[0 .. $] = to!(T)(item);' executes when T is Complex, and the output is:
----
Segmentation fault
----
Either the 'data[0 .. $] = ...'code path is broken when the compiler emits 64-bit, or the same code path is only working accidentally on 32-bit and it should have failed to compile. I'm not 100% sure which.
Also: the severity help text does not define the differences between normal, major, critical, etc. Feel free to change as needed, obviously I can workaround this issue in my code.
Comment #1 by dlang.element126 — 2014-06-08T21:05:03Z
Created attachment 1361
Test case
Comment #2 by dlang.element126 — 2014-06-08T21:33:30Z
DMD 2.065.0 64bit. Arch Linux.
Using array operations like `array[] = complex(1.0,2.0);` with the `Complex!double` struct may cause a segmentation fault when compiled with DMD 64 bit. See the attached test case.
This code works and gives expected results with GDC 4.9.0-2 and LDC2 0.12.1-2, or with DMD when compiled with the `-m32` switch. It is specific to the `double` type, and works with `Complex!float` and `Complex!real`.
Interestingly, and although the segfault seems deterministic, uncommenting the call to `writeln()` on the previous line prevents it, but the array operation then does nothing (the array keeps the initial values, not necessarily `nan+nani` like in the test case).
Comment #3 by ag0aep6g — 2016-08-09T21:07:10Z
Both test cases segfault with 2.065, but seem to work correctly since 2.066. Closing as WORKSFORME.