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

           Summary: Regression (2.057): Hex Literals are no longer treated
                    as unsigned.
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: flyboynw@gmail.com


--- Comment #0 from Adam Wilson <flyboynw@gmail.com> 2012-02-01 22:43:21 PST ---
I have taken this example code from druntime as that is what I was compiling for testing the new DI generation code. The only way to get bitop.d to compile using the GIT latest DMD was to add cast(uint) in front of every hex literal in the popcnt() function.

//BROKEN popcnt function
int popcnt( uint x )
{
    x = x - ((x>>1) & 0x5555_5555);
    x = ((x&0xCCCC_CCCC)>>2) + (x&0x3333_3333);
    x += (x>>4);
    x &= 0x0F0F_0F0F;
    x += (x>>8);
    x &= 0x00FF_00FF;
    x += (x>>16);
    x &= 0xFFFF;
    return x;
}
//FIXED popcnt function
int popcnt( uint x )
{
    x = x - ((x>>1) & cast(uint)0x5555_5555);
    x = ((x&cast(uint)0xCCCC_CCCC)>>2) + (x&cast(uint)0x3333_3333);
    x += (x>>4);
    x &= cast(uint)0x0F0F_0F0F;
    x += (x>>8);
    x &= cast(uint)0x00FF_00FF;
    x += (x>>16);
    x &= cast(uint)0xFFFF;
    return x;
}

Here is the full error dump from DMD:
typeMerge() x >> 1 op 1431655765
001E1E04 & type=null e1=001E1DBC e2=001E1DE0
  001E1DBC >> type=uint e1=023E3244 e2=001E1D98
    023E3244 var var=x type=uint
    001E1D98 1 type=int
  001E1DE0 1431655765 type=int
        t1 = uint
        t2 = int
assert cast.c(2082) t1->ty == t2->ty

-- 
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
----------------------------------------------------------------------------
           Priority|P2                          |P1
                 CC|                            |flyboynw@gmail.com


-- 
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


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr@puremagic.com


--- Comment #1 from Brad Roberts <braddr@puremagic.com> 2012-02-01 22:54:40 PST ---
Need more details as I can't reproduce the problem with:
  dmd -c src/core/bitop.d

Nor does dmd -c bug74723.d (with just your broken popcnt function in it).

Please include a standalone .d file and the command you executed to demonstrate the problem.

-- 
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 #2 from Adam Wilson <flyboynw@gmail.com> 2012-02-01 22:59:38 PST ---
This is the cmdline used: dmd -c -d -o- -Isrc -Iimport -Hfimport\core\bitop.di
src\core\bitop.d
It's lifted straight out of the Druntime win32.mak file.

Although I think the old DI generation code masks the problem because it leaves the function implementation in the DI file and DMD is properly able to sort it out from there. It was only when I stripped the function impl out of the DI file that I saw this issue.

The .d file was unchanged other than to add the casts. The NEW DI file is as follows:

// D import file generated from 'src\core\bitop.d'
module core.bitop;
nothrow
{
    pure int bsf(size_t v);

    pure int bsr(size_t v);

    pure int bt(in size_t* p, size_t bitnum);

    int btc(size_t* p, size_t bitnum);
    int btr(size_t* p, size_t bitnum);
    int bts(size_t* p, size_t bitnum);
    pure uint bswap(uint v);

    ubyte inp(uint port_address);
    ushort inpw(uint port_address);
    uint inpl(uint port_address);
    ubyte outp(uint port_address, ubyte value);
    ushort outpw(uint port_address, ushort value);
    uint outpl(uint port_address, uint value);
    int popcnt(uint x);
    debug (UnitTest)
    {
    }
    uint bitswap(uint x);
    debug (UnitTest)
    {
    }
}

-- 
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


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com
           Severity|regression                  |normal


--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2012-02-01 23:13:46 PST ---
I don't think this was a regression. Recategorized.

-- 
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 #4 from Adam Wilson <flyboynw@gmail.com> 2012-02-01 23:17:09 PST ---
Well, as long as it gets fixed I suppose categorization doesn't matter. My DI generation patch is sunk until this is fixed, and given that dynamic libraries work now, it'll be more important to get DI generation working properly. Actually, my whole project is sunk until DI generation starts working properly.

-- 
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 #5 from Brad Roberts <braddr@puremagic.com> 2012-02-01 23:21:05 PST ---
From what you've said so far, you have local changes and those changes broke something?  Sounds like you've got some debugging to do.  At a minimum, you'll need to show what you changed that cause the breakage.

At this point, there's nothing that's pointing to a bug in the current dmd code base.  I'm not saying there isn't a bug, but you've provided nothing in this report that allows anyone to see the bug you're seeing.

-- 
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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #6 from Don <clugdbug@yahoo.com.au> 2012-03-19 23:02:40 PDT ---
The only way I can see that there could be a bug, and yet be fixed by the
cast(uint), is this line:

(x & 0xCCCC_CCCC)>>2

This might fail if there's a 64 bit codegen issue, eg if it does a 64bit load of the constant, and then a 64 bit unsigned shift instead of a 32bit unsigned shift for this combination.

If that were true, then the results would only be wrong if the upper bits of the register were originally non-zero.

In all other cases, I can't see how the cast(uint) can be doing anything.

-- 
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 #7 from Adam Wilson <flyboynw@gmail.com> 2012-03-19 23:21:16 PDT ---
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);

No dice.

DMD throws on every Hex literal in druntime/phobos, 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.

-- 
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 #8 from Don <clugdbug@yahoo.com.au> 2012-03-20 01:42:17 PDT ---
(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).

> 
> 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.

> 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.

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