[Issue 8991] adding a __ctfe branch with return to a function breaks NRVO
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Wed Nov 14 01:08:34 PST 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8991
--- Comment #3 from Don <clugdbug at yahoo.com.au> 2012-11-14 01:08:32 PST ---
I have no idea why this evil hacky code exists in Phobos, I cannot see how it
can possibly be correct. If it bypasses postblit, surely that's wrong.
If it is faster to use memcpy(), that's a compiler bug.
But anyway, it fails because it detects that two different variables are being
returned.
The workaround is easy:
+ T result = void;
if (__ctfe)
{
*cast(int*)0 = 0; //to demonstrate that no CTFE is attempted
- T result = source;
+ result = source;
return result; //must have broke NRVO
}
- T result = void;
Now, although it would be possible to hack IfStatement::semantic to check for
__ctfe
or !__ctfe, and restore fd->nrvo_var, this would fail in cases like:
if (__ctfe) {
Lnasty:
T result = source;
return result;
}
if (b) goto Lnasty;
T result = void;
return result;
The problem is, that NRVO is run during the semantic pass, rather than
afterwards.
Personally I think that inlining should happen after the semantic3 pass (it
would make CTFE *much* simpler), and I think NRVO could happen then as well.
Otherwise I'm not sure that this is worth doing anything about. It is still
true that if (__ctfe ) never affects backend code generation, it's just odd
that DMD is doing NRVO in the front-end.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list