similar to: [LLVMdev] Current LLVM/CLANG build failure.

Hello, I'm starting to play with LLVM today and I've trouble compiling it. I'm working under Windows Vista, with the gcc from Cygwin: gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Is LLVM supposed to work with this version of GCC (probably using the -mno-cygwin option to get a Mingw-like behavior)? The LLVM source tree is from the current SVN trunk. Compilation

In any case, it seems that GCC 3.4.4 may be in hot water even if you did get it to compile: http://llvm.org/docs/GettingStarted.html#brokengcc -- Christopher Lamb On Aug 6, 2007, at 9:48 AM, Alain Frisch wrote: > Hello, > > I'm starting to play with LLVM today and I've trouble compiling it. > I'm > working under Windows Vista, with the gcc from Cygwin: > >

Function.cpp:167: error: call of overloaded `AddInteger(uint32_t&)' is ambiguous /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:151: note: candidates are: void llv m::FoldingSetImpl::NodeID::AddInteger(int) /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:152: note: void llvm::FoldingSetIm pl::NodeID::AddInteger(unsigned int) /home/Seb/llvm/include/llvm/ADT/FoldingSet.h:153: note: void

Hello I'm trying to link my project with llvm 3.2 libraries. I haven't touched the project for some months. Previously I used to link to an svn build of llvm 3.1 and everything worked fine. I've compiled llvm with ./configure --enable-libcpp --enable-cxx11 Currently I'm only using StringRef, SmallVector and FoldingSet, so I only link libLLVMSupport and libLLVMCore. Are they

Nicola Gigante <nicola.gigante at gmail.com> writes: > The error I get is the following: > Undefined symbols for architecture x86_64: > "typeinfo for llvm::FoldingSetImpl", referenced from: > typeinfo for llvm::FoldingSet<Type> in Program.o > ld: symbol(s) not found for architecture x86_64 > > Looking at the error the question is: is llvm built

Il giorno 18/mar/2013, alle ore 15:14, Óscar Fuentes <ofv at wanadoo.es> ha scritto: > Nicola Gigante <nicola.gigante at gmail.com> writes: > >> The error I get is the following: >> Undefined symbols for architecture x86_64: >> "typeinfo for llvm::FoldingSetImpl", referenced from: >> typeinfo for llvm::FoldingSet<Type> in Program.o

Nicola Gigante <nicola.gigante at gmail.com> writes: > Il giorno 18/mar/2013, alle ore 15:14, Óscar Fuentes <ofv at wanadoo.es> ha scritto: > >> Nicola Gigante <nicola.gigante at gmail.com> writes: >> >>> The error I get is the following: >>> Undefined symbols for architecture x86_64: >>> "typeinfo for

Hi Reid, I've been working on the outlining code and have a prototype that produces what I want for a simple case. Now I'm thinking about the heuristics for recognizing the various logical pieces for C++ exception handling code and removing them once they’ve been cloned. I've been working from various comments you've made earlier in this thread, and I'd like to run something

I am reading the code for exit block transformation in loop simplify. I do not fully understand how exit blocks with out-of-loop dominators are transformed. In SplitLandingPadPredecessors, all the in-the-loop predecessors of the exits block are grouped and given to the .loopexit basic block and the out-of-loop predecessors are grouped and given to the .nonloopexit basic block. the .loopexit

If we added unwind target to every potentially throwing instruction (loads, stores, all binary operations), wouldn't all such instructions have to become BB terminators? I'd expect that CFG would then end up consisting mostly of single-instruction BBs. This can't be good for compilation performance and optimizations... Another vague idea: what if lifetime.start() returned some kind

I’m not sure I understand what you are suggesting in terms of how this should be handled. I agree that the cleanup code is unlikely to be complex, but obviously we still need some way to handle any cases that unlikely but possible. I hadn’t even thought about what might be in a __finally block. I was thinking about destructors being inlined. Obviously that puts a practical limit on what will

I should also implement NodeEquals() method. Please ignore this message. ------------------ Original ------------------ From: "Xu Zhongxing"<xuzhongxing at foxmail.com>; Date: Mon, Sep 26, 2011 10:11 PM To: "llvmdev"<llvmdev at cs.uiuc.edu>; Subject: [LLVMdev] [LLVMDev] The ComputeHash algorithm in FoldingSet isunsafe I use FoldingSet to save some data

Rubin, Norman wrote: > I'm trying to install llvm on my windows development box and hit a > problem > I'm using cygwin > cygwin% gcc --version > gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > I downloaded both the top of tree via svn > I ran ./configure > make > > make[1]: Entering directory `/cygdrive/c/llvm/lib/Support' >

I'm trying to install llvm on my windows development box and hit a problem I'm using cygwin cygwin% gcc --version gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) I downloaded both the top of tree via svn I ran ./configure make make[1]: Entering directory `/cygdrive/c/llvm/lib/Support' llvm[1]: Compiling APFloat.cpp for Debug build llvm[1]: Compiling APInt.cpp

I used to be able to build LLVM (from source) under Cygwin for llvm-2.2 and previous releases, but can't continue the trend since the release of LLVM 2.3. I have tried a wide variety of gcc compilers (gcc 3.4.4, 4.1.2, 4.2.4 and 4.3.2) on cygwin, they all fail at the same location: C:\cygwin\home\czhao\ResearchTools\LLVM\2.3\obj2.3>make make[1]: Entering directory

I use FoldingSet to save some data structures. And I found somehow it always abandon a new node. I tracked the bug into the ComputeHash() function of FoldingSet. It computes the SAME hash value for these two 32-bit unsigned integer sequences: size: 17

tl;dr: I think we have too many different set classes. They have incompatible APIs and surprising behavior. I think we can reduce their number substantially. Dear all, The following is a subset of the set classes we have in ADT: * DenseSet * SmallDenseSet (https://reviews.llvm.org/D25628) * SetVector * SmallSetVector * SmallSet * SmallPtrSet * StringSet * FoldingSet *

On Feb 10, 2010, at 4:49 PM, Gregory Petrosyan wrote: >> >> These numbers are so noisy, that they aren't particularly useful. >> Could you try instrumenting foldingset to keep track track of the # >> collisions and # hash table resizes and compare those? They should >> be much more stable and still correlate directly to performance. > > OK, now with real

On Mon, Feb 08, 2010 at 10:31:23AM -0800, Chris Lattner wrote: > On Feb 7, 2010, at 1:03 PM, Gregory Petrosyan wrote: > > >On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: > >>While I've not reviewed the patch in too much detail, it looks > >>promising. Can you run some end-to-end benchmarks to make sure that > >>cache pressure in the

Thanks, Reid. These are good points. So I guess that does take us back to something more like my original proposal. I like your suggestion of having some kind of “eh.actions” intrinsic to represent the outlining rather than the extension to landingpad that I had proposed. I was just working on something like that in conjunction with my second alternative idea. What I’d really like is to have