Displaying 7 results from an estimated 7 matches for "rpmbuild_debug".
2012 May 16
2
[LLVMdev] NVPTX: __iAtomicCAS support ?
...version 3.0
.target sm_20, texmode_independent
.address_size 32
.func (.param .b32 func_retval0) _Z12__iAtomicCASPiii
(
.param .b32 _Z12__iAtomicCASPiii_param_0,
.param .b32 _Z12__iAtomicCASPiii_param_1,
.param .b32 _Z12__iAtomicCASPiii_param_2
)
;
Not Implemented
UNREACHABLE executed at
/tmp/rpmbuild_debug/BUILD/llvm/build/include/llvm/Target/TargetLowering.h:1249!
0 libLLVM-3.2svn.so 0x00007f47738b8f5f
1 libLLVM-3.2svn.so 0x00007f47738b9525
2 libpthread.so.0 0x00007f47726135d0
3 libc.so.6 0x00007f4771931945 gsignal + 53
4 libc.so.6 0x00007f4771932f21 abort + 385
5 libLLVM-3.2...
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 `NumEntries
== 0 && "Node...
2012 May 16
0
[LLVMdev] NVPTX: __iAtomicCAS support ?
...32
>
> .func (.param .b32 func_retval0) _Z12__iAtomicCASPiii
> (
> .param .b32 _Z12__iAtomicCASPiii_param_0,
> .param .b32 _Z12__iAtomicCASPiii_param_1,
> .param .b32 _Z12__iAtomicCASPiii_param_2
> )
> ;
>
> Not Implemented
> UNREACHABLE executed at
> /tmp/rpmbuild_debug/BUILD/llvm/build/include/llvm/Target/TargetLowerin
> g.h:1249!
> 0 libLLVM-3.2svn.so 0x00007f47738b8f5f
> 1 libLLVM-3.2svn.so 0x00007f47738b9525
> 2 libpthread.so.0 0x00007f47726135d0
> 3 libc.so.6 0x00007f4771931945 gsignal + 53
> 4 libc.so.6 0x00007f477193...
2012 Aug 03
0
[LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build
...pletely serve ourselves...
We would really really appreciate some collaboration.
Thanks,
- D.
2012/8/3 Dmitry N. Mikushin <maemarcus at gmail.com>:
> 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 `NumEntries
> == 0 &...
2012 Aug 03
1
[LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build
...ly appreciate some collaboration.
>
> Thanks,
> - D.
>
> 2012/8/3 Dmitry N. Mikushin <maemarcus at gmail.com>:
>> 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 `NumEntries...
2012 Jun 29
0
[LLVMdev] [NVPTX] Backend failure in LegalizeDAG due to unimplemented expand in target lowering
...ne with the
following command:
$ bugpoint -llc-safe test.ll
The resulting IR is attached, and it is crashing in the same way. Is
it a valid code?
dmikushin at hp2:~/forge/kernelgen/branches/tests_lnt/behavior/sincos>
llc test.ll.1
This action is not supported yet!
UNREACHABLE executed at
/tmp/rpmbuild_debug/BUILD/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1194!
0 libLLVM-3.2svn.so 0x00007f395f147077
1 libLLVM-3.2svn.so 0x00007f395f14763d
2 libpthread.so.0 0x00007f395dee05d0
3 libc.so.6 0x00007f395d74b945 gsignal + 53
4 libc.so.6 0x00007f395d74cf21 abort + 385
5 libLLVM-3.2sv...
2012 Jun 27
2
[LLVMdev] [NVPTX] Backend failure in LegalizeDAG due to unimplemented expand in target lowering
Dear LLVM,
I'm trying to understand why the attached IR code works for x86_64
target and fails for nvptx64, because of unimplemented expand during
the target lowering. Any ideas?
Just change the target triple to x86_64-unknown-unknown, and the same
IR code could we successfully codegen-ed for x86_64.
Thanks,
- Dima.
dmikushin at dmikushin-desktop:~/Desktop$ gdb ~/sandbox/bin/llc
GNU gdb