[Mono-bugs] [Bug 557262] New: shr applied to int32 issue on 64-bit linux (no sign in)

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Fri Nov 20 11:07:57 EST 2009



           Summary: shr applied to int32 issue on 64-bit linux (no sign
    Classification: Mono
           Product: Mono: Compilers
           Version: 2.4.x
          Platform: x86-64
        OS/Version: Ubuntu
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: IL assembler
        AssignedTo: jankit at novell.com
        ReportedBy: lambourg at adacore.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---

Created an attachment (id=328709)
 --> (http://bugzilla.novell.com/attachment.cgi?id=328709)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr;
rv: Gecko/20091102 Firefox/3.5.5

The following sequence produces unexpected results on 64-bit linux:
ldc.i4 32768
conv.i4 ; just make sure this is an int32

dup ; dup for debug output
call void class [mscorlib]System.Console::WriteLine(int32) ; debug output

ldc.i4.s 16
shl ; we should have now -2^31 on the stack
.. ; same debug sequence
ldc.i4.s 16
shr ; we should now have -32768 on the stack, as shr completes with the sign
.. ; debug

The expected result is
32768           -- initial value
-2147483648     -- an int32 value that is initial shifted 16-bit left
-32768          -- we shifted back to the initial value, with the sign bit kept

The actual result is

As shown here, the shr operation does not propagate the sign, as it should have
as described by the ECMA standard (and as opposed to shr.un)

Further investigation show that the shr operation seems to propagate the sign
only when used with int64 numbers (if I convert first to an int64, and then
shift right then left 48 bits, then I correctly obtain in the end -32768).

Reproducible: Always

Steps to Reproduce:
1. with a 64-bit mono:
2. compile the attached il file (ilasm /exe testshift.il)
3. run it (mono ./testshift.exe)
Actual Results:  

Expected Results:  

I verified in the ECMA standard:
* In partition III, the table 6 clearly shows that the resulting type of a
shift operation must have the same type, and that shifting an int32 should be
allowed (no constraint on host)
* Still in partition III, 3.59 describes shr, and clearly states "shr
replicates the high order bit on each shift, preserving the sign of the
original value in result."

Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the mono-bugs mailing list