search for: cassert

Index: include/llvm/ADT/APInt.h =================================================================== --- include/llvm/ADT/APInt.h (revision 55101) +++ include/llvm/ADT/APInt.h (working copy) @@ -20,6 +20,7 @@ #include <cassert> #include <iosfwd> #include <string> +#include <cstring> namespace llvm { class Serializer; -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080821/c0d19448/attachment.html>

...fig flac --cflags to the compiler flags so that FLAC's headers can be found will break my build with errors like: error: 'assert' was not declared in this scope The problem is that /usr/include/FLAC has an "assert.h" header. In my C++ project, I have: #include <cassert> The cassert header (part of the standard C++ library) will internally include assert.h. But it ends up including the one from FLAC. I'm stuck. What do I do?

Hello, I am testing the new cool LLVM python bindings that Mahadevan wrote over the past few weeks. I came across a problem in the python binding which directed me to use of 'cassert'[1] in LLVM itself. When LLVM users make a mistake in using the library's constructs they usually hit an assertion. This form of defensive programming is great for detecting errors as soon as they happen, especially in c++. However, when I use the python bindings and hit an assertion, I...

> > hm, sending bug report is not my favorite hobby :) > > Well if you don't, it might never get fixed :( OK-OK, let's save the world :) Well, I've made it. > It might be possible to hack your <cassert> header file or something > though... it is just a few places in three files as reported in my previous post. Then comes assert violation with message from llvm sources. regards, -- vak

...y for dependencies: > ...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type > f|grep -v 'tests'` | sort | uniq -c > 1 #include <algorithm> > 10 #include <atomic> > 1 #include <bitset> > 6 #include <cassert> > 1 #include <cerrno> > 1 #include <cstddef> > 7 #include <cstdint> > 2 #include <cstdio> > 1 #include <cstdlib> > 2 #include <cstring> > 1 #include <deque> > 2 #include <iterato...

This fixes a bug in SmallVectorImpl<>::insert, which were not behaving correctly on inserting an empty range into an empty vector: #include <llvm/ADT/SmallVector.h> #include <cassert> int main() { llvm::SmallVector<int, 1> v, w; llvm::SmallVector<int, 1>::iterator it = v.insert(v.end(), w.begin(), w.end()); assert(it == v.end()); } The insert function(s) would incorrectly return "this->end()-1". I attached the patch which I diff'ed f...

>From CVS: llvm[3]: Compiling SJLJ-Exception.cpp for Debug build (bytecode) SJLJ-Exception.cpp:16:19: cstdlib: No such file or directory SJLJ-Exception.cpp:17:19: cassert: No such file or directory SJLJ-Exception.cpp: In function `void SJLJDestructor(llvm_exception*)': SJLJ-Exception.cpp:43: error: `free' undeclared (first use this function) SJLJ-Exception.cpp:43: error: (Each undeclared identifier is reported only once for each function it appears in.) SJLJ...

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler

...0, 2008, at 8:02 PM, Zhongxing Xu wrote: > Index: include/llvm/ADT/APInt.h > =================================================================== > --- include/llvm/ADT/APInt.h (revision 55101) > +++ include/llvm/ADT/APInt.h (working copy) > @@ -20,6 +20,7 @@ > #include <cassert> > #include <iosfwd> > #include <string> > +#include <cstring> > > namespace llvm { > class Serializer; > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.ed...

Works for me. Presumably #including <cassert> will fix it though? On Sep 26, 2008, at 4:30 PMPDT, Mike Stump wrote: > I'm seeing a build failure... > > In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ > Attributes.cpp:14: > /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member > function '...

Johannes Schaub (litb) wrote: > This fixes a bug in SmallVectorImpl<>::insert, which were not behaving > correctly on inserting an empty range into an empty vector: > > #include <llvm/ADT/SmallVector.h> > #include <cassert> > > int main() { > llvm::SmallVector<int, 1> v, w; > llvm::SmallVector<int, 1>::iterator it = > v.insert(v.end(), w.begin(), w.end()); > assert(it == v.end()); > } > > The insert function(s) would incorrectly return "this->end()-1"...

I'm seeing a build failure... In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ Attributes.cpp:14: /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member function 'llvm::Attributes llvm::AttrListPtr::getParamAttributes(unsigned int) const': /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h:152: error: 'assert' was not declared in this scope

> > - gcc bug > > - problem with SuSE distribution > > One of these two. In theory GCC should never crash (even if the LLVM > sources had problems), and since SuSE made modifications to the compiler > before they shipped it, they implicitly took responsibility for the end > result. I agree. > You can try sending a bug report to SuSE. hm, sending bug report is

...> ...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type > f|grep -v 'tests'` | sort | uniq -c > > 1 #include <algorithm> > > 10 #include <atomic> > > 1 #include <bitset> > > 6 #include <cassert> > > 1 #include <cerrno> > > 1 #include <cstddef> > > 7 #include <cstdint> > > 2 #include <cstdio> > > 1 #include <cstdlib> > > 2 #include <cstring> > > 1 #include <deque&gt...

...> ...compiler-rt/lib/xray % grep '#include <[^>.]*>' -oh `find . -type > f|grep -v 'tests'` | sort | uniq -c > > 1 #include <algorithm> > > 10 #include <atomic> > > 1 #include <bitset> > > 6 #include <cassert> > > 1 #include <cerrno> > > 1 #include <cstddef> > > 7 #include <cstdint> > > 2 #include <cstdio> > > 1 #include <cstdlib> > > 2 #include <cstring> > > 1 #include <deque&gt...

...n 50213) > +++ lib/VMCore/Core.cpp (working copy) > @@ -20,6 +20,7 @@ > #include "llvm/TypeSymbolTable.h" > #include "llvm/ModuleProvider.h" > #include "llvm/Support/MemoryBuffer.h" > +#include "llvm/Support/CallSite.h" > #include <cassert> > #include <cstdlib> > #include <cstring> > @@ -798,6 +799,101 @@ > return wrap(--I); > } > > +void LLVMAddParamAttr(LLVMValueRef Arg, LLVMParamAttr Param) { Rename Param -> Attr or PA or something. > + LLVMParamAttr P = (LLVMParamAttr)Param; >...

Hi.. Updated so you now set alignment through LLVMInstrSetAlignment. Anders Johnsen -------------- next part -------------- A non-text attachment was scrubbed... Name: ParamAttr.patch Type: text/x-diff Size: 7420 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080424/cb72b4bb/attachment.patch>

Yeah, this is a problem with the static constructor getting optimized out. Including "JIT.h" is supposed to fix that. Is it possible that the file where you are including "JIT.h" doesn't have any required code in it? -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Mario Schwalbe Sent: Tuesday,

...iftwidth=4 expandtab: */ #define DEBUG_TYPE "ExecutionEngineTest" #include <llvm/ExecutionEngine/Interpreter.h> #include <llvm/ExecutionEngine/JIT.h> #include <llvm/Support/TargetSelect.h> #include <llvm/LLVMContext.h> #include <llvm/Module.h> #include <cassert> using namespace llvm; int main(void) { InitializeNativeTarget(); #if 1 LLVMLinkInJIT(); #endif EngineBuilder engineBuilder(new Module("foo", getGlobalContext())); #if 0 engineBuilder.setEngineKind(EngineKind::Interpreter); #else engineBuilder.setEngineKind(Engin...

...s argument with assert itself. If it is just one or two places in the source base, it's probably ok to work around this. If the SuSE compiler has problems with that construct in general, however, it will never compile LLVM (we use it all over the place). It might be possible to hack your <cassert> header file or something though... -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/