similar to: [LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build

Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build"

2012 Aug 03
0
[LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build
Dear NVPTX community, I've create a bug http://llvm.org/bugs/show_bug.cgi?id=13521 with reprocase for this issue. Please, help us to fix it. Last 1,5 months we regularly encounter & workaround or fix 1-2 bugs per week in NVPTX backend. This is definitely not the amount of work we can completely serve ourselves... We would really really appreciate some collaboration. Thanks, - D.
2012 Aug 03
1
[LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build
Unfortunately, I cannot reproduce this. Based on your bugzilla comment, it does look like a mis-compile with your system compiler. Does the same issue occur if you build LLVM as static libraries? On 08/03/2012 12:24 AM, Dmitry N. Mikushin wrote: > Dear NVPTX community, > > I've create a bug http://llvm.org/bugs/show_bug.cgi?id=13521 with > reprocase for this issue. > >
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 { >
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";
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
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
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,
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
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 03
2
[LLVMdev] DenseMap iterator constness fix
Dear all, The first of the proposed patches (DenseMapIterator.patch) forbids implicit conversion of DenseMap::const_iterator to DenseMap::iterator which was possible because DenseMapIterator inherited (publicly) from DenseMapConstIterator. Conversion the other way around is now allowed as one may expect. The template DenseMapConstIterator is removed and the template parameter IsConst which
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? > >
2012 May 16
2
[LLVMdev] NVPTX: __iAtomicCAS support ?
Dear colleagues, I'm looking if we can replace nvopencc with LLVM NVPTX in our project. It turns NVPTX won't work with the code nvopencc can handle (please see the log below). So are atomic intrinsics not supported or am I doing call in a wrong way? Thanks, - Dima. SOURCE ======== dmikushin at hp2:~> cat kernelgen_monitor.ll ; ModuleID =
2009 Oct 27
1
[LLVMdev] Remove class/struct DenseMapInfo mix
Hello Visual Studio is complaining about the mix of struct and class. 2>C:\dev\llvm\include\llvm/ADT/ValueMap.h(202) : warning C4099: 'llvm::DenseMapInfo<llvm::ValueMapCallbackVH<KeyT,ValueT,Config,ValueInfoT>>' : type name first seen using 'struct' now seen using 'class' 2> C:\dev\llvm\include\llvm/ADT/ValueMap.h(251) : see reference to class
2012 May 16
0
[LLVMdev] NVPTX: __iAtomicCAS support ?
> -----Original Message----- > From: Dmitry N. Mikushin [mailto:maemarcus at gmail.com] > Sent: Wednesday, May 16, 2012 5:44 AM > To: LLVM-Dev > Cc: Justin Holewinski > Subject: NVPTX: __iAtomicCAS support ? > > Dear colleagues, > > I'm looking if we can replace nvopencc with LLVM NVPTX in our project. > It turns NVPTX won't work with the code nvopencc
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
2012 Aug 02
1
[LLVMdev] Questions about clang options
Dear Zhang, Compiler ends up invoking cc1 (the backend) anyways. So if you would like to invoke it by hand, the only thing to know is the right combination of options. Try to use the compiler verbose option "-v". It will show you how exactly clang invokes the backend: > clang -v -c showdebug.c clang version 3.2 (trunk 156703) Target: x86_64-unknown-linux-gnu Thread model: posix