BitScanForwardNode: LongBits test failure

[Tom Rodriguez]

> On Nov 30, 2016, at 11:03 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> I have test failure which baffles me.  BitScanForwardNode has a comment at
> the top:
> 
> /**
> * Determines the index of the least significant "1" bit. Note that the result is undefined if the
> * input is zero.
> */
> 
> But BitScanForwardNode.tryFold sometimes is called with the constant zero.
> 
> What seems to happen is that tryFold() fails, so foldStamp() is
> called, again with the constant zero.  Some rather tortured logic is
> executed and the result is that the stamp becomes -1 ... -1, so the
> constant -1 is substituted; this is wrong for
> Long.numberOfTrailingZeros(0);
> 
> A fix is obvious: correct tryFold() so that it works for 0.  But I
> don't understand how Long.numberOfTrailingZeros(0) works on other
> processors; yet presumably this test (LongBits) does pass there.

AArch64 seems to have it’s own version of numberOfTrailingZeros instead of using the default one.  The other uses of BitScanForwardNode are explicitly protected from 0.  That being said foldStamp should probably handle the case of 0 properly.  BitScanForwardNode is sort of x86 dependent which is why it has the weird specification.

tom


> 
> Andrew.