similar to: [LLVMdev] Last GC infrastructure patch

I tried building LLVM 2.1 with no real target CPU backends enabled, just the C backend, by hacking the configure script slightly: --- /home/foad/llvm/llvm-2.1/configure 2007-09-17 22:37:52.000000000 +0100 +++ configure 2007-12-13 10:29:41.000000000 +0000 @@ -4762,7 +4762,7 @@ done ;; esac -TARGETS_TO_BUILD="CBackend MSIL $TARGETS_TO_BUILD"

Hi all! I gave a shot at compiling core llvm with a Solaris 9 machine. The compiler is FSF gcc 3.4.6. I am building trunk in the release version. So far I did not run tests (no dejagnu installed). Here are my findings: 0) Configuring. I had to suppress the solaris tools by: env AR=/opt/gnu/bin/ar NM=/opt/gnu/bin/nm RANLIB=/opt/gnu/bin/ranlib STRIP=/opt/gnu/bin/strip ../llvm/configure

With the TableGen problem circumvented the build proceeds quite well up until: llvm[2]: Linking Debug executable llc /home/neale/LLVM/llvm/tools/llc/Debug/llc.o: In function `ForceCodegenLinking': /home/neale/LLVM/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:45: undefined reference to `llvm::createBURRListDAGScheduler(llvm::SelectionDAGISel*, bool)'

Hi I'm using a GC that's pretty similar to the OCaml one. It records stack locations using llvm.gcroot, and dumps out a frametable describing the live stack offsets so that the GC runtime can walk them as required. I'm on 2.3, not svn head. I'm having some trouble with pointers being cached in registers across function calls (at least x86 backend, haven't tried others yet).

I ran with VERBOSE=1 and see: g++ -I/home/neale/LLVM/llvm/include -I/home/neale/LLVM/llvm/tools/llc -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fno-exceptions -fPIC -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -g -Wl,-R -Wl,/home/neale/LLVM/llvm/Debug/bin -Wl,-export-dynamic

Hi, Artur > // CallSites have equal signatures > bool MSILWriter::cmpCallSite(CallSite A, CallSite B) { >   return (getCallSiteFType(A)==getCallSiteFType(B) && >     A.getAttributes()==B.getAttributes()); > } As it is impossible to honour argument attributes in MSIL I don't see why you should compare attributes. You seems to have the same MSIL call signature for calls

Hi Anton > > > The interesting for me part of the CallInst is printf(i8* noalias %0, i32 > > 123). > > I was diging in doxygen documentation but I really can't see the easy way > to > > compare those instructions and again finish with reinvented (but working) > > wheel ;). > Ah, sorry. I missed that you're doing variadic calls, not casting >

Hi Scott, On Sep 22, 2008, at 20:59, Scott Graham wrote: > I'm using a GC that's pretty similar to the OCaml one. It records > stack locations using llvm.gcroot, and dumps out a frametable > describing the live stack offsets so that the GC runtime can walk > them as required. I'm on 2.3, not svn head. > > I'm having some trouble with pointers being cached

Hi, I am trying to use llvm to translate ftp.c(a file of wget-1.11.2.tar.bz2 ) to msil. But it shows errors like: [dayin at localhost src]$ llvm-gcc -emit-llvm ftp.c -c -o ftp.bc [dayin at localhost src]$ llc ftp.bc -march=msil -o ftp.s Intrinsic ID = 32 llc: /home/dayin/llvm/llvm-2.2/lib/Target/MSIL/MSILWriter.cpp:802: void <unnamed>::MSILWriter::printIntrinsicCall(const

I'm seeing a lot of build failures recently: (1) on x86-64 linux, gcc 4.1.2: ... llvm[3]: Compiling Hello.cpp for Debug build (PIC) llvm[3]: Linking Debug Loadable Module LLVMHello.so /usr/bin/ld: .../llvm/build/llvm/lib/Transforms/Hello/Debug/.libs/Hello.o: relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>, std::allocator<char>

Hello EveryOne, I am building customized tools for ARM using a crosscomplier. I am currently building a tool similar to lli but it only jits code. I enabled jit when I was configuring LLVM. On linking my code with help from llvm-config to the libraries I get this error: Can't exec "which": No such file or directory at llvm2/bin/llvm-config line 69. Use of uninitialized value in

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

Based on cmake/modules/LLVMLibDeps.cmake, I produced a graphviz dot file and then manually removed components and edges until the graph was small enough to be presentable. I don't know if I can actually use LLVM due to its humongousness, but I hope the graph will be helpful to others attempting to comprehend LLVM. PNG attached; dot file follows. digraph G { ipo

NetBSD does not have alloca.h, so CBackend.cpp need to handle NetBSD in the same way as FreeBSD and OpenBSD, as in the attached patch. /Krister -------------- next part -------------- Index: CBackend.cpp =================================================================== --- CBackend.cpp (revision 45865) +++ CBackend.cpp (working copy) @@ -1323,7 +1323,7 @@ static void

> I'm periodically updating my local version of the LLVM, and, when I did it > today, I couldn't use the llc with -march=c. Looking for the CBackend files, > I realized that they were removed from the LLVM folder. I actually don't > remember reading about a drop of this capability in any of the devlist > messages, so I was wondering if this removal could be only

Hello, llvmdev! I'm using LLVM on OpenBSD. This project proactively advocates usage of 'secure' C apis, especially related to memory bounds checking. Thus using functions like sprintf/strcpy/etc usually spits out a linker warning in base toolchain like this one: /home/proger/dev/llvm/Debug+Asserts/lib/libclangFrontend.a(DocumentXML.o) (.text+0xc65): In function

Hi, is there a problem with loadable backends and some analysis passes? An example: If I put the C backend in my project directory, compile a library form the code, and try to load it into lli I get the following message: ------------------------------------------------------- lli -load /path/CBackend.dylib Error opening '/path/CBackend.dylib': dlopen(/path/CBackend.dylib, 1):

U-boot for the arndale board splits the memory in 8 contiguous banks and rewrites the memory node. So most of the memory is lost. As the frametable is only able to handle contiguous memory, use the first contiguous banks and warn if some of the memory banks are not used. Signed-off-by: Julien Grall <julien.grall@linaro.org> --- xen/arch/arm/setup.c | 23 +++++++++++++++++------ 1 file

Hi Dmitry, Where were you expecting notice to have been given? If I recall correctly, the obsolescence of the C backend was mentioned many times on this mailing list, and as Owen notes, in the release notes since 2.8. I'm not trying to be snarky. You were obviously genuinely surprised by its removal, and that makes me wonder if where the core open source devs are expecting people to look for

This allows the use of shadow stack from the llvm-c API. I am not sure this is the place to insert the include, though. Index: include/llvm-c/ExecutionEngine.h =================================================================== --- include/llvm-c/ExecutionEngine.h (revision 56175) +++ include/llvm-c/ExecutionEngine.h (working copy) @@ -24,6 +24,7 @@ #ifdef __cplusplus extern "C" {