similar to: llvm / clang does not build with new libc++

Displaying 20 results from an estimated 900 matches similar to: "llvm / clang does not build with new libc++"

2012 Aug 09
1
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
Hi Ben, Thanks that helped a lot. The problem seems to be that with the move to C++11 we now have: void std::vector<_Ty>::push_back(std::pair<_Ty1,_Ty2> &&)' and there no conversion operator that can be applied to convert: 'std::pair<_Ty1,_Ty2>' to 'std::pair<_Ty3,_Ty4> && Where: [ _Ty1=void *,
2012 Aug 09
3
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
I'm probably missing something simple here but in: CGDebugInfo.h: std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; but then in CGDebugInfo.cpp: llvm::DIType TC = getTypeOrNull(Ty); void * v = Ty.getAsOpaquePtr(); std::pair<void *, llvm::WeakVH> tmp = std::make_pair(v, TC); if (TC.Verify() && TC.isForwardDecl())
2012 Aug 09
0
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
On 09.08.2012, at 19:43, "Gaster, Benedict" <Benedict.Gaster at amd.com> wrote: > I’m probably missing something simple here but in: > > CGDebugInfo.h: > > std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; > > but then in > > CGDebugInfo.cpp: > > llvm::DIType TC = getTypeOrNull(Ty); > > void * v =
2016 Dec 24
1
failure at link time 3.9.1
As a note, I experimentally attempted to build 391 branch "just llvm + clang" on ubuntu the other day, and got this: [ 90%] Linking CXX executable ../../../../bin/clang ../../../../lib/libclangCodeGen.a(ObjectFilePCHContainerOperations.cpp.o): In function `(anonymous namespace)::PCHContainerGenerator::DebugTypeVisitor::VisitImportDecl(clang::ImportDecl*)':
2013 Nov 15
1
[LLVMdev] DebugInfo: LTO Metadata Size reduction by removing some cycles
>From a thread with Adrian on llvm-commits I looked a little at cases where DwarfCompileUnit's getOrCreateContextDIE's "fallback to return the CU" didn't fire when a CU DIE was required (ie: when the "getDIE" call actually found the CU before the fallback happened) This seems unnecessary, and any case where we do this (where a metadata node has a non-null
2016 Apr 01
0
[cfe-dev] RFC: Up front type information generation in clang and llvm
On Tue, Mar 29, 2016 at 11:50 PM, Eric Christopher via cfe-dev < cfe-dev at lists.llvm.org> wrote: > > > On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul < > Paul_Robinson at playstation.sony.com> wrote: > >> Skipping a serialization and doing something clever about LTO uniquing >> sounds awesome. I'm guessing you achieve this by extracting types out of
2015 Aug 18
3
[RFC PATCH 1/2] [clang]: Add AuxAttr support
This patch adds EmitTypeAuxAttribute() function to CGDebugInfo, which allows other parts of clang issue auxiliary information through an enumeration type in Dwarf information. For example, by calling DI->EmitTypeAuxAttribute(type, "ID", 1234); We can get following information in dwarf: <1><3f>: Abbrev Number: 3 (DW_TAG_structure_type) <40> DW_AT_name
2013 Apr 16
1
[LLVMdev] creating and inserting a function with variable arguments
The code that I have written to get the function type is: const std::vector<Type *> ParamTys; ParamTys.push_back(IntegerType::getInt32Ty(Context)); ParamTys.push_back(IntegerType::getInt32Ty(Context)); ParamTys.push_back(IntegerType::getInt32Ty(Context)); ParamTys.push_back(PointerType::get(Type::getVoidTy(Context), 0)); ParamTys.push_back(PointerType::get(Type::getVoidTy(Context), 0));
2014 Dec 10
2
[LLVMdev] Metadata/Value split has landed
> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the >> C++ side of it. This was a rocky day, but I suppose that's what I get >> for failing to stage the change in smaller pieces. >>
2009 May 15
2
[LLVMdev] Removing std::vector from APIs (was Re: Mutating the elements of a ConstantArray)
On 2009-05-15, at 07:26, David Greene wrote: > On Friday 15 May 2009 05:50, Jay Foad wrote: >> > >>> The one major thing to be aware of is that it isn't safe to use >>> &V[0] when V is an empty std::vector >> >> Oh dear. That's a bit of a flaw in the plan. I suppose the solution >> is to switch to SmallVector whenever this might be a
2014 Oct 18
2
[LLVMdev] Dereferencing NULL pointer in IndVarSimplify.cpp?
Hi, Here is the code in IndVarSimplify.cpp. SmallVector<WeakVH, 16> DeadInsts; while (!DeadInsts.empty()) if (Instruction *Inst = dyn_cast_or_null<Instruction>(&*DeadInsts.pop_back_val())) RecursivelyDeleteTriviallyDeadInstructions(Inst, TLI); Since DeadInsts.pop_back_val() is WeakVH which could hold a NULL pointer, the expression,
2009 Dec 09
1
reshape() makes R run out of memory (PR#14121)
Full_Name: Alexander L. Belikoff Version: 2.8.1 OS: Ubuntu 9.04 (x86_64) Submission from: (NULL) (67.244.71.200) I'm trying to reshape the following data frame: ID DATE1 DATE2 VALUE_TYPE VALUE 'abcd1233' 2009-11-12 2009-12-23 'TYPE1' 123.45 ... VALUE_TYPE is a string and is a factor with only 2 values
2008 Dec 18
0
[LLVMdev] Troubles with clang and llvm libraries and simple Xcode project
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
2014 Dec 11
2
[LLVMdev] Metadata/Value split has landed
On Wed, Dec 10, 2014 at 05:27:45PM -0800, Duncan P. N. Exon Smith wrote: > +zalman at google.com > Hi Duncan, This patch plus another small change fixes the assertion failure for me. With the patch alone, the void* overload of addGarbageObject() was being used by MDNode::getTemporary(), so I had to cast the object as an MDNode*: diff --git a/lib/IR/Metadata.cpp b/lib/IR/Metadata.cpp
2009 Oct 07
2
[LLVMdev] DebugFactory
On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > Here is a patch that does just that. This does not work. I'm getting llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function ‘llvm::DIType clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, llvm::DICompileUnit)’: /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225: error:
2009 Oct 07
0
[LLVMdev] DebugFactory
OK so the problem is that the compiler sees '0' and can't decide whether its an integer or a null pointer of type Constant *. I guess the new functions will have to have slightly different names. On Wed, Oct 7, 2009 at 9:50 AM, Devang Patel <devang.patel at gmail.com> wrote: > On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > > Here is a patch
2014 Dec 10
3
[LLVMdev] Metadata/Value split has landed
> On 2014 Dec 10, at 14:08, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Dec 10, 2014 at 11:21:08AM -0800, Duncan P. N. Exon Smith wrote: >> >>> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: >>> >>> On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >>>> The `Metadata`/`Value`
2014 Dec 11
2
[LLVMdev] Metadata/Value split has landed
I committed: r224058 = 966942da9e68b59c31ce770e7f94c55a63482c6b r224060 = da75f7277e3a129aed8ef8aa4e0d84de40b76fd4 r224061 = f88e4c8e9171045454b2c8e05054c2af8da3fe4f Let me know if somehow you're still hitting the problem. r224061 removes leak detection entirely from `MachineInstr`. There aren't any leaks to be had there, since they're allocated in a custom allocator. They're
2017 Dec 12
2
Extending llvm::iterator_range
Hello, Our llvm::iterator_range is quite minimalist in design, it does not even have an "empty" method. Is that because we want it to work on all iterators (including those dirty OutputIterator)? Maybe we can add a little bit to it? I recently needed: - bool empty() - value_type& font() - value_type& back() - void advance_begin(difference_type n) - void
2016 Jul 31
2
[Release-testers] [3.9 Release] Release Candidate 1 has been tagged
Hi, On the OpenMandriva side, x86_64 passes all checks. We're having some problems with other architectures though (see below): x86_64 succeeded, packages are here: https://abf.openmandriva.org/build_lists/76792 i586 fails to build, but this seems to be an issue with 3.8.1 (which we're using to build 3.9): /usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS