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

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=557262

http://bugzilla.novell.com/show_bug.cgi?id=557262#c0


           Summary: shr applied to int32 issue on 64-bit linux (no sign
                    in)
    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)
reproducer

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr;
rv:1.9.1.5) 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
bit
.. ; 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
32768
-2147483648
32768

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:  
32768
-2147483648
32768


Expected Results:  
32768
-2147483648
-32768


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.