similar to: [LLVMdev] DenseMap iterator constness fix

Displaying 20 results from an estimated 700 matches similar to: "[LLVMdev] DenseMap iterator constness fix"

2009 Nov 03
0
[LLVMdev] DenseMap iterator constness fix
+template <bool, typename True, typename False> +struct If { typedef True Result; }; + +template <typename True, typename False> +struct If<false, True, False> { typedef False Result; }; These should probably go into include/llvm/Support/type_traits.h. In C++0x, this is named "conditional" (section 20.6.7), so I think you should use the same name, despite the standard
2009 Nov 04
2
[LLVMdev] DenseMap iterator constness fix
Hi Jeffrey, You are right that the generated copy constructor is used for const_iterator. I have added a comment clarifying this. Also I have added the tests you suggested and corrected the comparison operators. Please find attached the updated patches. Best regards, Victor 2009/11/3 Jeffrey Yasskin <jyasskin at google.com> > +template <bool, typename True, typename False> >
2009 Nov 04
2
[LLVMdev] DenseMap iterator constness fix
Good catch! I meant "for iterator" of course. Attached is a corrected patch together with an old patch for clang just to keep them together. Could someone commit these, please? Thanks, Victor 2009/11/4 Jeffrey Yasskin <jyasskin at google.com> > + // Otherwise this is a copy constructor for const_iterator. > > Do you mean "for iterator"? > > Otherwise,
2009 Nov 04
0
[LLVMdev] DenseMap iterator constness fix
+ // Otherwise this is a copy constructor for const_iterator. Do you mean "for iterator"? Otherwise, looks good to me. If you can commit this, please do. Otherwise, someone else should as I'm not going to be around tomorrow. On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich <victor.zverovich at googlemail.com> wrote: > Hi Jeffrey, > You are right that the generated
2009 Nov 09
0
[LLVMdev] DenseMap iterator constness fix
Reminding about the patches... Is there a problem with them or simply nobody have looked at them since? Victor 2009/11/4 Victor Zverovich <victor.zverovich at googlemail.com> > Good catch! I meant "for iterator" of course. Attached is a corrected patch > together with an old patch for clang just to keep them together. > Could someone commit these, please? > >
2019 Jun 21
2
Purpose of Epoch Trackers
Hi all, I'm dealing with the multi-threaded code, in one of executions of the program I hitting an assertion failure, I'm not always getting the assertion failure when I run the executable but it occurs for say (1 in 10) times. I think there may be an thread race condition. I don't know which is the root cause of this error because the assertion not explicitly occurs in my code, it
2013 Nov 04
2
[LLVMdev] compile error when using overloaded = operator of DenseMap
Hi, I am trying to implement Available Expressions data flow analysis. I created the following class (I am giving here code snippet.): namespace { typedef DenseMap<Expression, uint32_t> DMTy; //Expression is a class I defined. struct DataFlowValue { DMTy ExprMap; llvm::BitVector* DFV; // Functions operating on the data // bool operator==(const DataFlowValue V) const;
2013 Nov 04
0
[LLVMdev] compile error when using overloaded = operator of DenseMap
On Mon, Nov 4, 2013 at 10:35 AM, Rekha R <rekharamapai at nitc.ac.in> wrote: > Hi, > > I am trying to implement Available Expressions data flow analysis. I created > the following class (I am giving here code snippet.): > > namespace { > typedef DenseMap<Expression, uint32_t> DMTy; //Expression is a class I > defined. > struct DataFlowValue { >
2008 Oct 30
6
[LLVMdev] cygwin build problems
Cygwin's <stdint.h> defines uint32_t as "unsigned long". I think this is valid, but it causes various problems like this when building LLVM with GCC 3.4.4: .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3440: error: call of overloaded `AddInteger(uint32_t)' is ambiguous .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1429: error: no matching function for call to `max(long
2018 Jul 25
2
are the LLD libraries thread safe?
E.g. Is it intended to be allowed to call lld::elf::link in 2 different threads at the same time? Follows is an example Valgrind error I ran into when doing the above. I'll try putting a global resource lock on invoking LLD and see if it solves the problem. ==5467== Invalid write of size 8 ==5467== at 0x525509: llvm::DenseMapBase<llvm::DenseMap<llvm::CachedHashStringRef, int,
2012 Oct 26
2
[LLVMdev] changes to raw_fd_ostream
I'm getting seemingly odd SegFaults when writing out using a raw_fd_ostream in the current trunk (last version worked, believe it was 153818, or similar). Again, nothing in the release notes... should I be scanning the svn log? For example, I have something like: raw_fd_ostream fout("out.txt", errorStr=""); .... fout<<"Hello World, how are you!"\n";
2018 Jul 25
2
are the LLD libraries thread safe?
Hi Andrew, LLD relies on various bits of global state which are manipulated during the link, so I wouldn't expect it to be thread safe at that level, although it does attempt to reset that global state at the start of each call to link(), so it should be callable sequentially. Regards, James On 25 July 2018 at 02:37, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote:
2012 Oct 26
0
[LLVMdev] changes to raw_fd_ostream
It looks like some kind of file IO buffer overflow. I'm not dumping any long strings at one time, but I am keeping the file open for the entire run. I've yet to find a correlation to other C files. On Fri, Oct 26, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm getting seemingly odd SegFaults when writing out using a > raw_fd_ostream in the current
2012 Oct 29
1
[LLVMdev] changes to raw_fd_ostream
So I did a clean checkout and build and still have this issue, did something changed with the way/when it's getting flushed? My old revision did not have this issue, this is an issue strictly with LLVM it seems. On Fri, Oct 26, 2012 at 3:27 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > It looks like some kind of file IO buffer overflow. I'm not dumping any > long strings
2012 Aug 02
2
[LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build
Hi, After building out project in release mode, caught an assertion, which we have not seen before: hello_f: /tmp/rpmbuild_debug/BUILD/llvm/build/include/llvm/ADT/DenseMap.h:126: void llvm::DenseMap<KeyT, ValueT, KeyInfoT>::clear() [with KeyT = llvm::MachineBasicBlock*, ValueT = <unnamed>::BlockChain*, KeyInfoT = llvm::DenseMapInfo<llvm::MachineBasicBlock*>]: Assertion
2009 Jun 15
4
[LLVMdev] runtime library for jitted code
Albert Graef <Dr.Graef at t-online.de> writes: > Victor Zverovich wrote: >> I am considering a possibility of using LLVM JIT for an algebraic >> modelling language. I have already done some prototyping following the >> Kaleidoscope tutorial and currently thinking of how to connect the >> jitted code to a runtime library (for this language) which I would like
2010 May 28
4
[LLVMdev] how to get TargetData?
Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part
2009 Jun 16
0
[LLVMdev] runtime library for jitted code
Hi, The question about the name mangling gave me an idea that it can be used to automate registration of DLL functions. Instead of manually creating Function objects specifying a return type and argument types which is error-prone and time-consuming one can get a list of functions exported from a DLL using Windows API, demangle each name and construct a Function object from it. Is there any
2010 Apr 05
2
[LLVMdev] llvm gold plugin example
Hi all, Following the example from http://llvm.org/docs/GoldPlugin.html#example1 gives the following error on Ubuntu Karmic: /usr/bin/ld: error: a.a: no archive symbol table (run ranlib) /usr/bin/ld: /usr/lib/crt1.o:../sysdeps/i386/elf/start.S:115: error: undefined reference to 'main' /usr/bin/ld: b.o: in function foo1:b.c(.text+0x4): error: undefined reference to 'foo2'
2013 Apr 02
1
[LLVMdev] cyclical dependence between caller and callee in JIT
2013/3/27 Nick Lewycky <nicholas at mxc.ca>: >The common idiom to delete any Value* is: > > V->replaceAllUsesWith(UndefValue::get(V->getType()); > V->eraseFromParent(); > > Does that work for functions? You may need to make sure the 'undef' has a > pointer to function type instead of the function type. > I tried this code sample, passing the type