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



--- Comment #9 from Adam Wilson <flyboynw@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: -------

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



--- Comment #10 from Don <clugdbug@yahoo.com.au> 2012-03-20 12:35:34 PDT ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > 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.

I'm wrong, it's in the spec (lexer.html).

If it is in the range 0..int.max, it is an int.
If it is in the range int.max+1u .. uint.max, it is a uint.
You can check it with this:

static assert(is (typeof(0x7FFF_FFFF) == int));
static assert(is (typeof(0x8000_0000) == uint));

So, it looks as though your original interpretation of the issue wasn't correct. There may be something else going on though.

The fact that you were on Windows rules out a 64 bit codegen issue, which was the obvious scapegoat.

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

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



--- Comment #11 from Don <clugdbug@yahoo.com.au> 2012-03-21 01:35:59 PDT ---
I have tried to reproduce the ICE, but it always compiles for me, using core.bitop.d together with core.bitop.di and command line args from comment 2.


Is there any chance that you were doing this with a version of DMD you compiled yourself? I often get weird ICE bugs like this one if I don't do 'make clean' first -- the Win32 makefile for DMD is hopelessly broken, it has dozens of missing dependencies.

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

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


Adam Wilson <flyboynw@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


--- Comment #12 from Adam Wilson <flyboynw@gmail.com> 2012-03-31 15:02:46 PDT ---
Hello Don, I tried your 'make clean' suggestion and the build of druntime now works perfectly. I had no idea how bad the makefile really is ... Thank you!

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