Comment #0 by electrolysis.jp+d — 2014-01-03T10:38:46Z
import std.conv, std.stdio;
void main(){
/// int
static assert(to!string(15, 10) == "15"); // success
// assert(to!string(15, 10) == "15"); // failure
assert(to!wstring(15, 10) == "15"w); // success
assert(to!dstring(15, 10) == "15"d); // success
writeln(to!string(15, 10)); // ??
/// uint
static assert(to!string(15u, 10) == "15"); // success
// assert(to!string(15u, 10) == "15"); // failure
assert(to!wstring(15u, 10) == "15"w); // success
assert(to!dstring(15u, 10) == "15"d); // success
writeln(to!string(15u, 10)); // ??
/// long
static assert(to!string(15L, 10) == "15"); // success
assert(to!string(15L, 10) == "15"); // success
}
In the case of "(r)dmd foo.d", only to!string(int, radix) and
to!string(uint, radix) return "0" at run time with any radix
though "15" is returned when compiled with "-debug".
Environment: DMD 2.064.2 on Win7 SP1 32-bit
Comment #1 by monarchdodra — 2014-01-03T12:55:28Z
I did some investigating, and the Phobos code is legit. Duplicating the function, while leaving it where it is, does not reproduce the issue. Furthermore, older versions of DMD do not reproduce this issue either.
It makes me think that ctfe instantiation is causing something weird later for runtime.
I did a bissect, and hit this commit:
12bb9afb753ad2f2aef65550b960357c63854cbc is the first bad commit
commit 12bb9afb753ad2f2aef65550b960357c63854cbc
Author: Walter Bright <[email protected]>
Date: Wed Sep 11 14:33:14 2013 -0700
fix Issue 10441 - Static libraries too big
:040000 040000 00ef3e43d4274d2e24514810353fead7bbcdaee9 313550fcc47de2b124d69f05bce5f94586bc2b01 M src
:040000 040000 13dbdadb43e009e4e10041a161e1c825110f8028 7bcbc44d497d9056603b0863d781b894ff49b4ab M test
Seems to be related. I think.
Comment #2 by k.hara.pg — 2014-01-04T23:42:17Z
Hmm, with "-allinst" switch, OP code runs successfully in Windows (Both -m32 and -m64).
Comment #3 by monarchdodra — 2014-01-05T00:10:54Z
(In reply to comment #2)
> Hmm, with "-allinst" switch, OP code runs successfully in Windows (Both -m32
> and -m64).
I *thought* I had tried that, but I must have gotten it wrong. I can confirm it works too for linux64.
So... is this an actual bug?
http://d.puremagic.com/issues/show_bug.cgi?id=11284
Seems to indicate the problem would come from a "build irregularity"? Does this mean there is a Phobos build irregularity?
Comment #4 by k.hara.pg — 2014-01-05T00:29:47Z
(In reply to comment #2)
> Hmm, with "-allinst" switch, OP code runs successfully in Windows (Both -m32
> and -m64).
Instead of "-allinst", "-release" also suppresses the error.
(In reply to comment #3)
> (In reply to comment #2)
> > Hmm, with "-allinst" switch, OP code runs successfully in Windows (Both -m32
> > and -m64).
>
> I *thought* I had tried that, but I must have gotten it wrong. I can confirm it
> works too for linux64.
>
> So... is this an actual bug?
> http://d.puremagic.com/issues/show_bug.cgi?id=11284
> Seems to indicate the problem would come from a "build irregularity"? Does this
> mean there is a Phobos build irregularity?
I'm not sure, but essentially I think "build irregularity" should not be there. If it exists, it is a fault of separate compilation feature.
Current template instantiation strategy is fragile. Walter's implementation is often does not fully cover target cases when it is introduced...