search for: boost_concept_check

...ping it was something easy to fix on the compiler, since it compiles fine on Leopard. When assertions are disabled I get this error: llvm[1]: Compiling IntrinsicInst.cpp 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/Greybi...

...zed --disa >> ble-shared --disable-multilib --disable-asserts >> Ok...I would 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...

...T for development on windows. Built with "C:/MinGW/bin/sh.exe"-2.04$ ./configure --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::...

...This is free software; see the source for copying conditions. There is NO warranty; 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::_...

...lt with "C:/MinGW/bin/sh.exe"-2.04$ ./configure --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 > : instantiate...

I fixed my immediate problem by using a different version of gcc. Chris Lattner kirjoitti: > The offending line of code looks fine on our side, > but there could be something I'm missing. For what it is worth, I've run into problems with boost_concept_check before when using Boost.Python. Some versions of gcc worked fine, while others gave error messages relating to boost_concept_check. My guess is that it is due to some slight differences in how templates are instantiated in different versions of gcc. -- Pertti

.../sh.exe"-2.04$ ./configure --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 &gt...

...m to make it a full backend (with the final result an exe or dll file). Razvan PS: 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:...

Hello all, I am trying to build llvm 1.8a with gcc 4.1.1 and I get the attached error. Are there any easy workarounds or should I just try another version of gcc? -- Pertti -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: build-error URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060901/350fb4a1/attachment.ksh>

On Fri, 1 Sep 2006, [ISO-8859-1] Kellom�ki Pertti wrote: > I am trying to build llvm 1.8a with gcc 4.1.1 and I get the attached error. > Are there any easy workarounds or should I just try another version of gcc? I haven't seen this error, but I'm not using GCC 4.1.1. It would be good to track this down and either file a bug with GCC or for us to get it fixed in LLVM. The

...i wrote: > I fixed my immediate problem by using a different version > of gcc. ok. > Chris Lattner kirjoitti: >> The offending line of code looks fine on our side, >> but there could be something I'm missing. > > For what it is worth, I've run into problems with boost_concept_check > before when using Boost.Python. Some versions of gcc worked fine, > while others gave error messages relating to boost_concept_check. > My guess is that it is due to some slight differences in how templates > are instantiated in different versions of gcc. Okay. Question: does GCC 4....

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