similar to: [LLVMdev] Bug In Module::getConstantPointerRef ?

On Mon, 2 Feb 2004, Reid Spencer wrote: > > _Link_type __x = _M_root(); // Current node. > > The _M_root() call is de-referencing the _M_header field. > > This could, ostensibly, be a bug in std::_Rb_tree template but it could > also be a usage problem. > > Note that the GVRefMap (in Module.cpp) has no constructor and just uses > the default. Presumably the default

I am debugging the memory issue that manifests itself like this: *** glibc detected *** ../app/app.OWS: free(): invalid pointer: 0x0ad391fc *** ======= Backtrace: ========= /lib/libc.so.6(+0x6c501)[0x4f6501] /lib/libc.so.6(+0x6dd70)[0x4f7d70] /lib/libc.so.6(cfree+0x6d)[0x4fae5d] ../app/app.OWS(_ZNSt8_Rb_treeIjjSt9_IdentityIjESt4lessIjESaIjEE5eraseESt17_Rb_tree_iteratorIjES7_+0x4b)[0x83de6eb]

I found the problem : my code sets JITEmitDebugInfo after creating the JIT. This causes the JITDwarfEmitter DE to not be constructed in the ctor of JITEmitter (JITEmitter.cpp around line 375). Not sure if it's documented anywhere that JITEmitDebugInfo must be set before constructing the JIT, but looking at the code, it makes sense. Easy enough to fix on my side. Christophe On 19 avr. 2011,

Hello, I'd like some advice on a crash that we have observed on MacOSX with the 2.8 and 2.9 releases of LLVM, but not on the top of trunk. The crash is a null-deref in llvm::JITDwarfEmitter::EmitDwarfTable : Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable

Hi list, Here it is: I have compiled with no problem courier-imap-4.0.4 on this arch (x86_64). Now I want to update my install with 4.0.6. I want to do this because the server is not yet in a production state, so if a major flaw affects courier-imap in the future, I could react more quickly. And indeed I'm encountering problems with the make process (Since I initialy build courier-imap

On Thu, 17 Jun 2004, Patrick Meredith wrote: > How is this done? Everything logical I have tried has failed, here was > one attempt: > > Constant *C = (Constant*) ConstantArray::get(inst2string(I)); //fucnction defined elsewhere > > //generates a correct Global string > GlobalVariable *str = new GlobalVariable(C->getType(), true, >

Dear LLVMers, I am trying to fold memory operands in the way that is done in RegAllocLocal.cpp, or in LiveIntervalAnalysis.cpp, but I am getting errors that I don't know how to fix. Could someone tell me which steps should I take in order to correctly fold memory operands? The code that I am using is: const TargetMachine & target_machine = this->machine_function->getTarget();

I have a Function* to a function that has a signature like: void foo(double*, double*); I need to write the address of this function into a global variable initializer (really, into the initializer of a particular structure field). The structure field type is void*, and must be. Because of type constraints, doing something like: Function* foo = ...; std::vector<const Type*> fields; ...

LLVMers, The long awaited conclusion of bug 122 (VMCore cleanups) is very near. I have just committed all the changes to rid LLVM of the ConstantPointerRef abomination. This class no longer exists. Just use GlobalValue, GlobalVariable or Function directly. The changes pass 100% of Feature and Regression tests. Two minor discrepancies against the Programs tests were detected but these were

As I thought about this more, I realized that the problem is not as easy as just transmuting the FunctionType from one FunctionType to another, since void* is not a FunctionType. If the strict type-checking that is happening (the assert on Constants.cpp:233 in the ConstantStruct constructor) is the only problem here, and nothing more severe, perhaps the client should be able to set a flag that

Hi, Probably some of the leaks Valgrind reports are spurious, but the numbers seem to be significant enough to demand some attention: ==10132== LEAK SUMMARY: ==10132== definitely lost: 15,624 bytes in 558 blocks. ==10132== indirectly lost: 44,548 bytes in 1,591 blocks. ==10132== possibly lost: 37,576 bytes in 98 blocks. ==10132== still reachable: 1,336,876 bytes in 1,364 blocks.

LLVMers, On the way to resolving bug 122, I am committing my SymbolTable rewrite. If you are working on anything that uses the SymbolTable, I suggest you read the documentation in include/llvm/SymbolTable.h. The changes I've committed reduce the use of Type::TypeTy. This static member will go away in the future, so please do not propagate new code that uses it. There is no reason to use it

How is this done? Everything logical I have tried has failed, here was one attempt: Constant *C = (Constant*) ConstantArray::get(inst2string(I)); //fucnction defined elsewhere //generates a correct Global string GlobalVariable *str = new GlobalVariable(C->getType(), true, GlobalValue::InternalLinkage, C, mkStrName( strNumber++ ), &M); std::vector<Value*>

Chris Lattner wrote: > > And why isn't it possible to just make those functions known to LLVM? > > After all, *I think*, if this function is to be called, it should be > > declared in assembler, and so you have to pass some information abou > > those function to the code printer. (Of course, it's possible to just > > directly print the declarations, but

Hi, Compiling the simple following function with llv (LLVM 2.8) : define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b) { %res = select <4 x i1> <i1 true, i1 false, i1 true, i1 true>, <4 x i32> %a, <4 x i32> %b ; ret <4 x i32> %res } gives : UNREACHABLE executed! 0 llc 0x0000000100927422 std::_Rb_tree<llvm::sys::Path,

Hi, Compiling the simple following function with llv (LLVM 2.8) : define <4 x i32> @foo(<4 x i32> %a, <4 x i32> %b) { %res = select <4 x i1> <i1 true, i1 false, i1 true, i1 true>, <4 x i32> %a, <4 x i32> %b ; ret <4 x i32> %res } gives : UNREACHABLE executed! 0 llc 0x0000000100927422 std::_Rb_tree<llvm::sys::Path,

Hi there, Inspired by the recent FOSDEM keynote, I've tried to write an LLVM backend for the STM8 microcontroller platform. The STM8S-Discovery evaluation board [1] has been handed out for free or is sold dirt- cheap, but there is no Open Source cross-compiler for it. The available ST assembler, linker and USB flash programmer are closed- source Windows binaries. And the compiler

Hi, for a current project I'm required to get the types of the template arguments key and value for std::map<K,V>. I've noticed that the STL implementation used by Clang defines the type of the map as %"class.std::map" = type { %"class.std::_Rb_tree" } which then is further defined and finally ends as %"struct.std::_Rb_tree_node_base" =

On Sun, Feb 20, 2011 at 4:23 PM, Andreas Färber <andreas.faerber at web.de> wrote: > Hi there, > > Inspired by the recent FOSDEM keynote, I've tried to write an LLVM > backend for the STM8 microcontroller platform. The STM8S-Discovery > evaluation board [1] has been handed out for free or is sold dirt- > cheap, but there is no Open Source cross-compiler for it. The >

On Tue, Oct 16, 2012 at 4:17 AM, Sebastian Dreßler <dressler at zib.de> wrote: > Hi, > > for a current project I'm required to get the types of the template > arguments key and value for std::map<K,V>. I've noticed that the STL > implementation used by Clang defines the type of the map as > > %"class.std::map" = type {