This failure is caused by a timeout when compiling the test. It passes when the timeout value is increased. These failures are caused by a lack of support/configuration for Boost.Tr1 The compiler does not support features that are essential for the library. The toolset is not supported by Boost.Regex. The test fail with ICE, but the exact reason for ICE is not known. A minimal example of casting any to reference type seem to work. Anyone interested in using this functionality with msvc is suggested to do additional testing. Compilers need to support partial template specialization to work with zero length arrays. This compiler does not support enable_if, which is needed by the Boost.System library on which Boost.Asio depends. On HP-UX 11.23 platform, these tests must be compiled with _XOPEN_SOURCE_EXTENDED macro defined. It is likely related to CR JAGag28813. The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions. This test could probably be made to work if somebody with knowledge about the compilers would submit a patch. The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions. The test could probably be made to work if somebody submitted a patch. The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions. The test depends on Boost.Pointer Container which probably does not work for this compiler. The test depends on Boost.Pointer Container which probably does not work for this compiler. The test depends on Boost.Pointer Container which probably does not work for this compiler. The test does not work for this compiler. The test depends on Boost.Tuple which probably does not work for this compiler. C++11 is the minimum requirement. The VC++ 6.0 backend runs out of internal resources while trying to process the Comeau output for this library; Comeau Computing has been asked about a solution. On the other hand, Comeau 4.3.3 with VC++ 7.0 backend works fine. Compiler bug. Time out. This failure is caused by Boost.Function. This failure is caused by a bug in the compiler triggered by the use of the debug flag '-gall'. It has been reported to the compiler vendor. This failure is only present in release mode and is caused by /OPT:ICF. Temporarily enabled and always failing test used for collecting additional feedback from the testing site. The compiler does not support features that are essential for the library. This version of the Rogue Wave library fails to provide all needed addition operators for the iterator type and the difference type of std::deque. Long double NaN's are apparently handled incorrectly on this platform. This failure is due to NaNs trapping. This failure is due to the compiler not recognising the long double special values for infinity and quiet NaN The compiler does not support features that are essential for the library. hash_value is not overloaded for arrays for older versions of Visual C++. There is a work around so that boost::hash<T[N]>, boost::hash_combine and boost::hash_range work. On these compilers the wrong overload of hash_value is called when the argument is a hash function pointer. So calling hash_value doesn't work but boost::hash does work (and it's recommended that user never call hash_value directly so this shouldn't be a problem). This platform has poor support for long double so the hash function perform poorly for values out of the range of double or if they differ at a greater precision that double is capable of representing. These examples only work on compilers with support for ADL. It is possible to work around this, but I wanted to keep the example code as clean as possible. It appears that Borland doesn't find friend functions defined in a class by ADL. This is easily fixed but this example is meant to show the typical way of customising boost::hash, not the portable way. The test demonstrates a Borland bug - functions that aren't in a namespace don't appear to be found by ADL. Debug containers aren't supported on Apple's version of gcc 4.2. The relevant SFINAE support is broken in MSVC up to version 11. This compiler does not support the is_abstract type trait Conversion double-string-double may give a different value (or even throw) on many compilers Some compilers and STL realizations convert double and long double types with bigger precision loss than minimal (or even round to infinity). Such failures are not a lexical_cast, but a compiler fault. On this compiler, Boost.Function gives a run-time error when calling non-nullary lambdas as used by the tests of this library to program contract failure handlers. It might still be possible to use this library on this compiler using default contract failure handlers or programming custom contract failure handlers but without using non-nullary lambdas (however, the authors did not confirm that). Even tests that do not use C++11 lambda functions fail on this compiler because it incorrectly attempts an extra copy when objects are constructed using `boost::check c = ...`. This is fixed in MinGW GCC 4.3. Even tests that do not use C++11 lambda functions fail on this compiler because of a number of issues (Boost.Exception is not supported on this compiler but it is used by this library implementation, some aspects of `friend` and `volatile` are not properly implemented on this compiler, etc.). These specific issues are fixed in MSVC 9.0 (but only MSVC 11.0 has adequate lambda function support that makes this library actually usable). This test fails on this compiler because of a bug with exceptions (see http://grokbase.com/t/gg/android-ndk/1656csqqtp/assertion-ttypeencoding-dw-eh-pe-absptr-unexpected-ttypeencoding-failed). This test fails on this compiler because of a bug in its STL implementation (undefined references to `std::ios_base::failure::failure`). This test fails because of a libcxxrt bug on Clang for FreeBSD which causes `std::uncaught_exception` to not work properly on re-throws (see https://github.com/pathscale/libcxxrt/issues/49). This test fails because this complier does not properly implement SFINAE giving incorrect errors on substitution failures for private members. This seems to be fixed in GCC 4.8 and MSVC 12.0. This test fails because SFINAE on this complier seems to not fail as it should when a derived class tries to call a protected member function on a base class object via a function pointer instead of via inheritance. This seems to be fixed in Clang 3.1, and to be specific to version 4.6 of GCC. This test fails because this compiler seems to incorrectly check access level of members in base classes in a context when only derived class members are used. This seems to be fixed in GCC 4.8 (possibly related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973). This test fails because `std::unchaught_exception` seems to always return zero on this compiler (even if the authors could not find a direct reference to this possible compiler issue online). This test fails because this complier seems to dispatch calls incorrectly when both `const` and `const volatile` overloads are present (even if the authors could not find a direct reference to this possible compiler issue online). This is fixed in MSVC 9.0 (but only MSVC 11.0 has adequate lambda function support). This test fails because MSVC 10.0 is not able to properly deduce a template specialization. This is fixed in MSVC 11.0. This test fails because of a MSVC 10.0 bug with lambdas within template class initialization list. This can be worked around using a functor bind instead of a lambda, but it is fixed in MSVC 11.0. This test fails because of a MSVC 10.0 bug for which lambdas cannot access typedefs declared within classes. This can be worked around declaring typedefs outside of classes, but it is fixed in MSVC 11.0. This test fails because of an internal MSVC 10.0 compiler bug. This is fixed in MSVC 11.0. The serialization library does not support this compiler. XML serialization is not supported on this compiler. The serialization library does not support this compiler. XML serialization is not supported on this compiler. These are strange runtime failures for which there is no obvious explanation. Later versions of the Intel compiler (eg:8.0) seem to have resolved the issue. For some reason Code Warrior has difficulty compiling some of the input code. This may be related to limitations of locale handling, but it's unclear at this time (2005-May-21). Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. There is apparently a bug in Borland library such that std::local_time and std::gmtime are returning a time that's 1 hour ahead GetSystemTimeAsFileTime during DST. This is a rather serious problem in that some of the date-time clock interfaces will give the wrong current time. The sun 5.8 compiler and standard library have a problem with the classic facet which causes some of the io tests for date-time to fail. Overall this should not affect most uses of the library. The STLPort standard library has issues with some custom facet settings causing an unexplained failure in these facet tests. The STLPort standard library has issues with the handling of the classic facet which causes some fo the i/o tests for date-time to fail. Overall this should not affect most uses of the library. MSVC 7.1 with its standard library passes all date-time tests. For some reason when paired with stlport a few widestream io tests do not format output correctly. Overall this should not affect most uses of the library. Although these tests compile, the execution aborts for an unknown reason. Note that sometimes the excution is ok on cw-9_4. This may be fixable if someone can track down the source of the problem. These tests are failing with the beta2 version of VC_8. At least one of them is directly a result of the new VC_8 standard library restricting the year value in a tm struct to be positive (that is greater than year 1900). This is a change from VC7_1 and Microsoft is considering removing this restriction. These tests are for serialization which has been marked as unusable. The issue was specifically noted on AIX version : 5.2.0.41 using IBM XL Version 8.0.0.0. The failure is caused by a standard library bug. It doesn't support user defined facets which are not default constructible. This has been reported to the compiler vendor. These tests rely on the ability of an std::map to be instantiated on an incomplete type. The Rogue Wave version 2.2 and higher does not allow this. The failure is caused by a standard library bug. It doesn't support user defined facets which are not default constructible. This has been reported to the compiler vendor. The failure is caused by a standard library bug. The end-of-stream istream iterator can only be constructed when the istream iterator has been instantiated with char as the character type. This has been reported to the compiler vendor. This indicates that forward declarations could probably be used for these compilers but currently aren't. All these compilers use STLport, which is compatible with forward declarations in some circumstances, but not in others. I haven't looked into how to determine this, so I've just set container_fwd to never forward declare for STLport. GCC's libstdc++ has a versioned namespace feature which breaks container forwarding. I don't know how to detect it so I'm just always disabling it, which means that a lot of setups which means that it's disabled for a lot of setups where it could work - which is what these failures represent. Failing because these tests are run with warnings as errors, and the standard library is causing warnings. STLport debug mode seems to be broken here. Some old versions of GCC's libstdc++ don't work on clang with _GLIBCXX_DEBUG defined. http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-May/015178.html The exact reason of this (linker related) bug is unresearched. The test passes on some environments. The test was found to fail on a platform whit a german version of the compiler. This compiler does not support enable_if, which is needed by the Boost.System library on which Boost.Filesystem depends. Due to standard library bugs this configuration is not supported by the most recent version of the library. Due to standard library bugs, this version is not supported. More recent version of the library should work OK. Due to lack of C library featues, this toolset is not supported. The library works well with versions of this compiler 5.9 and later fstream for this compiler has serious problems and is not supported The library does not support wide paths on this compiler because it does not support SFINAE. These failures are reported to be fixed in Sun's next compiler release. This compiler does not support Boost.Interprocess, on which intermodule_holder depends. This compiler does not support the Boost.Range library, on which Boost.Foreach depends. This compiler does not support detection of const rvalues. This compiler does not support detection of const rvalues. This compiler does not support detection of rvalues. This compiler does not support detection of rvalues. These compilers cannot handle BOOST_FOREACH in a template, where the collection type depends on a template parameter. This failure is because the Boost.Range extension mechanism is broken on these compilers. It requires ADL which these compilers do not support. The failure is caused by a standard library bug: the iostream components fail to handle ios::internal flag. Not all compilers/platforms implement nonstandard calling conventions.
With GCC/x86 this failure reflects http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29328 .
Not all compilers/platforms implement nonstandard calling conventions. Overload selection does not work in some assignment contexts with this compiler.
Probably broken const conversion with that compiler. This compiler is currently not supported. hash_value is not overloaded for arrays for older versions of Visual C++. There is a work around so that boost::hash<T[N]>, boost::hash_combine and boost::hash_range work. On these compilers the wrong overload of hash_value is called when the argument is a hash function pointer. So calling hash_value doesn't work but boost::hash does work (and it's recommended that user never call hash_value directly so this shouldn't be a problem). This platform has poor support for long double so the hash function perform poorly for values out of the range of double or if they differ at a greater precision that double is capable of representing. These examples only work on compilers with support for ADL. It is possible to work around this, but I wanted to keep the example code as clean as possible. It appears that Borland doesn't find friend functions defined in a class by ADL. This is easily fixed but this example is meant to show the typical way of customising boost::hash, not the portable way. The test demonstrates a Borland bug - functions that aren't in a namespace don't appear to be found by ADL. Debug containers aren't supported on Apple's version of gcc 4.2. The compiler doesn't generate defaulted move ctor/assgin thus perform copy construction/assginment. Even though such case, the `inline` versions don't force generating move ctor/assign to preserve trivial requirements. Since that is not documented behaviour, it might be changed in future release. These compilers do not support features that are essential for the library. Intel 11.1 and 12.0 on Darwin raises a SIGSEGV in almost all unit tests. Intel 13.1.3 does not support BOOST_TEST pgi 11.1 does not support BOOST_AUTO and is not configured for UBLAS This configuration is not well configured for UBLAS The compiler does not support features that are essential for the library. Compiler error expected for msvc: A minimal example of a class template 'value' that results in syntax error in a subsequent meta function. See ticket #5141 for details. When compiling with aC++, depending on system load, the compile time may exceed specified timeout value. The test passes when the timeout value is increased. When compiling with GCC, linker takes segmentation fault. In the HP bug tracking system, this issue is tracked as QuIX ID: QXCR1000836120. The compiler does not support features that are essential for the library. The compiler does not support features that are essential for the library. The compiler is not supported by Interprocess. This is gcc bug 26526, and is fixed in later releases. No bzip2 support on the testing machine and no way to disable this test with BBv2 at present. compiler can't compile "windows.h" in strict mode This platform lacks the placement delete operator required by the C++ standard These six tests pass individually but cause a compiler stack overflow when compiled as a group On this platform, linking this test takes longer than 10 minutes which is a time limit specified for bjam. When linked manually, the test succeeds. The test fails at runtime for unknown reasons. I'm not sure whether CodeWarrior is correct to report that the member in question is inaccessible; however, when the member is made public an internal error occur that I have not been able to fix, so for now the question is moot. The failure reflects a problem with the build system: the zlib object files are generated in the wrong directory. Memory mapped files are not supported in QNX Neutrino version 6.3.0. "restrict" is treated as a keyword on this platform (as in C99); use the alias "slice" instead, defined in "boost/iostreams/slice.hpp." In the Dinkumware standard library, streampos relies on fpos_t to store stream offsets, but fpos_t is defined as a 32-bit long by the Borland runtime library. In Borland's modified version of STLPort, streampos relies on streamoff to store stream offsets, but streamoff is defined to be a 32-bit long. In STLPort, streampos consists of a long together with a conversion state; on this platform, long is a 32-bit type On this platform, streampos is an alias for fpos, whose implementation stores stream offsets using streamsize and fpos_t; both of the latter types are 32-bit On this platform, streampos is an alias for ptrdiff_t, which is an alias for a 32-bit type The following applies only to gcc-4.2 using the stdcxx standard library: On this platform, streampos is an alias for ptrdiff_t, which is an alias for a 32-bit type Visual C++ 7.1's SFINAE implementation can't deal with multiple assignment functions with the same parameters (but disabled with SFINAE). So path's assignment from boost::filesystem2::path is disabled. Would be pretty easy to workaround, but probably not worth it since this is pretty obscure, and filesystem2 will be removed soon. C++11 is the minimum requirement. This test does not allow C++11 auto-declaration support (because it uses the `auto` keyword as storage classifier). The compiler fails to compile Boost.Move and Boost.PropertyTree, which are used by this library. Boost.Filesystem used by Boost.Log does not support Windows Mobile. The compiler does not support features that are essential for the library. The compiler is not supported by the library due to an utterly broken templates support. This failure is caused by a deficient SFINAE implementation; the bug was fixed in the next major compiler version (CodeWarrior 9.x). This failure is caused by a deficient SFINAE implementation. This failure is caused by a problem with recursive templates and default template parameters, fixed in Update 2. This failure is caused by a lack of compiler support for template template parameters. This is an advanced functionality that hasn't been ported to the deficient compilers (yet). Patches are welcome! This is an advanced functionality that hasn't been ported to the deficient compilers (yet). Patches are welcome! This is a regression in the gcc 4.1 series that has been fixed in gcc 4.2.0. See bug #28088 for details. This is reported to be fixed in the next Sun compiler release.

