similar to: [LLVMdev] 1.5 llc hangs w/ GCC 4.0.1?

Andreas, This has been seen before and I believe fixed in the CVS version. See http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=578 for details. The problem was fixed June 6 by Nate. The patches are included in the bug report. You can either apply the patches to your 1.5 sources, use CVS, or downgrade your compiler to 3.4 Reid. Andreas Fredriksson wrote: > Hey guys, > I just moved to the

Hello, The CodeExtractor contains a std::set<BasicBlock*> to keep track of the blocks to extract. Iterators on this set are not deterministic, and so the functions that are generated are not (the order of the inputs/outputs can change). The attached patch uses a SetVector instead. Ok to apply ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F

If you call lld::coff::link twice, the second time gives this backtrace: msvcp140d.dll!00007ffc35830806() Unknown > zig.exe!std::_Debug_pointer<lld::coff::Chunk * __ptr64 const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int _Line) Line 926 C++ zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const *

+Rui and Peter On Wed, Jul 25, 2018 at 8:34 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Here's a fix: > > --- a/lld/COFF/Driver.cpp > +++ b/lld/COFF/Driver.cpp > @@ -72,6 +72,9 @@ bool link(ArrayRef<const char *> Args, bool CanExitEarly, > raw_ostream &Diag) { > exitLld(errorCount() ? 1 : 0); > > freeArena(); > +

Something that might interest you is the SetVector, which as its name implies is both a set and a vector paired together. You get the advantage of doing set-like operations (search) on the set and vector-like operations (iteration, random access) on the vector, but at the cost of paying the price for both data structures when modifying the structure (and double the memory). This seems like it

Hi, Thanks a lot for the help! It seems that the SmallSetVector is the ADT I need (interface-wise). Is more efficient than llvm::UniqueVector? In my use case I have to insert a new element in the structure only if the element is unique. I hardly expect more than 32 elements. Do you think I gain a lot if I use the SmallSetVector instead of using SmallVector + slow searching on every

UniqueVector is an stl map coupled with an stl vector[1], which seems very undesirable for you. As far as SmallVector + slow search, I believe that is precisely what the implementation of SmallSet does until it has to grow, after which it uses an stl set[2]. If you're always staying within your small number, SmallSetVector would be wasteful as the SmallSet would itself also have a SmallVector.

On Fri, Jan 08, 2010 at 05:04:17PM -0800, Chris Lattner wrote: > On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote: > >Hello, > > > >The CodeExtractor contains a std::set<BasicBlock*> to keep track > >of the > >blocks to extract. Iterators on this set are not deterministic, and so > >the functions that are generated are not (the order of the >

On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote: > Hello, > > The CodeExtractor contains a std::set<BasicBlock*> to keep track of > the > blocks to extract. Iterators on this set are not deterministic, and so > the functions that are generated are not (the order of the > inputs/outputs can change). > > The attached patch uses a SetVector instead. Ok to apply ?

On Wed, Jul 12, 2017 at 08:40:18PM +0800, Wei Wang wrote: > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > index 28b0e96..9f27101 100644 > --- a/include/linux/virtio.h > +++ b/include/linux/virtio.h > @@ -57,8 +57,28 @@ int virtqueue_add_sgs(struct virtqueue *vq, > void *data, > gfp_t gfp); > > +/* A desc with this init id is treated

On Wed, Jul 12, 2017 at 08:40:18PM +0800, Wei Wang wrote: > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > index 28b0e96..9f27101 100644 > --- a/include/linux/virtio.h > +++ b/include/linux/virtio.h > @@ -57,8 +57,28 @@ int virtqueue_add_sgs(struct virtqueue *vq, > void *data, > gfp_t gfp); > > +/* A desc with this init id is treated

hi, > Users generally expect a unique set of exit blocks, but don't make any > strong assumption. The worst that can happen is missed optimization or > redundant analysis. In most cases, the loop is in LoopSimplifyForm, so it's > probably not a problem in practice. > > > Another thing I should mention. The iteration order of ExitBlocks is > important. In llvm,

Is it kosher to include vim mode line comments inside of LLVM source files? I would like to do this inside of the MicroBlaze backend to ensure that tabs are expanded into exactly two spaces. I see that right now the following files have these vim mode line comments: include/llvm/ADT/SetVector.h lib/Archive/ArchiveInternals.h lib/Linker/LinkModules.cpp lib/Transforms/IPO/DeadTypeElimination.cpp

Background: I am still working on vectorizing (widening) a whole instruction tree (from the loads to the stores). I have all scalar loads in a SetVector and have created widened version of them (new instructions). What would be very useful to have is the possibility to get to the vector load instruction from the scalar load in constant time. I was thinking to somehow add the vector load

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 *

Andy, So if it is not a feature. then couple questions: First, I also do not see an easy way to restructure work sets in this case - so let's assume std::map is needed here. Then the way I understand it, there are five objects that cause the indeterminism: std::map<const Value *, SUnit *> AliasMemDefs, NonAliasMemDefs; std::map<const Value *, std::vector<SUnit

I have no idea why this code compiled correctly with gcc... m. Index: include/llvm/ADT/SetVector.h =================================================================== RCS file: /var/cvs/llvm/llvm/include/llvm/ADT/SetVector.h,v retrieving revision 1.8 diff -u -r1.8 SetVector.h --- include/llvm/ADT/SetVector.h 11 Sep 2004 20:38:25 -0000 1.8 +++ include/llvm/ADT/SetVector.h 13

On Oct 16, 2012, at 1:43 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Andy, > > This is less of a question but rather a status quo verification… > > We currently have certain indeterminism in MI scheduler DAG construction – it is introduces by the use of std::map/std::set during edge traversal. > Result – a random variation in SUnit edge order

From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm compiles fine; ours is compiled to a Debugging version. llvm-gcc, though, is angry. I get the following error (with path prefixes shortened for convenience) when compiling llvm-gcc: > In file included from

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include