similar to: [LLVMdev] x86_stdcallcc and extra name mangling on Windows

I think so. There have been other reports lately related to this being wrong. http://llvm.org/bugs/show_bug.cgi?id=14410 CC'ing Timur since he might know more about this. On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at klickverbot.at>wrote: > On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: > >> My question: Is there an easy way

On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: >> My question: Is there an easy way of disabling the name-mangling part >> but keep the rest of the CC that I missed? > if you use "\1" + "usual name", it will disable name mangling if you are > lucky. A leading \1 is LLVM's way of saying: leave this name alone! Seems like

The patch looks incorrect. The code just needs to handle \1 properly and clang extended to add explicit \1 to the names which does not require mangling. I do not think that moving whole mangling to clang is a good idea, because then everyone who uses LLVM to call WinApi functions will need to mangle by hands. On Wed, Feb 20, 2013 at 11:25 PM, Timur Iskhodzhanov <timurrrr at google.com>

I don't remember anything other that what I've written in the bug João has mentioned. Probably something like this patch http://llvm.org/bugs/show_bug.cgi?id=14410#c6 ? 2013/2/20 João Matos <ripzonetriton at gmail.com>: > I think so. There have been other reports lately related to this being > wrong. > > http://llvm.org/bugs/show_bug.cgi?id=14410 > > CC'ing

Anton, what do you think of David's patch with this test case? OK to commit that? On Wed, Feb 20, 2013 at 12:43 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. > > I do not think that moving whole

2013/2/21 Anton Korobeynikov <anton at korobeynikov.info>: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. I think clang already adds \01 to __stdcall names, so only the LLVM change is remaining. > I do not think that moving whole mangling to clang is a good idea, >

Hi! I like to submit some updates to the LLVM website regarding the LDC compiler. All links are currently out-of-date. The following pages need updates: On page http://www.llvm.org/Users.html, please replace the existing entry "LLVM D Compiler" in section "Open Source Projects" with: <tr> <td><a href="http://wiki.dlang.org/LDC/">

Can you send a patch? On 2 December 2013 06:44, Kai Nacke <kai at redstar.de> wrote: > Hi! > > I like to submit some updates to the LLVM website regarding the LDC > compiler. All links are currently out-of-date. The following pages need > updates: > > On page http://www.llvm.org/Users.html, please replace the existing entry > "LLVM D Compiler" in section

Hi Rafael, is there a repository with the static pages or should I simply produce a diff between the 2 versions? Regards, Kai On 03.12.2013 14:30, Rafael Espíndola wrote: > Can you send a patch? > > On 2 December 2013 06:44, Kai Nacke <kai at redstar.de> wrote: >> Hi! >> >> I like to submit some updates to the LLVM website regarding the LDC >> compiler.

On 03.12.2013 14:30, Rafael Espíndola wrote: > Can you send a patch? Hi Rafael, the patch is attached. @Mikael, Tim Thanks for the help. I really needed only the link to the repo. Regards, Kai > > On 2 December 2013 06:44, Kai Nacke <kai at redstar.de> wrote: >> Hi! >> >> I like to submit some updates to the LLVM website regarding the LDC >> compiler. All

You need to get the LLVM Sphinx docs using SVN or Git. If you want it, I can do the changes for you since I have already everything in place. -- Mikael 2013/12/3 Kai Nacke <kai at redstar.de> > Hi Rafael, > > is there a repository with the static pages or should I simply produce a > diff between the 2 versions? > > Regards, > Kai > > On 03.12.2013 14:30,

Hi everybody. I'm having (yet) another look at trying to get naked functions from D (1) working in our LLVM D Compiler - LDC (2). I have this test case: /// D CODE /// extern(C) int printf(char*, ...); ulong retval() { asm { naked; mov EAX, 0xff; mov EDX, 0xaa; ret; } } ulong retval2() { return (cast(ulong)0xaa << 32) | 0xff; } void main() {

Hi, I'm trying to run the following module in lli on LLVM 2.6, Windows/MSVS 2008, 32 bits memory model: --- declare x86_stdcallcc i8* @GetStdHandle(i32) define i32 @main() { %handle = call i8* @GetStdHandle(i32 -11) ret i32 0 } --- (This small modules that just retrieve the handle to stdout using WIN32 API). I'm converting it to bytecode using: llvm-as.exe -f

Hi Russel, I never tried to build LLVM with nmake. With msbuild it works without problems. You can find a short desription here: http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC, section Build LLVM. Regards Kai On 24.08.2013 21:15, Russell Wallace wrote: > I'm trying to build LLVM 3.3 using cmake/nmake, Microsoft C++ 2012, on a > 64-bit Windows 7 system. I

Hello, In my LLVM frontend (CLR/MSIL), I am currently using first-class aggregates to represent loaded value types on the "CLR stack". However, I noticed that when calling external method taking those aggregate by value, they were not passed as I expected: %COLORREF = type { i8, i8, i8, i8 } declare i32 @SetLayeredWindowAttributes(i8*, %COLORREF, i8, i32) I call this function with

I'm writing a front end for an existing interpreted language with slightly odd semantics for primitive values. Similar to the values in a database table, any value could be null, even for non-pointer types. For example a boolean variable could be true, false, or null. To model this behaviour, I'm passing an {i1, [type]} around for every numeric type. And using insertvalue / extractvalue

The following C test program was compiled using LLVM with -O3 option and MSVC with /O2. The MSVC one is about 600 times faster than the one compiled with the LLVM. We can see that the for loop in MSVC assembler is solved in the optimization pass more efficiently than that in LLVM. Is there an way to get a optimization result in LLVM like that of the MSVC? Manoel Teixeira #include

Hi Giorgio, here is another description how to compile LLVM on Windows: http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC Maybe this is helpful. I created this for Windows 7 but I also repeated it successfully on Windows 8. Regards Kai On 22.07.2013 22:51, Giorgio Franceschetti wrote: > Hi all, > yes, I do not know python and I installed it only for being able to

Hey Jeremy, (putting the discussion back to the list.) 2013/12/8 Jeremy Lakeman <Jeremy.Lakeman at gmail.com>: > If I run your demo exe it crashes, if I re-link the dll with VS 2010 it > errors gracefully; > > runtime error R6030 > - CRT not initialized > > putchar is a c runtime function. > I'm betting that your exe doesn't initialise the runtime library?

Hi LLVM folks, To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able to take the address of an outgoing call argument slot. This is http://llvm.org/PR5064 . Problem ------- On Windows, C structs are pushed right onto the stack in line with the other arguments. In LLVM, we use byval to model this, and it works for C structs. However, C++ records are also passed this