search for: _first

...nfigure --prefix=/usr -- enable-optimized --disa ble-shared --disable-multilib --disable-asserts output: llvm[1]: Compiling BasicBlock.cpp for Release build c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ boost_concept_check.h: In member function 'bool __gnu_cxx::_EqualOpConcept<_First, _Second>::__constraint s_() [with _First = llvm::BasicBlock, _Second = llvm::BasicBlock*]': c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ boost_concept_check.h:296 : instantiated from 'void __gnu_cxx::_EqualOpConcept<_First, _Second>::__const raints() [with _First...

...ranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. llvm-2.7 $ make ... llvm[1]: Compiling BasicBlock.cpp for Release build /usr/lib/gcc/i386-pc-solaris2.11/4.3.2/../../../../include/c++/4.3.2/bits/boost_concept_check.h: In member function ‘bool __gnu_cxx::_EqualOpConcept<_First, _Second>::__constraints_() [with _First = llvm::BasicBlock, _Second = llvm::BasicBlock*]’: /usr/lib/gcc/i386-pc-solaris2.11/4.3.2/../../../../include/c++/4.3.2/bits/boost_concept_check.h:296: instantiated from ‘void __gnu_cxx::_EqualOpConcept<_First, _Second>::__constraints() [with _Fir...

...-optimized --disa > ble-shared --disable-multilib --disable-asserts > > output: > llvm[1]: Compiling BasicBlock.cpp for Release build > c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ > boost_concept_check.h: In > member function 'bool __gnu_cxx::_EqualOpConcept<_First, > _Second>::__constraint > s_() [with _First = llvm::BasicBlock, _Second = llvm::BasicBlock*]': > c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ > boost_concept_check.h:296 > : instantiated from 'void __gnu_cxx::_EqualOpConcept<_First, > _Second>:...

...c35830806() Unknown > zig.exe!std::_Debug_pointer<lld::coff::Chunk * __ptr64 const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int _Line) Line 926 C++ zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const * _First, lld::coff::Chunk * const * _Last, const wchar_t * _File, unsigned int _Line, std::random_access_iterator_tag __formal) Line 958 C++ zig.exe!std::_Debug_range<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const * _First, lld::coff::Chunk * const * _Last, const wchar_t...

