search for: libllvmselectiondag

...rom: getVerboseAsm() in libLLVMCodeGen.a(LLVMTargetMachine.cpp.o) "llvm::TargetData::getPrefTypeAlignment(llvm::Type const*) const", referenced from: llvm::SelectionDAG::getConstantPool(llvm::MachineConstantPoolValue*, llvm::EVT, unsigned int, int, bool, unsigned char)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::SelectionDAG::getConstantPool(llvm::Constant const*, llvm::EVT, unsigned int, int, bool, unsigned char)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::SelectionDAG::CreateStackTemporary(llvm::EVT, llvm::EVT)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o)...

...rom: getVerboseAsm() in libLLVMCodeGen.a(LLVMTargetMachine.cpp.o) "llvm::TargetData::getPrefTypeAlignment(llvm::Type const*) const", referenced from: llvm::SelectionDAG::getConstantPool(llvm::MachineConstantPoolValue*, llvm::EVT, unsigned int, int, bool, unsigned char)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::SelectionDAG::getConstantPool(llvm::Constant const*, llvm::EVT, unsigned int, int, bool, unsigned char)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::SelectionDAG::CreateStackTemporary(llvm::EVT, llvm::EVT)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o)...

...7 1 libLLVMSupport.so 0x00007f74050232e3 2 libpthread.so.0 0x00007f7404960cb0 3 libc.so.6 0x00007f7403bba425 gsignal + 53 4 libc.so.6 0x00007f7403bbdb8b abort + 379 5 libc.so.6 0x00007f7403bb30ee 6 libc.so.6 0x00007f7403bb3192 7 libLLVMSelectionDAG.so 0x00007f7408266500 llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, llvm::APFloat const&) + 320 8 libLLVMSelectionDAG.so 0x00007f74081df6cf 9 libLLVMSelectionDAG.so 0x00007f74081d12b1 10 libLLVMSelectionDAG.so 0x00007f74081cff57 llvm::SelectionDAG::Legalize() + 375 11 libLLVMSelectio...

Hello Anton Thu, 3 Aug 2006 15:06:56 +0400 you wrote: > here it is in the attachment :) Ok. Could you also send LibDeps.txt file? It should be in /obj/tools/llvm-config directory -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...007f1b2d2b012a (/home/dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x9612a) #7 0x00007f1b359326ec (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) #8 0x00007f1b2d6a37a6 llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) #9 0x00007f1b2d6be0d9 llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x120156)...

...00007f74050232e3 > 2 libpthread.so.0 0x00007f7404960cb0 > 3 libc.so.6 0x00007f7403bba425 gsignal + 53 > 4 libc.so.6 0x00007f7403bbdb8b abort + 379 > 5 libc.so.6 0x00007f7403bb30ee > 6 libc.so.6 0x00007f7403bb3192 > 7 libLLVMSelectionDAG.so 0x00007f7408266500 > llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, llvm::APFloat > const&) + 320 > 8 libLLVMSelectionDAG.so 0x00007f74081df6cf > 9 libLLVMSelectionDAG.so 0x00007f74081d12b1 > 10 libLLVMSelectionDAG.so 0x00007f74081cff57 > llvm::SelectionDAG::Legal...

...; 2 libpthread.so.0 0x00007f7404960cb0 >> 3 libc.so.6 0x00007f7403bba425 gsignal + 53 >> 4 libc.so.6 0x00007f7403bbdb8b abort + 379 >> 5 libc.so.6 0x00007f7403bb30ee >> 6 libc.so.6 0x00007f7403bb3192 >> 7 libLLVMSelectionDAG.so 0x00007f7408266500 >> llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, llvm::APFloat >> const&) + 320 >> 8 libLLVMSelectionDAG.so 0x00007f74081df6cf >> 9 libLLVMSelectionDAG.so 0x00007f74081d12b1 >> 10 libLLVMSelectionDAG.so 0x00007f74081cff57 >> l...

