search for: getvmcontext

Carl, See clang/lib/CodeGen/TargetInfo.cpp. // FIXME: mingw64-gcc emits 128-bit struct as i128 if (Size <= 128 && (Size & (Size - 1)) == 0) return ABIArgInfo::getDirect(llvm::IntegerType::get(getVMContext(), Size)); It was my workaround, sorry. Please check to tweak the clause (128 to 64) and lemme know. ...Takumi On Tue, Feb 22, 2011 at 7:58 AM, Carl Norum <carl.norum at apple.com> wrote: > > The MS x64 ABI calling convention...

The MS x64 ABI calling convention (http://msdn.microsoft.com/en-us/library/ms235286(VS.80).aspx) says: Any argument that doesn’t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference. Clang isn't doing that for us when passing our triple, x86_64-pc-win32-macho. Here's a simple example program: struct Guid { unsigned int Data1; unsigned

Objects compiled for the MS-ABI don't conform to it! Data types beyond 64 bit MUST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t

...orm to the ABI. You can look at some of the other > classify*Type methods in Clang for how. Would you mind elaborating where to look, specifically? What I'm seeing is that some classify*Type methods select different types, like e.g.: return ABIArgInfo::getDirect(llvm::Type::getInt64Ty(getVMContext())); I was hoping this could be used to implement extension for ABI purposes, but it doesn't look like this will work (with the current infrastructure). If the type specified in the classify*Type method is larger than the actual parameter/return value type, CGCall.cpp will in fact create exte...

So, I'm not really sure if this is the right approach. I'd like some folks from the LLVM side of things to chime in. In general, I'm not certain we want to continue growing our dependence on the signext and zeroext attributes on return types, or whether we want to do the extension in the frontend instead. Most of the targets in Clang currently eagerly zext or sext the return value to