search for: stl_vector

Akshay Jain <jivan.molu at gmail.com> writes: > I have tried it, but I always end up with some kind of error. Can you > explain how can I get a function type for function which returns void > (nothing) and it's arguments are (int, int, int, void *, void *, ...) ?? Instead of getting something to cut&paste, you would be much more enriched if the problematic code and the

...blem appears here (http://www.r-project.org/nosvn/R.check/r-patched-linux-ix86/rimage-00install.html) but I do not know what its appearance there means. Thanks in advance for any help! Abbe g++ -I/usr/share/R/include -g -O2 -fpic -g -O2 -c matrix.cpp -o matrix.o /usr/include/c++/4.3/bits/stl_vector.h: In member function ?void std::vector<_Tp, _Alloc>::_M_initialize_dispatch(_Integer, _Integer, std::__true_type) [with _Integer = int, _Tp = std::vector<double, std::allocator<double> >, _Alloc = std::allocator<std::vector<double, std::allocator<double> > >]?:...

I have tried it, but I always end up with some kind of error. Can you explain how can I get a function type for function which returns void (nothing) and it's arguments are (int, int, int, void *, void *, ...) ?? Thanks in advance. On Tue, Apr 16, 2013 at 7:22 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Akshay Jain <jivan.molu at gmail.com> writes: > > > I am

...ome/akshay/llvm/llvm-2.9/lib/Transforms/AliasPass/pass2.cpp:108:62: error: no matching function for call to ‘std::vector<llvm::Type*>::push_back(const llvm::IntegerType*) const’ /home/akshay/llvm/llvm-2.9/lib/Transforms/AliasPass/pass2.cpp:108:62: note: candidate is: /usr/include/c++/4.6/bits/stl_vector.h:826:7: note: void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = llvm::Type*, _Alloc = std::allocator<llvm::Type*>, std::vector<_Tp, _Alloc>::value_type = llvm::Type*] <near match> /usr/include/c++/4.6/bits/stl_vector.h:826:7: note: no known conve...

...0x000000080136ecd1 in malloc_usable_size () from /lib/libc.so.7 #2 0x000000080136eec7 in free () from /lib/libc.so.7 #3 0x00000000007cdf7d in deallocate (this=0xd2e178, __p=0xd561c0) at new_allocator.h:97 #4 0x00000000007cdfaf in _M_deallocate (this=0xd2e178, __p=0xd561c0, __n=4) at stl_vector.h:134 #5 0x00000000007d66ef in _M_fill_insert (this=0xd2e178, __position= {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at vector.tcc:381 #6 0x00000000007d676d in insert (this=0xd2e178, __position= {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at stl_vector.h:653 #...

...p for Release-Asserts build In file included from IntrinsicInst.cpp:32: c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ boost_concept_check.h: In instantiation of '__gnu_cxx::_SGIAssignableConcept<llvm::MachineMove>': c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/stl_vector.h: 179: insta ntiated from 'std::vector<llvm::MachineMove, std::allocator<llvm::MachineMove> > ' c:/Users/Greybird/Desktop/llvm/llvm-2.4/include/llvm/CodeGen/ MachineModuleInfo.h :1007: instantiated from here c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ boost...

Mark Kromis wrote: > Resend > > > On Oct 14, 2008, at 5:40 AM, Mark Kromis wrote: > > >> Greetings, >> >> I have a compiler error that I have not been able to get through. I >> usually depend upon pre-built binaries but there was none available >> for the pre-release. I also try scanning the web site and mail list >> but was unable to

...4: warning: implicit declaration of function 'clearFrame' x86_64-pc-linux-gnu-g++ -I/usr/lib64/R/include -g -O2 -I/usr/local/include -fpic -O2 -march=core2 -fomit-frame-pointer -fno-ident -fweb -pipe -msse3 -c matrix.cpp -o matrix.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4/bits/stl_vector.h: In member function 'void std::vector<_Tp, _Alloc>::_M_initialize_dispatch(_Integer, _Integer, std::__true_type) [with _Integer = int, _Tp = std::vector<double, std::allocator<double> >, _Alloc = std::allocator<std::vector<double, std::allocator<double> > >...

Hi, > Today I've been trying to debug a weird bug that makes JIT crash with > certain code and when using the inliner. This may sound weird, but if I > disable the inliner, it doesn't crash. > I include an example gdb dump below. Does something looks wrong? Do you > think it's a bug in JIT or it's just some other piece of code that is > writing on the JIT

...usable_size () from /lib/libc.so.7 > #2 0x000000080136eec7 in free () from /lib/libc.so.7 > #3 0x00000000007cdf7d in deallocate (this=0xd2e178, __p=0xd561c0) > at new_allocator.h:97 > #4 0x00000000007cdfaf in _M_deallocate (this=0xd2e178, __p=0xd561c0, > __n=4) > at stl_vector.h:134 > #5 0x00000000007d66ef in _M_fill_insert (this=0xd2e178, __position= > {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0) at > vector.tcc:381 > #6 0x00000000007d676d in insert (this=0xd2e178, __position= > {_M_current = 0xd56380}, __n=1, __x=@0x7fffffffdbb0...