...ebug_pointer<lld::coff::Chunk * __ptr64 >> > const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int >> > _Line) Line 926 C++ >> zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * >> __ptr64>(lld::coff::Chunk * const * _First, lld::coff::Chunk * const * >> _Last, const wchar_t * _File, unsigned int _Line, >> std::random_access_iterator_tag __formal) Line 958 C++ >> zig.exe!std::_Debug_range<lld::coff::Chunk * __ptr64 const * >> __ptr64>(lld::coff::Chunk * const * _First, lld::coff::...

...ueue_kick_prepare(struct virtqueue *vq); > > bool virtqueue_notify(struct virtqueue *vq); I don't much care for this API. It does exactly what balloon needs, but at cost of e.g. transparently busy-waiting. Unlikely to be a good fit for anything else. If you don't like my original _first/_next/_last, you will need to come up with something else. -- MST

...ueue_kick_prepare(struct virtqueue *vq); > > bool virtqueue_notify(struct virtqueue *vq); I don't much care for this API. It does exactly what balloon needs, but at cost of e.g. transparently busy-waiting. Unlikely to be a good fit for anything else. If you don't like my original _first/_next/_last, you will need to come up with something else. -- MST

...ble-shared --disable-multilib --disable-asserts >> >> output: >> llvm[1]: Compiling BasicBlock.cpp for Release build >> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >> boost_concept_check.h: In >> member function 'bool __gnu_cxx::_EqualOpConcept<_First, >> _Second>::__constraint >> s_() [with _First = llvm::BasicBlock, _Second = llvm::BasicBlock*]': >> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >> boost_concept_check.h:296 >> : instantiated from 'void __gnu_cxx::_EqualOpConcept<_First, &g...

...uld have expected that to suppress the following error: >> output: >> llvm[1]: Compiling BasicBlock.cpp for Release build >> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >> boost_concept_check.h: In >> member function 'bool __gnu_cxx::_EqualOpConcept<_First, >> _Second>::__constraint >> s_() [with _First = llvm::BasicBlock, _Second = llvm::BasicBlock*]': >> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >> boost_concept_check.h:296 >> : instantiated from 'void __gnu_cxx::_EqualOpConcept<_First,...

...S: I also tried to compile llvm 2.3 in MSYS using the latest MinGW with gcc 4.3.0. This wasn't able to compile llvm at all because some errors like: d:\msys\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/boost_concept_check.h: In member function 'bool __gnu_cxx::_EqualOpConcept<_First, _Second>::__constraints_() [with _First = llvm::BasicBlock, _Second = llvm::BasicBlock*]': d:\msys\bin\../lib/gcc/i386-pc-mingw32/4.3.0/include/c++/bits/boost_concept_check.h:296: instantiated from 'void __gnu_cxx::_EqualOpConcept<_First, _Second>::__constraints() [with _First...

...: Busy waiting only happens when the vq is full (i.e. no desc left). If necessary, I think we can add an input parameter like "bool busywaiting", then the caller can decide to simply get a -ENOSPC or busy wait to add when no desc is available. > > If you don't like my original _first/_next/_last, you will > need to come up with something else. I thought the above virtqueue_add_chain_des() performs the same functionality as _first/next/last, which are used to grab descs from the vq and chain them together. If not, could you please elaborate the usage of the original proposal...

...) using GCC 4.0.1 (on Fedora Core x86), and I noticed that llc hung in an STL iterator loop given trivial bytecode input (essentially a single function to add a couple of integers). The bytecode compiled fine from llvm assembly via llvm-as. The hang was in one of the STL destroy() loops; basically _first was ok (originated inside the bowels of a SetVector (Value*)), but _last was an at best undefined pointer (something like 0x013), so the loop would just chug along forever, and crash at some point I presume because it doesn't sound healthy to walk through the entire free store. Has anyone seen...

...e' make: *** [all] Error 1 > >>> output: >>> llvm[1]: Compiling BasicBlock.cpp for Release build >>> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >>> boost_concept_check.h: In >>> member function 'bool __gnu_cxx::_EqualOpConcept<_First, >>> _Second>::__constraint >>> s_() [with _First = llvm::BasicBlock, _Second = llvm::BasicBlock*]': >>> c:\mingw\bin\../lib/gcc/mingw32/4.3.0/include/c++/bits/ >>> boost_concept_check.h:296 >>> : instantiated from 'void __gnu_cxx::_EqualOpC...

Not that I sympathize with the OP's manners but... Bill Wendling <isanbard at gmail.com> writes: > On May 10, 2008, at 7:55 PM, kr512 wrote: > >> See how gcc is invoked to generate the final executable >> file. This means LLVM is an incomplete backend, >> unfortunately. >> > That's only a convenience. GCC generates assembly code too and calls

...ng. > > It won't work e.g. with the proposed new layout where > > writing out a descriptor exposes it immediately. > > I think it can support the 1.1 proposal, too. But before getting > into that, I think we first need to deep dive into the implementation > and usage of _first/next/last. The usage would need to lock the vq > from the first to the end (otherwise, the returned info about the number > of available desc in the vq, i.e. num_free, would be invalid): > > lock(vq); > add_first(); > add_next(); > add_last(); > unlock(vq); > > Howev...

...ng. > > It won't work e.g. with the proposed new layout where > > writing out a descriptor exposes it immediately. > > I think it can support the 1.1 proposal, too. But before getting > into that, I think we first need to deep dive into the implementation > and usage of _first/next/last. The usage would need to lock the vq > from the first to the end (otherwise, the returned info about the number > of available desc in the vq, i.e. num_free, would be invalid): > > lock(vq); > add_first(); > add_next(); > add_last(); > unlock(vq); > > Howev...

...t parameter like > "bool busywaiting", then the caller can decide to simply get a -ENOSPC > or busy wait to add when no desc is available. I think this just shows this API is too high level. This policy should live in drivers. > > > > If you don't like my original _first/_next/_last, you will > > need to come up with something else. > > I thought the above virtqueue_add_chain_des() performs the same > functionality as _first/next/last, which are used to grab descs from the > vq and chain them together. If not, could you please elaborate the >...

...t parameter like > "bool busywaiting", then the caller can decide to simply get a -ENOSPC > or busy wait to add when no desc is available. I think this just shows this API is too high level. This policy should live in drivers. > > > > If you don't like my original _first/_next/_last, you will > > need to come up with something else. > > I thought the above virtqueue_add_chain_des() performs the same > functionality as _first/next/last, which are used to grab descs from the > vq and chain them together. If not, could you please elaborate the >...

...ually it wasn't intended to improve performance. It is used to indicate > the "init" state > of the chain. So, when virtqueue_add_chain_desc(, head_id,..) finds head > id=INIT, it will > assign the grabbed desc id to &head_id. In some sense, it is equivalent to > add_first(). > > Do you have a different opinion here? > > Best, > Wei > It is but let's make it explicit here - an API function is better than a special value. -- MST

...ually it wasn't intended to improve performance. It is used to indicate > the "init" state > of the chain. So, when virtqueue_add_chain_desc(, head_id,..) finds head > id=INIT, it will > assign the grabbed desc id to &head_id. In some sense, it is equivalent to > add_first(). > > Do you have a different opinion here? > > Best, > Wei > It is but let's make it explicit here - an API function is better than a special value. -- MST