similar to: Is it a va_arg bug in clang?

Hi Richard, Thank you for the info. I build my code in Ubuntu-64bits with simply commands: “clang X64.c”, then run “./a.out” to see the output. If I replace my va_list, va_start, va_arg va_end with __builtin_ms_va_list, __builtin_ms_va_start, __builtin_ms_va_arg, __builtin_ms_va_end, my code will build fail in Ubuntu with below message. Do you suggest I should build it in windows and not in

Hi Richard, I tried latest 3.7.1 release, the clang has same build failure and don’t know __builtin_ms_va_list at all. I compared the llvm trunk with 3.7.1 and find the trunk has a VA commit from Davis which is not included in the 3.7.1 release. So, I guess I need to directly build the latest trunk instead of the 3.7.1 release. (why 3.7.1 release doesn’t include this patch?) commit

Hello, I'm enabling clang LTO to improve code size of Uefi standard (http://www.uefi.org/) firmware (https://github.com/tianocore/edk2), which is mostly C code. My project is in https://github.com/shijunjing/edk2 branch llvm : https://github.com/shijunjing/edk2/tree/llvm. I find my most firmware modules work well after enable LTO, but some X64 modules will not run (e.g. hang with CPU

Hello everyone, I made a quick patch to clang/llvm to introduce an "apple_abi" function attribute (https://github.com/aguinet/llvm-project/commit/c4905ded3afb3182435df30e527955031cb0d098), to be able to compile functions for the Apple ARM64 ABI when targeting other ARM64 OSes (e.g. Linux). This can be seen as the Apple version of the already existing "ms_abi" attribute. In

Hi, I'm sending this discussion to both wine-devel and llvm-dev, to try to keep the discussion open for both sides, to try to find a workable compromise. This was preliminarily discussed on llvm-dev already a few weeks ago. One of the major unresolved issues with Wine for AArch64 is how to handle the platform specific register x18. (https://bugs.winehq.org/show_bug.cgi?id=38780) As

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009,

Hi Umesh, Thank you for the suggestion. I can use the "Brute force method " to narrow down the LTO wrong instructions here and there, but I still don't know why these wrong instructions are generated, and how to let Clang LTO don't generate those wrong instructions. I suspect the wrong code is caused by some LTO wrong optimization pass, so I hope to disable all optimizations in

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

Thank you so much. That helped alot. Fami On Wed, Nov 4, 2015 at 9:40 AM, John Criswell <jtcriswel at gmail.com> wrote: > On 11/3/15 7:54 PM, fateme Hoseini wrote: > > Dear John, > Thank you so much for your help. I looked at those documents. Could you > kindly answer the following questions: > > Does it mean that I have to make my own backend target in order to write

Hi, When using Wine to run Windows ARM64 executables on Linux, there's one major ABI incompatibility between the two; Windows treats the x18 register as the reserved platform register, while it is free to be clobbered anywhere in code on Linux. The Wine code sets up this register before passing control over to the Windows executable code, but whenever the Windows code calls a function

Hi, So, I run my pass in X86 target with llc command and it printed out "hello****". Now I am trying to do the same pass for ARM target. So I did exactly what I did for X86 as mentioned in my previous posts. When I run the following command: llc -march=arm test.ll -o test nothing prints out. I did the same for MIPS target too and I got no result. Can anyone tell me what I'm doing

Yes, I have done exactly the same. The wawanalyzer is the same. I changed ARM.h and ARMTargetMachine.cpp in the tager/arm folder. then I make tool/llc and lib folder. On Tue, Nov 17, 2015 at 10:55 AM, John Criswell <jtcriswel at gmail.com> wrote: > On 11/17/15 12:16 AM, fateme Hoseini via llvm-dev wrote: > > Hi, > So, I run my pass in X86 target with llc command and it printed

The Wine maintenance release 3.0.3 is now available. What's new in this release (see below for details): - Various bug fixes The source is available from the following locations: https://dl.winehq.org/wine/source/3.0/wine-3.0.3.tar.xz http://mirrors.ibiblio.org/wine/source/3.0/wine-3.0.3.tar.xz Binary packages for various distributions will be available from:

On 31 May 2016 at 01:08, Shi, Steven <steven.shi at intel.com> wrote: > Hi Mehdi, > What's the default code model for x86_64 Mac OS X App? Andrew showed me some example code of Mac OS X App as below, which looks to use the small code model but can run at >4GB high address. Small, but PIC. > For example if you read a global like this the compiler will generate this code.

> On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com> wrote: > > (And I doubt the GNU linker supports LTO with LLVM). > [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070 <https://sourceware.org/bugzilla/show_bug.cgi?id=20070>. The new GNU ld linker works well with

Hi everyone, I am a new commer and I 'm tying to use LLVM to cross compile a code. I want to cross compile to MIPS and the host is the default x86. The more I read the document the more confused I get. I see documents on cross-compiling to ARM. But some install some gcc packages, while some use clang. I don't know where to start and how to do it. Is this just enough to run a command line

Hi Steven, > On May 29, 2016, at 11:28 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? I wrote it on trunk, but I expect it to be fairly easy to port on 3.8. This is really just quickly plumbing an option on the TargetMachine creation. --

Hi Mehdi, Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Monday, May 30, 2016 2:13 PM To: Shi, Steven <steven.shi at intel.com> Cc: Umesh Kalappa <umesh.kalappa0 at

> On May 29, 2016, at 5:10 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > GCC LTO seems support large code model in my side as below, if the code model is linker specific, does the GCC LTO use a special linker which is different from the one in GNU Binutils? I don't know anything about GCC. (And I doubt the GNU linker supports LTO with LLVM). > I’m a

Hello. I seem to be having the same problem that Paul had in the thread titled "[Rd] R 2.15.2 make check failure on 32-bit --with-blas="-lgoto2"" from October of last year <https://stat.ethz.ch/pipermail/r-devel/2012-October/065103.html> Unfortunately, that thread ended without an answer to his last question. Briefly, I am trying to compile an Rblas for Windows NT 32bit