[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