http://d.puremagic.com/issues/show_bug.cgi?id=2809
Don <clugd...@yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--- Comment #2 from Don <clugd...@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: -------
