[Issue 2809] Wrong constant folding for unsigned shift

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=2809


Don <clugdbug at yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


--- Comment #2 from Don <clugdbug at yahoo.com.au> 2010-01-17 11:48:08 PST ---
Now I'm really confused. In Walter's test suite, this case is explicitly
tested!

static assert((cast(short)-1 >>> 1) == int.max);

There's a wrong statement in the bug description.
"Here compiler complains about conversion to return type:
---
short a(short b) { return b>>>1; } "

the response to this should be:
short a(short b) { return b>>>cast(short)1; }

So I'm rather confused about whether this is a bug, or intended (but
unintuitive) behaviour.

If it's a bug, it can be fixed by modifying UshrExp::semantic(Scope *sc) in
expression.c (around line 10103):
    e1 = e1->checkIntegral();
    e2 = e2->checkIntegral();
-    e1 = e1->integralPromotions(sc);
+    e = e1->integralPromotions(sc);
    e2 = e2->castTo(sc, Type::tshiftcnt);
-    type = e1->type;
+    type = e->type;
    }
    return this;

and in constfold.c Ushr(), around line 600, removing two asserts.
    case Tint8:
    case Tuns8:
-        assert(0);        // no way to trigger this
        value = (value & 0xFF) >> count;
        break;

    case Tint16:
    case Tuns16:
-        assert(0);        // no way to trigger this
        value = (value & 0xFFFF) >> count;
        break;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------