[LLVMbugs] [Bug 10645] New: Support for sret and thiscall on msvc++ (32)

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=10645

           Summary: Support for sret and thiscall on msvc++ (32)
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gleizesd at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Right now if LLVM code calls a method with "X86_thiscall" calling convention
(compiled with msvc++) that returns a struct by copy, the program will crash
(or will behave incorrectly).

When the first parameter is a structure return pointer with "sret" attribute,
it should not be put in ECX, and the "this" value will be the second parameter.

I modified manually the X86GenCallingConv.inc to bypass the issue, and seems to
work correctly. I am not used to the .td syntax :(, but in the
X86CallingConv.td, the CC_X86_32_ThisCall should become something like this
(?):

def CC_X86_32_ThisCall : CallingConv<[
  // Promote i8/i16 arguments to i32.
  CCIfType<[i8, i16], CCPromoteToType<i32>>,

  // The 'nest' parameter, if any, is passed in EAX.
  CCIfNest<CCAssignToReg<[EAX]>>,

  // Do not pass the sret argument in ECX     
  CCIfSRet<CCDelegateTo<CC_X86_32_Common>>,

  // The first integer argument is passed in ECX
  CCIfType<[i32], CCAssignToReg<[ECX]>>,

  // Otherwise, same as everything else.
  CCDelegateTo<CC_X86_32_Common>
]>;

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.