This library has never worked [on Borland 5.5.1 and 5.6.4], and the only tests that 'pass' are compile-fail tests failing for the wrong reasons!

Known error in MSVC. see http://boost-consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_60 for more information.
The VC++ 6.0 backend runs out of internal resources while trying to process the Comeau output for this library; Comeau Computing has been asked about a solution. On the other hand, Comeau 4.3.3 with VC++ 7.0 backend works fine. This error shows when using the dynamic version of the STLport library. The problem is reportedly fixed in STLport 5.0 (in beta stage as of this writing.) This test fails due to limitations of the template instantiation model used in the testing environment (-timplicit_local) resulting in erroneous duplication of some function-static variables. The test passes with other template instantiation models.

These compilers are too antiquated for this library.

These compilers don't quite have the necessary support for this library, it's possible that they could be made to work if someone cares enough.

This failure is caused by a test-runner timeout: unfortunately the Intel compiler is exceptionally slow at building some of these tests. This failure is caused by a test-runner timeout.

This is a compiler bug: it sometimes creates an illegal temporary object. The following code illustrates the bug:

		#include <cassert>
		const int global_i = 0;
		
		struct TestingReferenceBinding
		{
		  TestingReferenceBinding(const int& ii)
		  {
		    assert(&ii == &global_i);
  		  }
		};
		
		int main()
		{
		  TestingReferenceBinding ttt = global_i;
		}
                