...load_memcheck.so) ==11384== by 0x54C5034: __gnu_cxx::new_allocator<llvm::SDValue>::deallocate(llvm::SDValue*, unsigned) (new_allocator.h:96) ==11384== by 0x54C505E: std::_Vector_base<llvm::SDValue, std::allocator<llvm::SDValue> >::_M_deallocate(llvm::SDValue*, unsigned) (stl_vector.h:133) ==11384== by 0x54C5097: std::_Vector_base<llvm::SDValue, std::allocator<llvm::SDValue> >::~_Vector_base() (stl_vector.h:119) ==11384== by 0x54C50F9: std::vector<llvm::SDValue, std::allocator<llvm::SDValue> >::~vector() (stl_vector.h:272) ==11384== by 0x5683...

...tried to compile LLVM SVN 51761 with the Debian Etch provided g++ ("g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)"). While doings this, I got this error: llvm[4]: Compiling X86AsmPrinter.cpp for Release build /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h: In member function 'void llvm::SelectionDAGLowering::visitBitTestCase(llvm::MachineBasicBlock*, unsigned int, llvm::SelectionDAGISel::BitTestCase&)': /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:610: internal compiler error: in expand_expr_addr_ex...

...es::getColNam es() const': c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ 3.4.5/bits/stl_uninitiali zed.h:82: warning: '__cur' might be used uninitialized in this function c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ 3.4.5/bits/stl_vector.h: In member function `std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector< _Tp, _Alloc>&) [with _Tp = std::string, _Alloc = std::allocator<std::string>]': c:/src/R/Rtools/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/ 3.4...

Hi, Today I've been trying to debug a weird bug that makes JIT crash with certain code and when using the inliner. This may sound weird, but if I disable the inliner, it doesn't crash. I include an example gdb dump below. Does something looks wrong? Do you think it's a bug in JIT or it's just some other piece of code that is writing on the JIT memory?.. I don't really know

On May 25, 2008, at 1:39 PM, Marcel Moolenaar wrote: > On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > >> Could you try this (massively hacky) patch out to see if it fixes >> your >> problem? >> >> > Alas, it didn't fix the problem: > Crumbs. I think that the analysis I told you before wasn't fully correct. I think I mentioned something

...ackEndPointer is the Immutable Pass. This segfaults when ScalarEvolution tries to get TargetData if available. Below is the complete stack trace: #0 0x083ae6fd in std::vector<llvm::PassInfo const*, std::allocator<llvm::PassInfo const*> >::begin (this=0x10) at /usr/include/c++/4.4/bits/stl_vector.h:435 #1 0x083a63c8 in llvm::PMTopLevelManager::findAnalysisPass (this=0x85f6ad4, AID=0x85eef30) at /home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:673 #2 0x083a7f0e in llvm::PMDataManager::findAnalysisPass (this=0x88931b8, AID=0x85eef30, SearchParent=true) at /home/michael/Luna...

...0056348d614025 > lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) > /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:55:0 > > #7 0x000056348d5f363e std::vector<lld::coff::Chunk*, > std::allocator<lld::coff::Chunk*> >::~vector() > /usr/include/c++/7/bits/stl_vector.h:434:0 > > #8 0x000056348d5f363e lld::coff::LinkerDriver::link(llvm::ArrayRef<char > const*>) /home/jshi19/llvm/llvm-project/lld/COFF/Driver.cpp:1840:0 > > #9 0x000056348d5f3d08 lld::coff::link(llvm::ArrayRef<char const*>, bool, > llvm::raw_ostream&) /home/jshi19/...

...COFF/MarkLive.cpp:46:0 #6 0x000055f11edd8025 lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:55:0 #7 0x000055f11edb763e std::vector<lld::coff::Chunk*, std::allocator<lld::coff::Chunk*> >::~vector() /usr/include/c++/7/bits/stl_vector.h:434:0 #8 0x000055f11edb763e lld::coff::LinkerDriver::link(llvm::ArrayRef<char const*>) /home/jshi19/llvm/llvm-project/lld/COFF/Driver.cpp:1840:0 #9 0x000055f11edb7d08 lld::coff::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) /home/jshi19/llvm/llvm-project/lld/COFF/Dri...

...0055f11edd8025 > lld::coff::markLive(llvm::ArrayRef<lld::coff::Chunk*>) > /home/jshi19/llvm/llvm-project/lld/COFF/MarkLive.cpp:55:0 > > #7 0x000055f11edb763e std::vector<lld::coff::Chunk*, > std::allocator<lld::coff::Chunk*> >::~vector() > /usr/include/c++/7/bits/stl_vector.h:434:0 > > #8 0x000055f11edb763e lld::coff::LinkerDriver::link(llvm::ArrayRef<char > const*>) /home/jshi19/llvm/llvm-project/lld/COFF/Driver.cpp:1840:0 > > #9 0x000055f11edb7d08 lld::coff::link(llvm::ArrayRef<char const*>, bool, > llvm::raw_ostream&) /home/jshi19/...

On May 25, 2008, at 12:58 AM, Bill Wendling wrote: > On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > >> On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> >>> Let us know if you would like extra eyes on the two PPC failures. >>> Many >>> of us have a lot of experience with C++. :-) Do you know where these >>> allocations are?