similar to: [LLVMdev] Minor problem in today's LLVM/CLANG head

Here you go: http://www.cornwarning.com/xfer/jccolor.o (from the jpeg library...) jccolor.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags MH_MAGIC_64 X86_64 ALL 0x00 OBJECT 4 432 SUBSECTIONS_VIA_SYMBOLS Load command 0 cmd LC_SEGMENT_64 cmdsize 312 segname vmaddr 0x0000000000000000 vmsize 0x0000000000000900

This is compiling the Trunk revision from last Friday: reference out of range from _llvm_regerror (1000437F0) in ../../lib/libLLVMSupport.a(regerror.c.o) to cstring=0 (0) in ../../lib/libLLVMSupport.a(regerror.c.o) ld: rel32 out of range in _llvm_regerror from ../../lib/libLLVMSupport.a(regerror.c.o) clang-3: error: linker command failed with exit code 1 (use -v to see invocation) OS X 10.6,

Hi, I'm having a hard time linking the LLVM/clang libraries in Xcode. I've been fighting this for a couple of days now, and decided to make a fresh checkout and a super-simple demo project to try and isolate the problem, but even so I'm getting undefined symbol errors in the linker for the static libraries LLVM is producing. This is really baffling, so probably I'm

Logged this: http://llvm.org/bugs/show_bug.cgi?id=13353 I might respectfully suggest that building ITK (like building Boost) is an excellent torture test for CLANG. Up until last week the SVN head worked fine, now it doesn't. Later today I'll try building ITK again with CLang SVN head and see if someone fixed this...

Hi Matthijs, Thanks for giving some code so we can discuss this in more concrete detail. In terms of the information we need, I think you have it right. We just need a description of how the different address spaces relate and I don't see much of an issue with how you implemented to InstructionCombining. As you also mentioned, I don't like that we pass a reference to

Hi all, I just found that TargetData also contains a similar assert, and that I forgot a "return" in my previous patch. Here's an updated patch, which allows to use any integer to index a CompositeType. It seems this enables GEP to work with any integer value as well, I tested indexing a struct with a i16 an i64 (also through llc). This should still be adressed somewhere, unless we

This needs to be applied as well. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] GetElementPtr for packed types and VS build > Date: Wed, 01 Dec 2004 15:10:49 +0100 > > As I was working with packed types it became apparent that I sometimes >

"Anton Korobeynikov" <asl at math.spbu.ru> writes: >> at all, it would be great if you reflect your changes on the file list >> inside the corresponding CMakeLists.txt when you add, remove or rename >> a .cpp file. > > Isn't is possible for cmake just to glob everything in the corresponding > directory? Yes, but then the build would not notice a

Óscar Fuentes wrote: > "Anton Korobeynikov" <asl at math.spbu.ru> writes: > > >>> at all, it would be great if you reflect your changes on the file list >>> inside the corresponding CMakeLists.txt when you add, remove or rename >>> a .cpp file. >>> >> Isn't is possible for cmake just to glob everything in the

Hi all, > If I read the standard correctly, the properties of these address spaces can > be fully captured by defining the relationship between every pair of address > spaces (disjoint, identical, subset/superset). > > I think it would make sense to make these relationships backend/platform > specific, but for clang and the optimization passes to properly work with > address

On Sat, Apr 16, 2011 at 5:27 PM, tarun agrawal <tarun at cse.iitb.ac.in> wrote: > I am using llvm-2.6  and the ConstProp.cpp file is > http://llvm.org/docs/doxygen/html/ConstantProp_8cpp_source.html > > and the exact error message is: > > llvm[0]: Compiling ConstantProp.cpp for Release build  (PIC) >

Hi Kent, My guess is you are getting some new bit of info in your object files and your ranlib(1) is older and doesn't know about it. If you can send me the .o file or the output of otool(1) with the -hlv options on your object file I can take a look. Kev P.S. you can find out the version of ranlib(1) you have by running strings(1) on it and grep(1)'ing for the string

I am using llvm-2.6 and the ConstProp.cpp file is http://llvm.org/docs/doxygen/html/ConstantProp_8cpp_source.html and the exact error message is: llvm[0]: Compiling ConstantProp.cpp for Release build (PIC) /home/tarun/Desktop/compiler/LLVM/llvm-2.6/include/llvm/Analysis/ConstantFolding.h: In member function ‘virtual bool<unnamed>::ConstantPropagation::runOnFunction(llvm::Function&)’:

Hi! I'm porting my own projects to CMake (seems very cool) and I want to import LLVM as external libraries. To simplify this CMake supports an export feature that can export an LLVM.cmake file that lists all libraries of LLVM. With this I could simplify the use of LLVM in my own CMake project. For this the following cmake files of LLVM have to be extended (patches are provided at the end of

Ran into this today -- rebuilt the SVN Trunk for this morning of LLVM+CLANG. Now every time my builds try and make a library from .o files, ranlib complains about 'malformed object' files. This is with OS X 10.7.4, and the binary tools from XCode 4.4.1 ld -v @(#)PROGRAM:ld PROJECT:ld64-127.2 llvm version 3.0svn, from Apple Clang 3.0 (build 211.12) ranlib doesn't tell you what

Hi all, any comments about this patch? I'd like to get it out of my working copy :-) Gr. Matthijs > Index: lib/VMCore/Type.cpp > =================================================================== > --- lib/VMCore/Type.cpp (revision 53136) > +++ lib/VMCore/Type.cpp (working copy) > @@ -394,9 +394,8 @@ > > bool StructType::indexValid(const Value *V) const { >

On Mon, Mar 15, 2010 at 11:51:47AM +0000, Tim Northover wrote: > Hello, > > I noticed a bit of a gap in the current code for unions: a > ConstantUnion cannot be written out to .ll. I've been continuing plugging gaps as I find them, which might not be the best way to solve this problem, but it has produced something that seems to do roughly what I expect. I've split it into

I don't think this is right. According to llvm documentation: The index types specified for the 'getelementptr' instruction depend on the pointer type that is being indexed into. Pointer and array types can use a 32-bit or 64-bit integer type but the value will always be sign extended to 64-bits. Structure and packed structure types require i32 constants. Evan On Jul 10,

On Mon, Feb 8, 2016 at 12:45 PM, Hans Wennborg <hans at chromium.org> wrote: > Chris Bieneman is probably your best bet, and maybe also Dan Liew. > Hans, My current, and hopefully final, revision of the proposed patch is simplified and reworked to solve the problem entirely from cmake without touching the the llvm-build python scripts. Basically, the new fix for avoiding the

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > >>>> Isn't is possible for cmake just to glob everything in the corresponding >>>> directory? >>>> >>>> >>> Yes, but then the build would not notice a change on the file >>> structure. You'll need to explicitly invoke