similar to: [LLVMdev] llvm-gcc x86-64 build problem

Hello, Rafael > With this patch I was able to bootstrap gcc in linux x86-64 with > shared libraries enabled :-) Awesome! But... -ENOPATCH :( -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

How can a frontend tell LLVM to put a function argument on stack/register/etc? On Thu, Oct 4, 2012 at 5:08 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Ah, got it. >> Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. > No, we should not. It should be properly expanded in frontend. > > -- > With best regards, Anton Korobeynikov >

> Ah, got it. > Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. No, we should not. It should be properly expanded in frontend. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

hi, So... I followed the following steps in order to compile the llvm-gcc frontend. The single problem is that mentioned in the previous message: llvm-gcc HelloWorld.c /home/LLVM/install/lib/gcc/arm-elf/4.2.1/../../../../arm-elf/bin/ld: this linker was not configured to use sysroots collect2: ld returned 1 exit status 1. I have compiled the binutils for the arm-none-eabi target. Options:

my g++-cross was configured with following parameters: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv7fl-montavista-linux-gnueabi --enable-cross --with-sysroot=/home/arm_v7_vfp_le/target/ --with-build-sysroot=/home/arm_v7_vfp_le/target/ --enable-shared --enable-languages=c,c++ --with-as=/home/arm_v7_vfp_le/bin/arm_v7_vfp_le-as

> ../llvm-gcc-4.2-2.7.source/configure > --enable-llvm=/home/anatolyy/qctp406/pakman/depot/users/anatolyy/proto/crosscompiler/llvm-2.7 > --enable-multilib --enable-target-optspace --enable-interwork > --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ > --target=arm-elf This means that the compiler is built for ARMv4 which is not pretty good supported. Try to switch

2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> How can having an MSVC compatible compiler be to the detriment of clang and >> llvm? No one is trying to break mingw here, merely add support for something > Just to make stuff clear: I just wanted proper naming which will be > non-confusing. Right now we have: > - isTargetWindows() which really means

Hello, Reid. You wrote Saturday, June 3, 2006, 10:25:13 PM: RS> I don't think anyone has successfully built llvm-gcc4 on Linux yet. I've RS> tried and failed. There was some message in this list saying, that bootstrap was succeeded on linux. -- With best regards, Anton mailto:asl at math.spbu.ru Saturday, June 3, 2006 10:36:47 PM Faculty of Mathematics

2013/3/27 Anton Korobeynikov <asl at math.spbu.ru>: > Hi Eric, > >> From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs > No. They are using Windows Platform ABI for almost everything (e.g. > calling API, C runtime, etc.). At least mingw does. The differences > are exactly in unspecified area (e.g. passing / returning structs by >

What if it's already broken? 2013/3/28 Anton Korobeynikov <asl at math.spbu.ru>: >> A more specific question is - if I fix some Clang i686-pc-win32 >> compatibility issue with MSVC for some language feature (e.g. >> returning a struct), >> should I make sure Clang i686-pc-mingw32 behavior is not changed by my >> patches (a) >> or should I make sure

> How can having an MSVC compatible compiler be to the detriment of clang and > llvm? No one is trying to break mingw here, merely add support for something Just to make stuff clear: I just wanted proper naming which will be non-confusing. Right now we have: - isTargetWindows() which really means "msvc-compabile" - isTargetWin32() which means "everything on windows", so

Hello, llvm-dev. thank you for your interest in my question. Currently, I compiled simple c source code (hello.c) in lunux and windows, and I tried to simple test . first case: hello.bc (compiled with "-emit-llvm" on windows) -> lli.exe(linux). second case: hello.bc (compiled with "-emit-llvm" on linux) -> lli.exe(windows). second case return good result. but First case

Hi, Any help would b appreicated. This is one of my critical assignment. Thanks Sanjeev On Thu, Jun 17, 2010 at 7:03 PM, Sanjeev chugh <sanjuchugh at gmail.com> wrote: > Hello, > > Thanks for the reply. We have an product whose one part has lot of > algorithms doing some graphics work. Our intention was to figure out if > there can be any performance gain if we use llvm

Hello, Prakash > I tried with --enable-languages=java and it still fails with the same > error: gcj is not supported by llvm-gcc (and even with build w/o LLVM, as you're doing) -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

> A more specific question is - if I fix some Clang i686-pc-win32 > compatibility issue with MSVC for some language feature (e.g. > returning a struct), > should I make sure Clang i686-pc-mingw32 behavior is not changed by my > patches (a) > or should I make sure that Clang i686-pc-mingw32 generates > MSVC-compatible ABI for the same feature (b) > ? You need to make sure

Hello Timur, > I'd like to ask for advice: > a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? > [I suppose no] no > > b) Should I be altering CC_X86_32_ThisCall > OR should I introduce CC_X86_Win32_ThisCall instead? > [Answer not clear to me - is there any platform besides Windows > that uses thiscall?] no It seems for me

> Sounds fine to me. I just wanted some convenient and consistent naming. > I think it conflicts a bit with the triples (-win32 currently means > msvc I think), Right. But this is again a historical (and LLVM-specific) artifact, because I doubt anyone uses such triplet outside to mean msvc compatibility. > but that'll probably be ok ultimately - internal function names are easy to

Hello, Thanks for the reply. We have an product whose one part has lot of algorithms doing some graphics work. Our intention was to figure out if there can be any performance gain if we use llvm instead of native ARM. This is for ARM target. Earlier, I have built this component using llvm and tested it on x86. Performance was 4x as compared to native gcc. Then I built llvm for ARM and tested

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and