search for: _list_node_base

...r LLVM-3.0 llvm[1]: Generating LLVM-3.0.def llvm[1]: Linking Release Shared Library LLVM-3.0.dll c:/dev/llvm/build-rc3/Release/lib/libLLVMCodeGen.a(RegAllocPBQP.o):fake:(.text$_ ZN4PBQP5Graph7addNodeERKNS_6VectorE[PBQP::Graph::addNode(PBQP::Vector const&)]+0 x9c): undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base *)' c:/dev/llvm/build-rc3/Release/lib/libLLVMCodeGen.a(RegAllocPBQP.o):fake:(.text$_ ZN4PBQP19HeuristicSolverImplINS_10Heuristics6BriggsEE15computeSolutionEv[PBQP::H euristicSolverImpl<PBQP::Heuristics::Briggs>::computeSolution()]+0x76): undefine d reference...

...assembler. If you want to find out original parameter > names you need to use debug info. Note that the original parameter (of the function in concern) is of type "struct.std::_List_const_iterator<int>", whereas the parameter (after the compilation) is of type "struct.std::_List_node_base"*. Evidently, llvm-g++ replaces the original parameter with its sole field. This is understandable and the LLVM output indicates this by using "__position.0" rather than "__position". Further, llvm-g++ represents (bitcasts) the parameter type "struct.std::_List_node_ba...

Hi Xiaolong, > Note that the original parameter (of the function in concern) is of > type "struct.std::_List_const_iterator<int>", whereas the parameter > (after the compilation) is of type > "struct.std::_List_node_base"*. Evidently, llvm-g++ replaces the > original parameter with its sole field. This is understandable and the > LLVM output indicates this by using "__position.0" rather than > "__position". Further, llvm-g++ represents (bitcasts) the parameter > type "struc...

Hi Duncan, > > Note that the original parameter (of the function in concern) is of > > type "struct.std::_List_const_iterator<int>", whereas the parameter > > (after the compilation) is of type > > "struct.std::_List_node_base"*. Evidently, llvm-g++ replaces the > > original parameter with its sole field. This is understandable and the > > LLVM output indicates this by using "__position.0" rather than > > "__position". Further, llvm-g++ represents (bitcasts) the parameter > &...

2011/11/13 Alan Garny <agarny at hellix.com>: > Now, I know that shared libraries are not supported on Windows using CMake > (according to http://www.llvm.org/docs/CMake.html) which would have been my > preferred building choice, but I didn’t see anything against them not being > supported using Autotools, so I thought I would try it that way (as I > successively did on Linux

Hi, I need to build a shared version of LLVM on Windows, Linux (both x86 and x64) and Mac OS X. So far, I have been able to build LLVM on Linux and Mac OS X, and it's all working fine as confirmed by a small LLVM test code that I wrote. However, on Windows, even though I get a DLL, that DLL doesn't contain any (exported) functions (according to DLL Export Viewer; see

...zation executed by llvm-g++, simplifying function parameters in certain cases. Consider the following example: Given an iterator (in the context of C++ STL) (i.e. a class containing a pointer to another class): %"struct.std::_List_const_iterator<int>" = type { %"struct.std::_List_node_base"* } (The form in the readable LLVM language) and a function definition (declaration): void _M_insert(iterator __position, const value_type& __x) { ... } By issuing this command: llvm-g++ -fno-exceptions -fno-inline -emit-llvm -c ... The compilation substitutes "__position.0...

Hi Xiaolong, > The compilation substitutes "__position.0" for "__position", as shown below: > > define linkonce_odr void @_ZNSt4listIiSaIiEE9_M_insertESt14_List_iteratorIiERKi(%"struct.std::list<int,std::allocator<int> >"* %this, i64 %__position.0, i32* %__x) nounwind ssp { ... } names like this only exist to make the LLVM IR more readable,