Hello Anton Fri, 4 Aug 2006 21:45:19 +0400 you wrote: > Written by Mike Haertel and Paul Eggert. > I've updated llvm and llvm-gcc4 ant trying to build it again after > PR845 was resolved. According to Reid's letter this PR coud be the > reason of my problem. Anyway, "sort" call can cause large problems depending, where in your PATH cygwin directory is (before

.../dev/llvm/build/bin/../lib/libLLVMSupport.so.6+0x9612a) > #7 0x00007f1b359326ec > (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) > #8 0x00007f1b2d6a37a6 > llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) > #9 0x00007f1b2d6be0d9 > llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) > #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() > (/home/dev/llvm/build/bin/../lib/libLLVMSelec...

Make sure you’re running LLVM with assertions enabled. You’ll get more information about what’s going wrong that way. That said, yes, this looks like a bug. Specifically, SelectionDAGLegalize::ExpandConstantFP() assumes that f32 is the smallest floating point constant type it’ll need to handle, and that MVT enum ordering reflects that. while (SVT != MVT::f32) {

...trying to build llvm-2.7 using non-system gcc/binutils. My gcc version is 4.1.2, and binutils is 2.17.50.0.15. I get the following errors `.L2438' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) .... .... make[1]: *** [/build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVM-2.7....

...../lib/libLLVMSupport.so.6+0x9612a) > #7 0x00007f1b359326ec > (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) > #8 0x00007f1b2d6a37a6 > llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) > #9 0x00007f1b2d6be0d9 > llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) > #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() > (/home/dev/llvm/build/bin...

Hi, if I write the following simple program: target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" define void @foo () { %1 = alloca half store half 0xH42CC, half* %1 ; 0xH42CC = 3.4 %2 = load half* %1

...> > #7 0x00007f1b359326ec > > (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so. > 6+0x1176ec) > > #8 0x00007f1b2d6a37a6 > > llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, > bool) > > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) > > #9 0x00007f1b2d6be0d9 > > llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned > int) > > (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) > > #10 0x00007f1b2d69f156 llvm::DAGTypeLegalizer::run() > >...

...t; > >  (/home/dev/llvm/build/bin/../lib/libLLVMHexagonCodeGen.so.6+0x1176ec) > >     #8 0x00007f1b2d6a37a6 > >     llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, > llvm::EVT, bool) > > >  (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x1247a6) > >     #9 0x00007f1b2d6be0d9 > >     llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, > unsigned int) > > >  (/home/dev/llvm/build/bin/../lib/libLLVMSelectionDAG.so.6+0x13f0d9) > >     #10 0x00007f1b2d69f156 llvm:...

...known to have issues building LLVM; see http://llvm.org/docs/GettingStarted.html#brokengcc . Try upgrading your gcc version. -Eli > `.L2438' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o) > .... > .... > make[1]: *** [/build/toolchain/src/llvm-2.7/objdir/Release/l...

.... Has anyone else met with similar error under same platform? Thanks a lot. ..... ..... `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of /home/ktian/llvm/llvm-2.5/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o): defined in discarded section `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' of /home/ktian/llvm/llvm-2.5/Release/lib/libLLVMSelectionDAG.a(LegalizeVectorTypes.o) `.gnu.linkonce.t._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3MVTE' referenced...

For the tests that are changing, you should see if those changes are improvements, regressions, or neutral. This is unfortunately not always obvious for x86 asm, so feel free to just post those diffs in an updated version of the patch at D37896. If the test files have auto-generated assertions (look for this string on the first line of the test file: "NOTE: Assertions have been autogenerated

Dear All, Has anyone else noticed the following problem building LLVM on Mac OS X: find-cycles.pl: Circular dependency between *.a files: find-cycles.pl: libLLVMAsmPrinter.a libLLVMCodeGen.a libLLVMSelectionDAG.a llvm[1]: Building llvm-config script. cat: /Users/criswell/box/x86/llvm22/tools/llvm-config/FinalLibDeps.txt: No such file or directory -- John T.

> > If you're building llvm-gcc4, you don't need the runtime libraries, so > I'd just stick with the "tools-only" build and declare success. If > you're building llvm-gcc3, I'd suggest you switch to llvm-gcc4 :) I switched to llvm-gcc4 but when I run make from obj folder i run into folowing errors: Can't find a library with no dependencies at