[Bug 31330] New: +relay corrupts returns values on win64?

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=31330

             Bug #: 31330
           Summary: +relay corrupts returns values on win64?
           Product: Wine
           Version: 1.5.9
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: -unknown
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: dank at kegel.com
    Classification: Unclassified


The little program

#include <float.h>
#include <math.h>
#include <stdio.h>
int main(int argc, char **argv)
{
    int log2FLT_RADIX;
    double x = frexp((double) FLT_RADIX, &log2FLT_RADIX);
    printf("x is %g; wanted == 0.5\n", x);
    if (frexp((double) FLT_RADIX, &log2FLT_RADIX) != 0.5)
        printf("Trouble!  Not equal.\n");
    else
        printf("Whew!  Equal.\n");
}

(attached, with 32 and 64 bit binaries produced with visual c 2010)

prints out "Whew!  Equal." normally, but when run with +relay, the 64
bit version prints out "Trouble!  Not equal."  The 32 bit version is fine.

This is a test case extracted from TCL, which aborts 
with "This code doesn't work on a decimal machine!" when that comparison fails
(see http://brlcad.org/xref/source/src/other/tcl/generic/tclStrToD.c#L2176 ).
(You can see that error if you like by starting tclsh.exe from
the 64 bit download at http://www.activestate.com/activetcl/downloads 
with +relay on.)

While comparing doubles for equality is not a good idea, in this special
case it ought to be ok, and it seems surprising that +relay would break it.

The output with +relay seems to show random 32 bit values for the return value

0030:Call msvcrt.frexp(4000000000000000,0022fd48) ret=140001020
0030:Ret  msvcrt.frexp() retval=ffffffff ret=140001020
...
This code doesn't work on a decimal machine!
...
abnormal program termination
0032:Ret  KERNEL32.WriteConsoleA() retval=00000001 ret=7f4a2344372f
0032:Call KERNEL32.ExitProcess(00000003) ret=7f4a23453001

Adding a TRACE to frexp shows it's trying to return the right thing,
and changes the supposed return value:

0036:Call msvcrt.frexp(4000000000000000,100d093c) ret=10082b8c
trace:msvcrt:MSVCRT_frexp (2, 0x100d093c) returning 0.5, storing 2
0036:Ret  msvcrt.frexp() retval=00000043 ret=10082b8c

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.