This failure is caused by a compiler bug, and as far as we can tell, can't be worked around in the library, although we think the library might be made safer with respect to this bug.

Specifics: the following simple test fails when it should succeed.

                #include <cassert>

                int const x = 0;
                struct A
                {
                   A(int const& y)
                   {
                     assert(&x == &y);
                   }
                };

                int main()
                {
                    A a(x);  // direct initialization works fine
                    A b = x; // copy initialization causes x to be copied before it is bound
                }
                
The possible safety enhancement would be to cause the constructor in question to be explicit for optional<T const&>; that would prevent copy initialization.
Complete C++14 support is the minimum requirement. libstdc++ 6 is the minimum version which works. Wrokaround: define BOOST_RESULT_OF_USE_TR1 Compiler's too old for working. C++11 or later required. The test is exposing the following known error of Sun Studio 11: overload resolution fails if a) some class has a conversion operator to a reference to a built-in type, and b) overload resolution involves a user-defined operator as well as a built-in operator, and c) the built-in operator takes the result of the conversion mentioned in a) as an operand. A fix will be reportedly included in patch no 6 of Sun Studio 11. This error shows when the code has become too complex for the compiler to handle. The problem has no relationship with the functionality being tested, which in fact does work for MSVC++ 7.0. msvc 6 compiler failure. The facility being tested conflicts the the compiler in a fundamental way and cannnot be worked around. msvc 6 compiler failure. The facility being tested conflicts the the compiler in a fundamental way and cannnot be worked around. This failure appears when STLPort is built and used as a DLL with msvc 6. STLPort suggests that the next version of STLPort(5.0) will include a workaround for this problem. The library is believed to work in this configuration if compiled against Spirit 1.6. The latter is not provided by the particular testing environment these tests have been run in. All tests that serialize derived pointers currently fail with Metrowerks compilers. The CW compilers have problems with the static construction idiom used to implement the type registration in the Boost.Serialization library. In many cases CW specific work arounds are implemented in the library but this one is not immediately solvable. There is a user work around possible, please contact the library developers on the Boost list for information on the work around if needed. The variant library is not supported for this compiler version. Therefore serialization of variants doesn't work. The compiler fails with an error supposedly related to std::fpos<>::_Stz from the <iosfwd> header. It is not known what causes the compiler to instantiate this field and what causes the instantiation to fail.

