www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7423] New: Regression (2.057): Hex Literals are no longer treated as unsigned.

reply d-bugmail puremagic.com writes:
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



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: -------
Feb 01 2012
next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423


Brad Roberts <braddr puremagic.com> changed:

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



---
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: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423




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: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423




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: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423




---
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: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423


Don <clugdbug yahoo.com.au> changed:

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



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: -------
Mar 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423




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: -------
Mar 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423






 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: -------
Mar 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423








 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: -------
Mar 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423









 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: -------
Mar 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423




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: -------
Mar 21 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7423


Adam Wilson <flyboynw gmail.com> changed:

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



---
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: -------
Mar 31 2012