http://d.puremagic.com/issues/show_bug.cgi?id=7423
--- Comment #9 from Adam Wilson <flybo...@gmail.com> 2012-03-20 09:38:56 PDT --- (In reply to comment #8) > (In reply to comment #7) > > I initially thought something along the same lines and tried it on a single > > statement like so: > > > > x = (cast(unit)((x&0xCCCC_CCCC)>>2)) + (x&0x3333_3333); > > That wouldn't work, you have to cast before the shift happens. > > x = ((cast(unit)(x&0xCCCC_CCCC))>>2) + (x&0x3333_3333); > > Was this on a 64 bit system? (If it was on Windows, we can rule out this > theory > entirely). Yea, you're right, it's been a while since I tried it. I don't bit-shift much in my normal coding activities so it's not something I understand well. Yes, it was on Win64. > > > > > No dice. > > > > DMD throws on every Hex literal in druntime/phobos, > > What do you mean by that? Do you mean, generates an internal compiler error? > Can't reproduce that. It asserts to be precise. And it *only* does this when an autogenerated DI file does not have the function impls in it. For some reason it appears that if the DI file itself has the impl in it, there is no problem. > > regardless of usage; hence > > the cast(unit) sitting directly in front of the literal itself. Based on the > > debugging info that I see, it looks like DMD is internally creating int's > > out > > of hex literals somewhere. > > Hex literals are supposed to be ints, not uints. The code should work anyway, > because x is a uint, therefore (x & LITERAL) is of type uint. Sigh, and I've got a number of other people telling me it should be uint. I'm going to ask Walter for the final answer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