Historically, Spirit supported a lot of compilers, including (to some extent) poorly conforming compilers such as VC6. Spirit v1.6.x will be the last release that will support older poorly conforming compilers. Starting from Spirit v1.8.0, ill conforming compilers will not be supported. If you are still using one of these older compilers, you can still use Spirit v1.6.x.

The reason why Spirit v1.6.x worked on old non-conforming compilers is that the authors laboriously took the trouble of searching for workarounds to make these compilers happy. The process takes a lot of time and energy, especially when one encounters the dreaded ICE or "Internal Compiler Error". Sometimes searching for a single workaround takes days or even weeks. Sometimes, there are no known workarounds. This stifles progress a lot. And, as the library gets more progressive and takes on more advanced C++ techniques, the difficulty is escalated to even new heights.

Spirit v1.6.x will still be supported. Maintenance and bug fixes will still be applied. There will still be active development for the back- porting of new features introduced in Spirit v1.8.0 (and Spirit 1.9.0) to lesser able compilers; hopefully, fueled by contributions from the community. For instance, there is already a working AST tree back-port for VC6 and VC7 by Peder Holt.

This failure is caused by a compiler bug that manifests itself in the particular environment/hardware configuration the test has been run in. You may or may not experience this issue in your local setup. With GCC 3.4.6 the test fails with ICE: internal compiler error. The footprint is similar to that in GCC Bugzilla Bug 34950 except 34950 is a regression introduced in GCC 4.2.3. In any case, whatever the problem is, the GCC 4.x series does not seem to have it: the test compiles just fine with GCC 4.x compiler.
This compiler is not supported. Native mode is not supported for this compiler. Emulation mode is not supported for this compiler. The feature is not supported by this compiler. The feature is not supported by this compiler. The feature is not supported by this compiler. This failure is caused by a compiler bug. Templated operators that combine different iterators built with iterator_facade or iterator_adaptor may be present in an overload set even when those iterators are not interoperable. The usual result is that error messages generated by illegal use of these operators will be of lower quality. This failure is caused by a compiler bug. is_convertible<T,U>::value may be true for unrelated iterators T and U (including many of the Boost specialized adaptors) which use enable_if_convertible to restrict the applicability of converting constructors, even when T is not convertible to U because instantiating the conversion will cause a compilation failure. This failure is caused by a compiler bug. The compiler tends to drop const-ness and as a result some indirect_iterators will have pointer and reference members of T* and T& that should have been T const* and T const&. For some currently unknown reason, with aCC, this test can be compiled only in strict ansi mode. Since on HP-UX/aCC boost testing is done in the default compilation mode, this test fails to compile on this platform. Sadly Borland-5.9.2 has an even harder time compiling this library than earlier versions did. There are currently too many issues to stand a chance of porting to this compiler. This test relies on external software being installed in order to pass. This compiler is not sufficiently conforming to correctly handle these tests. Some versions of the Darwin platform have insufficient long double support for us to be able to run this test. This test takes too long to build for this compiler and times out. This is a compiler bug: it is unable to use SFINAE to detect the presence of specific member functions. This is a compiler bug: it is unable to resolve the overloaded functions. This test takes too long to execute and times out. These tests fail with an internal compiler error: there is no known workaround at present, except to use Sun-5.9 which does build this code correctly. This compiler is not sufficiently conforming to correctly handle these tests. This compiler is not sufficiently conforming to correctly handle these tests. There appears to be a bug in gcc's std::exp (long double) on this platform. For some reason taking the address of std library math functions fails on this platform: this is a problem for our test code, not the library. This compiler is not sufficiently conforming to compile these tests. std::numeric_limits<long double>::infinity() is apparently broken in this compiler: it's filed as bug 6347520 with Sun. Incomplete std::complex support make these tests pointless (the complex trig functions are absent). These have yet to fully investigated, but the code is known to compile with more conforming compilers, probably workarounds are possible if someone is prepared to invest the time. Appears to be a bug in STLport's complex abs function, but needs more investigation. This appears to be a problem with STLPort's abs function: the issue only effects the test code. A workaround should be possible but users should be encouraged to use STLport 5 instead. No true long double standard lib support causes these tests to fail. This is Intel issue 409291, it should be fixed from compiler package l_cc_c_9.1.046 onwards. This failure appears to be caused by a compiler bug: please note that the issue only effects the test suite, not the library itself. A workaround is available but breaks other compilers. This test ensures the inclusion property of interval arithmetic is available for built-in floating-point types float and double. If the test fails, interval<float> and interval<double> should not be used on this compiler/platform since there will be no numerical guarantee. This compiler has some problems with name looup / overload resolution. This failure is unresearched. Presumably, the problem is that the abs function is not available in the "right" namespace with this compiler/stdlib combination. This old version of the stlport library causes the BOOST_NO_STDC_NAMESPACE macro to be set. But this conflicts with the requirements of the library. The failure is caused by standard library deficiencies -- it lacks the basic_string class template and the <locale> header. The failures are caused by problems with std::locale implementation The failures are caused by compiler bug: it's not possible to explicitly pass template arguments to member template function. The failure is serious and makes one of the primary interfaces unusable. Several compiler bugs were worked around in order to get this test to pass, so it could be considered to be only partially working. However, the library's macro system, which is really being tested here, does work on this compiler, which is why we worked around the failures. Please see the test's source file for details. These compilers do not support SFINAE, so are expected to fail this test. Borland does not support this feature. A compatibility syntax might be developed later on. This feature generally requires advanced compiler features not supported by these compilers. It might be possible to work around the issue on VC6/7, but at this time no such workaround has been done. This is old and should not be tested any more. These test failure are reported to be under investigation at Sun's compiler labs. Inherited from MultiIndex Lots of test failures complaining about the ambiguity of a const and a non-const overload of the same function. This compiler seems to have very broken name lookup. Tend to crash the compiler (Intel 10) or simply take too long (Intel 11). This ancient GCC doesn't like local const ints as template parameters. Or something like that. The error is due to problems in the standard library implementation. It should be fixed in newer versions of the compiler. The error is due to problems in the standard library implementation. It should be fixed in newer versions of the compiler. This error seems to be a bug the compiler. Please submit a patch. This error seems to be a bug the standard library. Please submit a patch. This test fails because the test ptr_vector fails. Please see the note for that test. For sun the problem is that insert(iterator,range) is not available due to partial ordering errors (the core library remains usable). For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable). For sun the problem is that insert(iterator,range) is not available due to partial ordering errors (the core library remains usable). For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable). For sun the problem is that insert(iterator,range) is not available due to partial ordering errors (the core library remains usable). For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable). For hp, this compiler bug is insignificant. For sun the problem is that transfer(range,ptr_map) is not available due to partial ordering errors (the core library remains usable). For codewarrior the problem is not known so please submit a patch. For sun the problem is that transfer(range,ptr_map) and insert(range)code> is not available due to partial ordering errors (the core library remains usable). For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable).. For codewarrior, the cause of this problem is unknown. Please submit a patch. Other failures are due to problems with the serialization library, or to a minor problem with the use of the library. For sun the problem is due to Boost.Test. Seem like a bug in the compiler. Please submit a patch. Seem like a bug in the compiler. Please submit a patch. The library fails to compile because of an error in the C++ standard library implementation on this platform. It incorrectly assumes that fpos_t is of an integral type, which is not always the case. This is fixed in a later release. The old reasoning given for this markup, which applied to sun-5.8*, was as follows. However, tuple's tests seem to use the test library, which is apparently completely broken on Sun. Therefore, I've backed off the version number to sun-5.6 so I can see the actual state of the failures.
This compiler seems to be having trouble digesting Boost.Tuple. Until it can handle Boost.Tuple there's little chance it will handle Boost.Python
This compiler has a bug that causes silent misbehavior at runtime when each of an assignment expression follows one of the following patterns: expr.attr(name) or expr[item], where expr is-a boost::python::object. We've been unable to find a workaround. The problems with GCC 2.x only occur when C++ exceptions are thrown and the framework catches them, which happens quite often in the tests. So technically GCC 2.x is usable if you're careful. This test assumes standard-compliant dependent template name lookup which is performed by aCC6 only in strict ansi mode. Since on HP-UX/aCC6 boost testing is done in the default compilation mode, this test fails to compile on this platform (in strict ansi mode, it compiles and succeeds).
Unsupported compiler C++11 mode (or later) required Reported to Intel as issue 409291, and confirmed as a problem. Probably this relates to a specific Linux-Kernal or GLibC version. Test fails with ranlux*_O1 RNGs when saving and recalling the state due to a bug in the double to string conversion. The problem has been reported to QNX as PR29252. This test fails because of limitations in the system assembler version used by GCC. It most probably would pass if the test were split into multiple source files. It looks like a compiler issue: the test fails with gcc 3.4.6 and succeeds with gcc 4.2.1. This test is designed to give users visibility of the ADL problems with their compilers. Lack of Argument Dependent Lookup changes how one can extend the library. The lack of ADL is worked-around internally so that most of the functionality is preserved. For most compilers this is due to problems with built-in arrays (notably char arrays) and operator==() and operator!=() for iterator_range. Thus, not using built-in arrays fixes the problem. For other compilers it is simply a bug in the standard library. push_front fails the unit test in this configuration. I do not have this configuration available to determine if a work-around is possible. This test probably fails because it uses built-in arrays. So do expect these functions to work in normal code. The string functionality is expected to work if the user employs std::string and stays away from built-in arrays. For most compilers this is due to problems with built-in arrays (notably char arrays) and operator==() and operator!=() for iterator_range. Thus, not using built-in arrays fixes the problem. At the time of release I couldn't figure out why this was failing. Anyway, the failure is not very important; also, the well-definedness of "singularity" of an iterator range is likely to change. The test requires support for Argument Dependent Lookup (ADL) which the compiler in question does not provide. The compiler does not support features that are essential for the library. internal error: assertion failed: copy_template_param_expr. It seems to be already an Intel internal bug database (tracker number #82149). I have no workaround yet. The compiler does not support features that are essential for this test . No Wide character support on this platform. No Wide character support on this platform. This test requires features that are unsupported by Como: use and building of dll's mainly. This test requires features that are unsupported by Como: use and building of dll's mainly. This tests fails because a dependency (Boost.Test) fails to initialise correctly. The issue has been reported to the library's author. GCC on tru64 appears not to cope with C++ exceptions thrown from within threads. This test fails because a dependency (Boost.Program Options) doesn't build with this compiler. This test fails because a dependency (Boost.Program Options) which currently doesn't build with this compiler. There appears to be a linker bug that prevents these projects from building, see http://qc.borland.com/wc/qcmain.aspx?d=32020. There appears to be a linker bug that prevents these projects from building, see http://qc.borland.com/wc/qcmain.aspx?d=32020. Test fails due to unresilved externals from STLport: appears to be an STLport bug. These tests pass when run directly from the command line, but fail when run under the regression test script. The issue has never been fully pinned down, but appears to be related to how long the tests take to run. The test does not compile in typeof emulation mode, most likely due to a compiler bug. Users are advised to use native typeof. This compiler does not support native type-of (force type-of emulation mode defining the BOOST_TYPEOF_EMULATION macro). A runtime failure of this test indicates that this platform dynamically links code in a manner such that under certain circumstances more than one instance of a header-defined static class member can exist at runtime. See FAQ for more information. This test runs without problem on Borland compilers, which means the static assertion is not being caught. This compiler does not support enable_if, which is required by Boost.System. The test verifies that Boost.Test detects division by zero. It fails on PowerPC, PA-RISC and Linux ia64. On PowerPC processors, division has an undefined result. The compiler has to emit extra code to assert that the divisor isn't zero. Compiler options -fno-trapping-math and -fnon-call-exceptions might affect this. However, in default configuration no check is done, and division by zero is not detected. The test appears to test that failed assertion result in non-zero exit status. That seems to be not the case, for unknown reasons. On HP-UX platform, this test must be compiled/linked in multithread mode. When compiled/linked with aC++ with -mt, it succeeds. When compiled/linked with GCC with -pthread, it links cleanly but fails in run-time. This failure is caused by a conflict between the compiler and the testing environment: the tests are run on a platform with too recent version of glibc, which is not currently supported by the compiler vendor (Intel). If you are having the same problem and really want to make things work, renaming strol symbol in the compiler's static runtime library (libcprts.a) to something else is known to resolve the issue. When a thread ends, tss data needs to be cleaned up. This process is mostly automatic. When threads are launched by the Boost.Thread API cleanup is handled by the library implementation. For threads, launched by the native operating system API it is not possible to get this cleanup on every compiler/platform. A warning (error) will be present in this case, which cleary states this fact. It is recommended to start threads only by means of the Boost.Thread API if you need to avoid the leaks that appear on the end of the thread. If this is not possible the cleanup can be invoked from user code before the process actually ends. For library implementors this means to call these functions during library initialization and finalization. The Borland compiler and HP-UX aC++ compiler in default mode fail to bind rvalues to the thread move constructor, choosing instead to bind them to the private (and unimplemented) copy constructor. With aC++, the tests compile cleanly in strict ansi mode and succeed. These tests will fail in most compilers that don't support rvalue references. The implementation of native_handle() is not possible on this platform. The implementation of native_handle() is not possible on this platform. This platform doesn't supports Boost.Chrono. This platform doesn't supports Boost.Container. These are all failures with Boost.FunctionTypes which TTI uses. SFINAE for the constructors of param doesn't work correctly on this compiler. This affects free functions (including operators) with more than one any argument and overloaded member functions. This looks like an instance of MSVC substituting int in a template-id. Classes with exactly the same names defined in different modules in anonymous namespaces collapse for this compiler even with RTTI on. This is a known compiler limitation that already fixed in newer versions or will be fixed soon. Classes with exactly the same names defined in different modules in anonymous namespaces collapse for this compiler with RTTI off. This is a known limitation of RTTI-off mode. Such behavior is reflected in docs. Type Traits tests are run with warnings-as-errors and GCC 3.x emits warnings with this test that I haven't been able to suppress. Apparently the compiler can't cope with these - later versions are fine though. Probably work-round-able if someone would care to look into these. This failure is caused by the lack of compiler support for class template partial specialization. A limited subset of the tested functionality is available on the compiler through a user-side workaround (see http://www.boost.org/libs/type_traits/index.html#transformations for details). See bug 99776 'enum UIntEnum { value = UINT_MAX } is promoted to int' http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=22b0a6b7-120f-4ca0-9136-fa1b25b26efe https://developercommunity.visualstudio.com/content/problem/490264/standard-violation-enum-underlying-type-cannot-rep.html This functionality is available only on compilers that implement C++ Core Language Defect Report 337. The Type Traits library is broken when used with Sunpro-5.3 and the argument to the template is an array or function type. Most other argument types do work as expected: in other words the functionality is limited with this compiler, but not so much as to render the library unuseable. The Type Traits library is broken when used with Sunpro-5.8 and the argument to the template is a function type. Most other argument types do work as expected: in other words the functionality is limited with this compiler, but not so much as to render the library unuseable. This fails with an internal compiler error, there is no workaround as yet. Older versions of MWCW incorrectly align pointers to member functions (they use 12-byte boundaries, rather than a power-of-2 boundary), leading to alignment_of / aligned_storage to fail with these types on this compiler. VC6/7 has a buggy using declaration syntax which basically makes it impossible to implement the namespace forwarding that this library relies upon. See KB article 263630 here: http://support.microsoft.com/default.aspx?scid=kb;en-us;263630 Metrowerks Codeworrier has partial TR1 support built in which conflicts with this implementation. Porting to this compiler is almost certainly possible, but will require some work by someone who has this compiler. Later versions of MSVC are required for these tests - the issues may be work-round-able if anyone cares enough to look into them. These tests test features that are not supported in the current Boost implementations of TR1 components, they will currently fail on all compilers, unless that compiler has native TR1 support. MSVC 9.0 with the optional feature pack installed includes a version of the TR1 libraries that is not as interface-conforming as the Boost version. Most of these failures are of the "annoying" rather than "unusable" kind. These tests fail on this platform due to a lack of wide character support. These tests fail due to a lack of adequate long double std math lib support. These tests fail on this platform due to incomplete wide character support. These tests fail on this platform due to incomplete wide character support. Support for Borland C++ in the various TR1 libraries is pretty poor (due to numerous compiler bugs sadly). The TR1 concept checks are *very* strict, and are expected to fail with this compiler. In addition most of the type_traits tests fail whenever debugging support is turned on with an internal compiler error. More conservative uses are more likely to succeed with this compiler however. Support for Borland C++ in the various TR1 libraries is pretty poor (due to numerous compiler bugs sadly). The TR1 concept checks are *very* strict, and are expected to fail with this compiler. More conservative uses are more likely to succeed with this compiler however. These tests fail on this platform due to a recuring GCC bug. These tests fail due to a known compiler bug that is fixed in more recent GNU compiler releases. Users are very unlikely to encounter this as a real problem in practice. These tests fail due to a known compiler bug that is fixed in more recent releases. Users are very unlikely to encounter this as a real problem in practice. These tests fail due to a known compiler bug that is fixed in more recent releases. This functionality may not be usable with this compiler. These tests fail due to a known stdlib bug that has been reported to the vendor. This failure is caused by the lack of compiler support for class template partial specialization. A limited subset of the tested functionality is available on the compiler through a user-side workaround (see http://www.boost.org/libs/type_traits/index.html#transformations for details). This functionality is available only on compilers that implement C++ Core Language Defect Report 337. The Type Traits library is broken when used with Sunpro-5.3 and the argument to the template is an array or function type. Most other argument types do work as expected: in other words the functionality is limited with this compiler, but not so much as to render the library unuseable. The Type Traits library is broken when used with Sunpro-5.8 and the argument to the template is a function type. Most other argument types do work as expected: in other words the functionality is limited with this compiler, but not so much as to render the library unuseable. These failures appear to represent a genuine issue with the Boost.Random library that has yet to be addressed. These fail with an internal compiler error: there's no workaround as yet. This fails with an internal compiler error: there's no workaround as yet. These failures are completely spurious: they're caused by the tests being run with bjam -j2 and the post-processing not coping with the resulting output. These failures should clear if these tests are re-run at some point in the future. This library is almost unusable with VC7 due to name lookup issues. Older versions of MWCW incorrectly align pointers to member functions (they use 12-byte boundaries, rather than a power-of-2 boundary), leading to alignment_of / aligned_storage to fail with these types on this compiler. This tests whether inserting elements creates as few copies as I think is possible. If this fails it just means that the container might be a little inefficient. This test fail because it's using unordered's internal allocator traits, which doesn't work on Visual C++ 7.1. It normally uses the one from Boost.Container by default. boost::is_nothrow_move_constructible and boost::is_nothrow_move_assignable don't seem to work on this compiler. I'd hope that anyone wanting noexcept support would use a more recent compiler anyway. The definition of a custom template specialization of std::swap appears to trigger an internal compiler error ("Fatal F1004") on CodeGear 6.10.0 (formerly named Borland), as I reported, with help from Nicola Musatti and David Dean. Related Boost mailing list discussion: http://lists.boost.org/Archives/boost/2008/11/144465.php CodeGear bug reports on this issue: http://qc.codegear.com/wc/qcmain.aspx?d=68959 http://qc.codegear.com/wc/qcmain.aspx?d=69196 Borland 5.9.3 has an error (E2285) when trying to pass a multi-dimensional array by reference to a function template. A bug report by Christopher Yeleighton appears related: "The compiler obligatorily converts member arrays to pointers" http://qc.codegear.com/wc/qcmain.aspx?d=10267 Compiler has a problem with BOOST_STATIC_CONSTANT in nested templates inside class template specializations. When I made the conversion from value_initialized<T> to T& const-correct, this specific compiler version gave compile errors. See also: Ticket #2548 - "Let's fix the logical constness of value_initialized!" This failure is caused by a compiler bug (default-constructed scalar types are not zero-initialized) that has been fixed in the latest versions of the compiler (VC 7.1 and greater). The test takes more that 30 minutes to compile and the compilation is automatically killed. It is likely caused by the compiler bug, but it unknown how much this bug affects regular use of the operators library. Is it also unknown if the test can be refactored so that not to trigger this bug. The test relies on Boost.Serialization which is not supported on this toolset. The test relies on Boost.Random which is not supported on this toolset. The test relies on Boost.Iterator (iterator_facade) which is not supported on this toolset. This toolset isn't supported because of the used Spirit V1.8.x, which in turn is not usable with this toolset. This toolset isn't supported because of the used multi_index library, which in turn is not usable with this toolset. These compilers do not support class template partial specialization. Boost.Proto doesn't work on this compiler. This compiler doesn't support SFINAE / enable_if Digital Mars cannot seem to handle dependent default template parameters, such as "template < class T, bool B = is_foo < T > ::value >" Boost.Proto doesn't work on the cray compiler. Boost.Proto doesn't work on the vacpp compiler. This library is unusable due to bug #5373 in Boost.Thread on this compiler. Windows Mobile lacks essential features of the standard C library like gmtime, mktime, localtime making it impossible to use Boost.Locale on this platform. Compiler does not support shared runtime linking thus is makes it problematic to use Boost.Locale as dll Problems with wide file stream I/O. Currently unresolved due to lack of access to the compiler. This test fails only intermittently. The failure is caused by a problem in Boost code. The Boost developers are aware of the problem and plan to fix it. The failure is caused by a compiler bug. The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them). The failure is caused by a standard library bug. The failure is caused by a standard library bug, which has been reported to the standard library supplier (or is already known to them). The failure is probably caused by the test code, harness, or configuration. Thus, it may not affect users of the library. The failure is serious and likely to prevent all use of this Boost library with this compiler. The failure is serious and likely to prevent all use of this Boost library with this compiler. The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them). The failure is caused by a platform API bug. The failure is caused by a platform API bug, which has been reported to the platform API supplier (or is already known to them). The failure is not serious and will not affect most users. The library degrades gracefully. This compiler's bugs are not supported by the library. Locales missing or adequately supported by this compiler. Missing or inadequate wchar/wstring/wstream support for this compiler. No std iterator traits for this compiler. Library has limited input/output support due to compiler inadequacies. No high precision clock for this platform. A bug in standard library prevents passing std::set from DLL to application. A fixed <tree> header is available from http://www.dinkumware.com/vc_fixes.html. Although the documentation from the Comeau website would make it appear that windows DLL's are supported using the --windows option, after some experimentation we have been unsuccessful in making dll configurations work correctly. The failure is caused by a runtime limitation. Locale support is only available with the static linked variant of the runtime. Generally the dynamic linked variant is required when building dynamic modules, DLL, so, etc. This failure is caused by a compiler bug with no known workaround. Patches are welcome! This failure is caused by bugs in the standard library implementation and/or bugs in the compiler. Unresearched failure -- please contact library developers for more information about possible causes. The test fails due to unresearched issues. The library developers are aware of this failure, but need help with investigating/addressing it for future releases. The support for this deficient compiler will be dropped starting from Boost 1.33.0 release. Please use one of the previous Boost releases if you need the library to work on this compiler. This failure is caused by compiler bugs or limitations. Some advanced or esoteric library features may be unavailable or only partially available. This does not impact most common uses of the library. This failure is caused by a compiler bug. Certain code constructs that should fail compilation are accepted by the compiler. This can mask some programming errors, but does not impact the usability of the library. The failures are caused by the wrong handling of the std::internal flag in the iostreams implementation of the standard library used on that compiler/platform combo. Apart from that, the format library works as expected. The failures are caused by the fact that the iword and pword arrays seem to share the same memory area in the iostreams implementation of the standard library used on that compiler/platform combo. As long as you stay clear of iword and pword, the library should work ok. This failure occurs only when using shared libraries for this compiler and platform, although the same programs should work properly when using static libraries. This problem has not been researched. Wide character support is disabled in the GNU Standard C++ library as supplied on the QNX Neutrino version 6.3.0 distribution. This problem is due to the non-conforming STLport implementation of vector's swap: it can be easily reproduced with the following code snippet: typedef std::vector<int> vector_type; typedef vector_type::reference reference_type; vector_type v1(4u, 1); vector_type v2(7u, 0); reference_type ref = v1[2]; int x = ref; std::swap(v1, v2); BOOST_CHECK(v2[2] == x); // ok v2[2] = 1 - v2[2]; BOOST_CHECK(ref != x); // oops When compiling this test, aCC6 runs out of memory. The HP compiler group is aware of this issue and is working on the fix. This test assumes native typeof support. This test assumes compiler support for rvalue references. These tests rely on the ability of an std::deque container to be constructed off two input iterators. Unfortunately, the Rogue Wave library version 2.2 and higher assumes iterator which has + and - operators which only random access iterator is required to provide. Internal compiler error: GCC Bugzilla Bug 33580. This is a regression in the gcc 4.2 series. These test failures are reported to be under investigation at HP's compiler lab. This compiler does not support gcc stdcall function attribute. The Rogue Wave standard library version used by this compiler provides a faulty vector<bool> iterator, which is not symmetric. There is an associated bug report in the Rogue Wave bug tracking system for this problem. The test does not compile, most likely because of new version of EDG Front End implementing Core Issue 574. In the HP bug tracking system, it is tracked as QuIX ID: QXCR1000804484. Depending on system load, the compile time may exceed specified timeout value. The test passes when the timeout value is increased. This test fails when BOOST_UBLAS_NO_NESTED_CLASS_RELATION is defined. This test fails because MinGW apparently does not always catch exceptions properly. This test requires variadic macro support. This test requires lambda function support. This test has not been updated to accomodate changes in Boost.Random.