On Thu, Aug 29, 2013 at 01:46:03AM +0200, Marek Janukowicz wrote: > H. S. Teoh wrote: > > > On Thu, Aug 29, 2013 at 12:45:05AM +0200, Marek Janukowicz wrote: > >> H. S. Teoh wrote: > > [...] > >> > Oh, and BTW, are you on Linux 32-bit or 64-bit? Don't know if > >> > that makes a difference, but just in case. > >> > >> 64-bit > > [...] > > > > Maybe try compiling with -m32 and see if it makes a difference? If > > so, it may be a 64-bit related dmd bug. I'm also having trouble > > building a working compiler toolchain with a purely 64-bit > > environment. > > Yeah, it makes a difference :) [...] > This stacktrace did not show in 64-bit version, but the problem > persists. [...]
OK, my trouble with compiling 2.063.2 in 64-bit was actually my own fault -- I had a faulty dmd.conf -- so actually that has nothing to do with your problem. Anyway, I don't think it's a problem with libphobos2.a, because tracing through your failing test case, I see that it's all template functions instantiated from std.algorithm, and no static functions from the library are called at the point of failure. The template code in Phobos also looks kosher, so right now I'm suspecting a DMD codegen bug. I'm going to investigate the disassembly now to figure out what's going on. The good news is that the upcoming dmd 2.064 doesn't appear to have this problem: the part of std.algorithm that concerns your code doesn't appear to have been touched since 2.063.2, so the problem is unlikely to be there. So whatever dmd bug is causing the problem has been fixed in git HEAD. The bad news is that dmd 2.064 has some changes that makes it incompatible with 2.063.2 druntime/phobos, so you won't be able to use it unless you build the entire dmd/druntime/phobos toolchain from git. T -- "No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev