Bug 9356 – -inline with inout and append generates wrong code
Status
RESOLVED
Resolution
FIXED
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-01-20T04:07:00Z
Last change time
2013-11-11T23:22:13Z
Keywords
pull, wrong-code
Assigned to
yebblies
Creator
doob
Comments
Comment #0 by doob — 2013-01-20T04:07:46Z
The assert in "foo" passes, which it obviously shouldn't.
inout(char)[] bar (inout(char)[] a)
{
return a;
}
void foo (string str)
{
string result;
result ~= bar(str);
assert(result == "!");
}
void main ()
{
foo("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa");
}
If I remove "inout" in "bar" or the append in "foo" the code work as expected. What "result" will actually be depends on the length of the string passed to "foo".
I've only tried this with on Mac OS X, both 32 and 64bit.
Comment #1 by r.sagitario — 2013-06-23T23:21:31Z
I have hit this bug with a recent commit to druntime that changes the implementation of AssociativeArray.keys:
import std.stdio;
void main()
{
string[] files;
files ~= "1";
files ~= "2";
byte[string] cache;
cache["3"] = 1;
cache["4"] = 1;
files ~= cache.keys;
writeln(files);
}
when compiled with -inline, it prints
["1", "2", "\x01\x00"]
This seems to be caused by inout(T[]) not being appendable to T[]. Instead it is appended as a single element (_d_arrayappendcT is called, see CatAssignExp::toElem).
In case of AssociativeArray.keys, there also seems to be a problem that inlining seems to ignore implicite conversion on the return type by the inlined function.
Comment #2 by yebblies — 2013-06-28T06:53:01Z
Yeah, the inliner ends up replacing the call expression with the return expression, but doesn't re-paint the type to account for castless implicit conversions. e2ir uses if/else when it should be using if/elseif/else assert, so it generates wrong code instead of ICEing.
https://github.com/D-Programming-Language/dmd/pull/2269
Comment #3 by github-bugzilla — 2013-11-09T10:21:06Z