organicmaps/boost
13
Fork 0
mirror of https://github.com/boostorg/boost.git synced 2025-04-04 13:05:00 +00:00
Code Issues 1 Projects Releases Wiki Activity Actions
boost/status/explicit-failures-markup.xml
Douglas Gregor bebd91dc9e Merged from 1.33.0 release 
[SVN r30540]
2005-08-12 13:02:37 +00:00

3242 lines
126 KiB
XML
Raw Blame History

<explicit-failures-markup
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="explicit-failures.xsd"
>
<!--
PLEASE VALIDATE THE XML BEFORE COMMITTING YOUR CHANGES!
The following online services can be used to validate your changes to this file:
- http://apps.gotdotnet.com/xmltools/xsdvalidator/
When using the gotdotnet tool you need to provide both the explicit-failures-markup.xml
file as the XML document and the explicit-failures.xsd as the schema document. Use the
browse buttons to select them from your local hard drive.
- http://tools.decisionsoft.com/schemaValidate.html
-->
<!-- /////////////// Toolsets /////////////// -->
<mark-toolset name="borland-5_6_4" status="required"/>
<mark-toolset name="cw-9_4" status="required"/>
<mark-toolset name="cw-8_3" status="required"/>
<mark-toolset name="cw-9_5-darwin" status="required"/>
<mark-toolset name="msvc" status="required"/>
<mark-toolset name="msvc-stlport" status="required"/>
<mark-toolset name="vc7" status="required"/>
<mark-toolset name="vc-6_5" status="required"/>
<mark-toolset name="vc-6_5-stlport" status="required"/>
<mark-toolset name="vc-7_0" status="required"/>
<mark-toolset name="vc-7_1" status="required"/>
<mark-toolset name="mingw-3_4_2" status="required"/>
<mark-toolset name="gcc-2.95.3-linux" status="required"/>
<mark-toolset name="gcc-2.95.3-stlport-4.5.3-linux" status="required"/>
<mark-toolset name="gcc-2.95.3-stlport-4.6.2-linux" status="required"/>
<mark-toolset name="gcc-3.2.3-linux" status="required"/>
<mark-toolset name="gcc-3.3.6-linux" status="required"/>
<mark-toolset name="gcc-3.4.4-linux" status="required"/>
<mark-toolset name="gcc-4.0.0-linux" status="required"/>
<mark-toolset name="gcc-4.0.1-linux" status="required"/>
<mark-toolset name="gcc-3_3-darwin" status="required"/>
<mark-toolset name="gcc-3_4_3-sunos" status="required"/>
<mark-toolset name="intel-win32-8_1" status="required"/>
<mark-toolset name="intel-win32-9_0" status="required"/>
<mark-toolset name="intel-8.1-linux" status="required"/>
<!-- /////////////// Libraries /////////////// -->
<!-- minmax -->
<library name="algorithm/minmax">
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
</mark-unusable>
</library>
<!-- string_algo -->
<library name="algorithm/string">
<mark-unusable>
<toolset name="borland"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="iw-7_1-vc6"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="mipspro"/>
<toolset name="sunpro-5_3-sunos"/>
<note author="P.Droba">
The compiler does not support features that are essential for the library.
</note>
</mark-unusable>
</library>
<!-- any -->
<library name="any">
<test name="any_to_ref_test">
<mark-failure>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="Vladimir Prus">
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.
</note>
</mark-failure>
</test>
</library>
<!-- array -->
<library name="array">
<test name="array3">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note refid="3"/>
</mark-failure>
<mark-failure>
<toolset name="sunpro-5_3-sunos"/>
<note refid="4"/>
</mark-failure>
</test>
<test name="array4">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note refid="3"/>
</mark-failure>
</test>
</library>
<!-- assign -->
<library name="assign">
<mark-unusable>
<toolset name="dmc-8_43-stlport-4_5_3"/>
</mark-unusable>
<mark-expected-failures>
<test name="array"/>
<toolset name="msvc-stlport"/>
<toolset name="vc-6_5-stlport"/>
<toolset name="vc-7_0"/>
<note author="Thorsten Ottosen" >
The test would (most likely) compile and run properly if the workaround
syntax .to_container( c ) was applied to all list_of() expressions.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="email_example"/>
<toolset name="gcc-2.95.3*"/>
<note refid="27" author="Thorsten Ottosen"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="list_inserter"/>
<toolset name="vc-7_0"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65*"/>
<toolset name="intel-win32"/>
<note refid="6" author="Thorsten Ottosen"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="list_inserter"/>
<toolset name="gcc-2.95.3*"/>
<note author="Thorsten Ottosen">
This test could probably be made to work if somebody with knowledge
about the compilers would submit a patch.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="list_of"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65*"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Thorsten Ottosen" >
The test would (most likely) compile and run properly if the workaround
syntax .to_container( c ) was applied to all list_of() expressions.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="list_of"/>
<toolset name="intel-win32-8_1"/>
<toolset name="intel-win32-9_0"/>
<note author="Thorsten Ottosen">
The test would (most likely) compile and run properly if
the test did not use list_of() with boost::array.
I would be very happy to see an intel programmer
submit a patch. It is quite strange that it only happens on
intel's windows compilers.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="list_of_workaround"/>
<toolset name="sunpro-5_3-sunos"/>
<note author="Thorsten Ottosen" >
The test could probably be made to work if somebody submitted a patch.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="multi_index_container"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65*"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3*"/>
<note refid="27" author="Thorsten Ottosen"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="multi_index_container"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="mipspro"/>
<toolset name="tru64cxx65"/>
<note author="Thorsten Ottosen" >
The test would (most likely) compile and run properly if the workaround
syntax .to_container( c ) was applied to all list_of() expressions.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="my_vector_example"/>
<toolset name="gcc-2.95.3*"/>
<note refid="27" author="Thorsten Ottosen"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="ptr_list_inserter"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65*"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="mipspro"/>
<note author="Thorsten Ottosen" >
The test depends on Boost.Pointer Container which probably does not work for
this compiler.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="ptr_list_of"/>
<toolset name="tru64cxx65*"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="mipspro"/>
<note author="Thorsten Ottosen" >
The test depends on Boost.Pointer Container which probably does not work for
this compiler.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="std"/>
<toolset name="sunpro-5_3-sunos"/>
<note author="Thorsten Ottosen" >
The test does not work for
this compiler.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="tuple_list_of"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Thorsten Ottosen" >
The test depends on Boost.Tuple which probably does not work for
this compiler.
</note>
</mark-expected-failures>
</library>
<!-- bind-->
<library name="bind">
<mark-expected-failures>
<test name="bind_cv_test"/>
<test name="bind_stateful_test"/>
<toolset name="intel-7.1-linux"/>
<toolset name="intel-7.1-stdlib-default-linux"/>
<note refid="2" author="Aleksey Gurtovoy"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="bind_dm2_test"/>
<test name="mem_fn_dm_test"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="cw-8_3"/>
<note refid="31" author="Peter Dimov"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="bind_dm_test"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="sunpro-5_3-sunos"/>
<note refid="31" author="Peter Dimov"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="mem_fn_derived_test"/>
<toolset name="sunpro-5_3-sunos"/>
<note refid="31" author="Peter Dimov"/>
</mark-expected-failures>
</library>
<!-- concept_check -->
<library name="concept_check">
<test name="class_concept_fail_expected">
<mark-failure>
<toolset name="cw-8_3*"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
</library>
<!-- config -->
<library name="config">
<test name="config_test">
<mark-failure>
<toolset name="intel-win32"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
<test name="config_link_test">
<mark-failure>
<toolset name="*como-4_3_3-vc7*"/>
<note author="J. Maddock" refid="3"/>
</mark-failure>
</test>
<test name="limits_test">
<mark-failure>
<toolset name="cw-8_3*"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
<test name="limits_test">
<mark-failure>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<note author="Aleksey Gurtovoy" refid="4"/>
</mark-failure>
</test>
<test name="test_thread_fail1">
<mark-failure>
<toolset name="sunpro-5_3-sunos"/>
<note author="J. Maddock" refid="3"/>
</mark-failure>
</test>
<test name="test_thread_fail2">
<mark-failure>
<toolset name="sunpro-5_3-sunos"/>
<note author="J. Maddock" refid="3"/>
</mark-failure>
</test>
</library>
<!-- conversion -->
<library name="conversion">
<test name="lexical_cast_test">
<mark-failure>
<toolset name="vc-8_0"/>
<note author="Aleksey Gurtovoy" refid="4"/>
</mark-failure>
<mark-failure>
<toolset name="sunpro-5_3-sunos"/>
<note author="Douglas Gregor" refid="3"/>
</mark-failure>
</test>
</library>
<!-- crc -->
<library name="crc">
<test name="crc_test">
<mark-failure>
<toolset name="sunpro-5_3-sunos"/>
<note author="Douglas Gregor" refid="3"/>
</mark-failure>
</test>
</library>
<!-- date_time -->
<library name="date_time">
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="msvc-stlport"/>
<toolset name="vc-6_5-stlport"/>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<toolset name="iw-7_1-vc6"/>
</mark-unusable>
<test name="testgreg_serialize*">
<mark-failure>
<toolset name="gcc-2.*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="B. Garst">The serialization library does not support this compiler.
</note>
</mark-failure>
</test>
<test name="testgreg_serialize_xml">
<mark-failure>
<toolset name="vc-7_0"/>
<note author="J. Garland">XML serialization is not supported on this compiler.
</note>
</mark-failure>
</test>
<test name="testtime_serialize*">
<mark-failure>
<toolset name="gcc-2.*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="B. Garst">The serialization library does not support this compiler.
</note>
</mark-failure>
</test>
<test name="testtime_serialize_xml*">
<mark-failure>
<toolset name="vc-7_0"/>
<note author="J. Garland">XML serialization is not supported on this compiler.
</note>
</mark-failure>
</test>
<test name="testdate_iterator">
<mark-failure>
<toolset name="intel-7.1-stdlib-default-linux"/>
<toolset name="intel-7.1-linux"/>
<note author="J. Garland" refid="19,21"/>
</mark-failure>
</test>
<test name="testdate_iterator_dll">
<mark-failure>
<toolset name="intel-7.1-stdlib-default-linux"/>
<toolset name="intel-7.1-linux"/>
<note author="J. Garland" refid="19,21"/>
</mark-failure>
</test>
<test name="testgeneric_period">
<mark-failure>
<toolset name="intel-7.1-stdlib-default-linux"/>
<toolset name="intel-7.1-linux"/>
<note author="J. Garland">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.
</note>
</mark-failure>
</test>
<test name="testgreg_wstream">
<mark-failure>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<toolset name="cw-8_3*"/>
<toolset name="borland-5_6_4"/>
<toolset name="mingw*"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-3.1-darwin"/>
<toolset name="*como-4_3_3*"/>
<toolset name="tru64cxx65-042"/>
<note author="B. Garst" refid="19,21"/>
</mark-failure>
</test>
<test name="testdate_input_facet*">
<mark-failure>
<toolset name="cw-9_4"/>
<toolset name="cw-9_5*"/>
<note author="J. Garland">
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).
</note>
</mark-failure>
</test>
<test name="testlocal_time_facet">
<mark-failure>
<toolset name="borland-5_6_4"/>
<toolset name="*como-4_3_3*"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testlocal_time">
<mark-failure>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="*como-4_3_3*"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testclocks">
<mark-failure>
<toolset name="*como-4_3_3*"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testlocal_time_input_facet">
<mark-failure>
<toolset name="borland-5_6_4"/>
<toolset name="*como-4_3_3*"/>
<toolset name="cw-8_3*"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testtime_input_facet">
<mark-failure>
<toolset name="borland-5_6_4"/>
<toolset name="*como-4_3_3*"/>
<toolset name="cw-8_3*"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testcustom_time_zone">
<mark-failure>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="*como-4_3_3*"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testposix_time_zone">
<mark-failure>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testfacet*">
<mark-failure>
<toolset name="tru64cxx65-042"/>
<note author="J. Garland">
There something non-standard about the tru64 standard library which
is preventing these tests from compiling.
</note>
</mark-failure>
</test>
<test name="testtz_database">
<mark-failure>
<toolset name="borland-5_6_4"/>
<toolset name="*como-4_3_3*"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testtime_wstream">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-3.1-darwin"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<toolset name="borland-5_6_4"/>
<toolset name="mingw*"/>
<toolset name="*como-4_3_3*"/>
<toolset name="tru64cxx65-042"/>
<note author="B. Garst" refid="19,21,22"/>
</mark-failure>
</test>
<test name="testtime_wstream_std_config">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-3.1-darwin"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<toolset name="borland-5_6_4"/>
<toolset name="mingw*"/>
<toolset name="*como-4_3_3*"/>
<toolset name="tru64cxx65-042"/>
<note author="B. Garst" refid="19,21,22"/>
</mark-failure>
</test>
<test name="testdate_facet_new">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="borland-5_6_4"/>
<toolset name="cw-8_3*"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testdate_facet_new_dll">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="borland-5_6_4"/>
<toolset name="cw-8_3*"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testtime_facet">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="borland-5_6_4"/>
<toolset name="cw-8_3*"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="J. Garland">
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.
</note>
</mark-failure>
</test>
<test name="testfacet">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-3.1-darwin"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="mingw*"/>
<toolset name="tru64cxx65-042"/>
<note author="B. Garst" refid="18,19"/>
</mark-failure>
</test>
<test name="testfacet_dll">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-3.1-darwin"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="mingw*"/>
<toolset name="*como-4_3_3*"/>
<toolset name="tru64cxx65-042"/>
<note author="B. Garst" refid="18,19"/>
</mark-failure>
</test>
<test name="testgreg_year_dll">
<mark-failure>
<toolset name="*como-4_3_3*"/>
</mark-failure>
</test>
<test name="testparse_date">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<toolset name="tru64cxx65-042"/>
<note author="B. Garst" refid="18,20"/>
</mark-failure>
</test>
<test name="testmicrosec_time_clock">
<mark-failure>
<toolset name="intel-7.1-stdlib-default-linux"/>
<toolset name="*como-4_3_3*"/>
<toolset name="intel-7.1-linux"/>
<note author="B. Garst" refid="22"/>
</mark-failure>
</test>
<test name="teststreams">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-3.1-darwin"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<toolset name="borland-5_6_4"/>
<toolset name="mingw-3*"/>
<toolset name="mingw"/>
<toolset name="*como-4_3_3*"/>
<toolset name="tru64cxx65-042"/>
<note author="B. Garst" refid="18,19,20"/>
</mark-failure>
</test>
<test name="testdate_dll">
<mark-failure>
<toolset name="*como-4_3_3*"/>
<note author="J. Garland" date="30 Jan 2004" id="24"/>
</mark-failure>
</test>
<test name="testgreg_day_dll">
<mark-failure>
<toolset name="*como-4_3_3*"/>
<note author="J. Garland" date="30 Jan 2004" id="24"/>
</mark-failure>
</test>
<test name="*_dll">
<mark-failure>
<toolset name="*como-4_3_3*"/>
<note author="J. Garland" date="30 Jan 2004" id="24"/>
</mark-failure>
</test>
<mark-expected-failures>
<test name="testdate_dll"/>
<test name="testdate_duration_dll"/>
<test name="testdate_input_facet_dll"/>
<test name="testdate_iterator_dll"/>
<test name="testfacet_dll"/>
<test name="testformatters_dll"/>
<test name="testgenerators_dll"/>
<test name="testgreg_durations_dll"/>
<test name="testperiod_dll"/>
<toolset name="cw-8_3*"/>
<note author="R. Rivera" refid="25"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="testlocal_time_input_facet"/>
<test name="testtime_input_facet"/>
<toolset name="cw-9_4"/>
<toolset name="cw-9_5*"/>
<note author="J. Garland">
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="testlocal_time"/>
<test name="testlocal_time_input_facet"/>
<test name="testtime_input_facet"/>
<toolset name="vc-8_0"/>
<note author="J. Garland">
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.
</note>
</mark-expected-failures>
</library>
<!-- dynamic_bitset -->
<library name="dynamic_bitset">
<test name="dyn_bitset_unit_tests4">
<mark-failure>
<toolset name="cw-9_3"/>
<note author="Aleksey Gurtovoy" refid="2"/>
</mark-failure>
<mark-failure>
<toolset name="cw-9_3-darwin"/>
<note author="Douglas Gregor" refid="2"/>
</mark-failure>
<mark-failure>
<toolset name="sunpro-5_3-sunos"/>
<note author="Douglas Gregor" refid="2"/>
</mark-failure>
</test>
</library>
<!-- filesystem -->
<library name="filesystem">
<mark-unusable>
<toolset name="intel-7.1-linux"/>
<toolset name="intel-7.1-stdlib-default-linux"/>
<note author="Aleksey Gurtovoy">
Due to to standard library bugs this configuration is not supported by
the most recent version of the library.
</note>
</mark-unusable>
<mark-expected-failures>
<test name="operations_test_dll"/>
<test name="path_test_dll"/>
<toolset name="borland-5_6_4"/>
<toolset name="mingw-3_4_2"/>
<note author="Beman Dawes" refid="35"/>
</mark-expected-failures>
</library>
<!-- format -->
<library name="format">
<mark-unusable>
<toolset name="iw-7_1*"/>
<note author="Aleksey Gurtovoy">
The failure is caused by a standard library bug: the
iostream components fail to handle <code>ios::internal</code>
flag.
</note>
</mark-unusable>
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
</mark-unusable>
<mark-expected-failures>
<test name="format_test2"/>
<test name="format_test3"/>
<toolset name="tru64cxx65*"/>
<note author="Markus Schoepflin" refid="33"/>
</mark-expected-failures>
</library>
<!-- functional/hash -->
<library name="functional/hash">
<mark-expected-failures>
<test name="hash_value_array_test"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Daniel James">
hash_value is not overloaded for arrays for older versions
of Visual C++. There is a work around so that
boost::hash&lt;T[N]&gt;, boost::hash_combine and boost::hash_range
work.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="hash_function_pointer_test"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note refid="2" author="Daniel James"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="hash_float_test"/>
<toolset name="gcc-3_4_3-sunos"/>
<note author="Daniel James">
On this compiler the hash function is returning the same value
for <code>std::numeric_limits&lt;long double&gt;::max()</code>,
<code>std::numeric_limits&lt;long double&gt;::max() / 2</code> and
<code>std::numeric_limits&lt;long double&gt;::max() * 3 / 4</code>.
This suggests the hash function isn't taking into account the
full range of <code>long double</code> - it might be
converting it to a <code>double</code>. This won't cause
anything to break, but means that the hash function isn't
as good as it should be for <code>long double</code>s.
</note>
</mark-expected-failures>
</library>
<!-- graph -->
<library name="graph">
<mark-unusable>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="sunpro-5_3-sunos"/>
</mark-unusable>
<mark-expected-failures>
<test name="adj_matrix_cc"/>
<test name="biconnected_components_test"/>
<test name="bfs_cc"/>
<test name="bundled_properties"/>
<test name="dfs_cc"/>
<test name="dijkstra_cc"/>
<test name="floyd_warshall_test"/>
<test name="gursoy_atun_layout_test"/>
<test name="graphviz_test"/>
<test name="subgraph"/>
<test name="transitive_closure_test"/>
<test name="vector_graph_cc"/>
<toolset name="vc-7_0"/>
<note refid="3" author="D. Gregor"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="graphviz_test"/>
<toolset name="vc-8_0"/>
<note refid="1" author="D. Gregor"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="betweenness_centrality_test"/>
<toolset name="iw-7_1-vc6*"/>
<toolset name="vc-7_0"/>
<note refid="3" author="Aleksey Gurtovoy"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="graphviz_test"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="como-4_3_3-vc7_1"/>
<toolset name="cw-8_3"/>
<toolset name="cw-9_3-darwin"/>
<toolset name="cw-9_4-darwin"/>
<toolset name="cw-9_4"/>
<toolset name="cw-9_4-darwin"/>
<toolset name="cw-9_5-darwin"/>
<toolset name="iw-7_1-vc6"/>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<note refid="3" author="Doug Gregor"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="layout_test"/>
<toolset name="intel-win32-9_0"/>
</mark-expected-failures>
</library>
<!-- io-->
<library name="io">
<mark-expected-failures>
<test name="ios_state_unit_test"/>
<toolset name="borland-5_6_4"/>
<toolset name="iw-7_1-vc6*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note refid="4" author="Aleksey Gurtovoy"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="ios_state_test"/>
<test name="ios_state_unit_test"/>
<toolset name="tru64cxx65*"/>
<note refid="34" author="Markus Schoepflin"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="ios_state_unit_test"/>
<toolset name="gcc-2.95.3-*"/>
<note refid="3" author="Doug Gregor"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="ios_state_unit_test"/>
<toolset name="intel-win32-*"/>
<note refid="3" author="Stefan Slapeta"/>
</mark-expected-failures>
</library>
<!-- iostreams -->
<library name="iostreams">
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="dmc-8_43-stlport-4_5_3"/>
<note author="Jonathan Turkanis" refid="17"/>
</mark-unusable>
<mark-expected-failures>
<test name="seekable_file_test"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="borland-5_6_4"/>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<toolset name="msvc-stlport"/>
<toolset name="vc-6_5-stlport"/>
<toolset name="*como-4_3_3*"/>
<note author="Jonathan Turkanis" refid="4"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="code_converter_test"/>
<test name="wide_stream_test"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="*mingw*"/>
<toolset name="*cygwin*"/>
<toolset name="gcc-3.3.6-osf1"/>
<note author="Jonathan Turkanis" refid="19"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="bzip2_test"/>
<test name="file_descriptor_test"/>
<test name="mapped_file_test"/>
<toolset name="*como-4_3_3*"/>
<note author="Jonathan Turkanis">
compiler can't compile "windows.h" in strict mode
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="gzip_test"/>
<test name="zlib_test"/>
<toolset name="como-4_3_3-vc7_1"/>
<note author="Jonathan Turkanis">
The failure reflects a problem with the build system: the zlib
object files are generated in the wrong directory.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="stdio_filter_test"/>
<toolset name="*como-4_3_3*"/>
<note author="Jonathan Turkanis" refid="0"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="mapped_file_test"/>
<toolset name="intel-win32-9_0"/>
<note author="Jonathan Turkanis" refid="0"/>
</mark-expected-failures>
<mark-expected-failures reason="?">
<test name="direct_adapter_test"/>
<test name="gzip_test"/>
<toolset name="gcc-2.95.3-linux"/>
<note author="Jonathan Turkanis" refid="29"/>
</mark-expected-failures>
<mark-expected-failures reason="?">
<test name="file_descriptor_test"/>
<toolset name="gcc-3_4_4-cygwin"/>
<note author="Jonathan Turkanis" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="finite_state_filter_test"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="gcc-2.95.3*"/>
<note author="Jonathan Turkanis" refid="2"/>
</mark-expected-failures>
</library>
<!-- lambda -->
<library name="lambda">
<mark-unusable>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="borland-5_5_1"/>
<toolset name="vc-7_0"/>
<toolset name="sunpro-5_3-sunos"/>
<note refid="17">
</note>
</mark-unusable>
<mark-expected-failures>
<test name="bll_and_function"/>
<toolset name="vc-8_0"/>
<note author="Aleksey Gurtovoy" refid="6"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="member_pointer_test"/>
<toolset name="gcc-2.95.3-*"/>
<note author="Doug Gregor" refid="3"/>
</mark-expected-failures>
</library>
<!-- logic -->
<library name="logic">
<test name="tribool_io_test">
<mark-failure>
<toolset name="msvc-stlport"/>
<toolset name="vc-6_5-stlport"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65-042"/>
<note author="Douglas Gregor" refid="4"/>
</mark-failure>
</test>
</library>
<!-- MPL -->
<library name="mpl">
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
<note author="Aleksey Gurtovoy" date="10 Jul 2005">
The compiler is not supported by the library due to an
utterly broken templates support.
</note>
</mark-unusable>
<mark-expected-failures>
<test name="as_sequence"/>
<test name="is_sequence"/>
<test name="has_xxx"/>
<test name="no_has_xxx"/>
<test name="single_view"/>
<toolset name="cw-8_3*"/>
<note author="Aleksey Gurtovoy" date="17 Sep 2004">
This failure is caused by a deficient SFINAE implementation; the bug
was fixed in the next major compiler version (CodeWarrior 9.x).
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="is_sequence"/>
<test name="as_sequence"/>
<test name="has_xxx"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3*"/>
<note author="Aleksey Gurtovoy" date="17 Sep 2004">
This failure is caused by a deficient SFINAE implementation.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="apply"/>
<test name="for_each"/>
<test name="multiset"/>
<test name="zip_view"/>
<toolset name="borland-5_6_4"/>
<note author="Aleksey Gurtovoy" date="17 Sep 2004" refid="26"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="assert"/>
<test name="at"/>
<test name="back"/>
<test name="front"/>
<test name="has_xxx"/>
<test name="multiset"/>
<test name="no_has_xxx"/>
<test name="zip_view"/>
<toolset name="mipspro"/>
<note author="Aleksey Gurtovoy" date="17 Sep 2004" refid="26"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="quote"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="mipspro"/>
<note author="Aleksey Gurtovoy" date="17 Sep 2004">
This failure is caused by a lack of compiler support for template template
parameters.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="map"/>
<test name="set"/>
<test name="set_c"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3*"/>
<toolset name="mipspro"/>
<note author="Aleksey Gurtovoy" date="17 Sep 2004">
This is an advanced functionality that hasn't been ported to the deficient
compilers (yet). Patches are welcome!
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="map"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Aleksey Gurtovoy" date="17 Sep 2004">
This is an advanced functionality that hasn't been ported to the deficient
compilers (yet). Patches are welcome!
</note>
</mark-expected-failures>
</library>
<!-- multi_array -->
<library name="multi_array">
<mark-unusable>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="borland-5_5_1"/>
<note author="Alisdair Meredith" date="30 Jan 2004">
<p>
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!
</p>
</note>
</mark-unusable>
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
<note author="Douglas Gregor" refid="3"/>
</mark-unusable>
<test name="constructors">
<mark-failure>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<note author="Ronald Garcia" date="13 Jul 2004">
Known error in MSVC. see
<a href="http://boost-consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_60">
http://boost-consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_60</a>
for more information.
</note>
</mark-failure>
</test>
<mark-expected-failures>
<test name="assign_to_array"/>
<toolset name="gcc-2.95.3*"/>
<note author="Aleksey Gurtovoy" date="21 Sep 2004" refid="2"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="assign"/>
<test name="compare"/>
<test name="concept_checks"/>
<test name="constructors"/>
<test name="iterators"/>
<test name="resize"/>
<test name="stl_interaction"/>
<toolset name="gcc-2.95.3*"/>
<note author="Doug Gregor" date="23 Jun 2005" refid="3"/>
</mark-expected-failures>
</library>
<!-- multi_index -->
<library name="multi_index">
<mark-unusable>
<toolset name="borland-5_6_4"/>
<note author="J. L&#243;pez" date="05 Jul 2004" refid="17"/>
</mark-unusable>
<mark-unusable>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note author="J. L&#243;pez" date="09 Jul 2004" refid="17"/>
</mark-unusable>
<mark-unusable>
<toolset name="*como-4_3_3-msvc"/>
<note author="J. L&#243;pez" date="30 Jul 2004">
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.
</note>
</mark-unusable>
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="sunpro-5_8u1-sunos"/>
<note author="J. L&#243;pez" date="22 Apr 2005" refid="17"/>
</mark-unusable>
<mark-unusable>
<toolset name="dmc-8_43-stlport-4_5_3"/>
<toolset name="dmc-8_44b-stlport-4_5_3"/>
<note author="J. L&#243;pez" date="03 Jun 2005" refid="17"/>
</mark-unusable>
<mark-expected-failures>
<test name="test_serialization"/>
<toolset name="msvc-stlport"/>
<toolset name="vc-6_5-stlport"/>
<note author="J. L&#243;pez" date="10 Jan 2005">
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.)
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_serialization"/>
<toolset name="vacpp"/>
<note author="J. L&#243;pez" date="07 Jul 2005">
Boost.Serialization is not supported on this platform.
</note>
</mark-expected-failures>
</library>
<!-- optional -->
<library name="optional">
<mark-expected-failures>
<test name="optional_test_ref"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Aleksey Gurtovoy" refid="3"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="optional_test_ref_fail1"/>
<toolset name="borland-5_6_4"/>
<note author="Fernando Cacciola" refid="2"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="optional_test_fail3a"/>
<toolset name="gcc-3_3-darwin"/>
<note author="Fernando Cacciola" refid="2"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="optional_test_inplace_fail2"/>
<toolset name="gcc-3_3-darwin"/>
<note author="Fernando Cacciola" refid="2"/>
</mark-expected-failures>
</library>
<library name="pool">
<mark-unusable>
<toolset name="gcc-2.95.3-*"/>
<note author="Doug Gregor" refid="2"/>
</mark-unusable>
</library>
<!-- preprocessor -->
<library name="preprocessor">
<mark-expected-failures>
<test name="seq"/>
<toolset name="cw-8_3"/>
<note author="Paul Mensonides" refid="2"/>
</mark-expected-failures>
</library>
<!-- serialization -->
<library name="serialization">
<mark-unusable>
<toolset name="vacpp*" />
<toolset name="mipspro*" />
<toolset name="dmc*" />
<toolset name="sunpro*" />
<note author="Robert Ramey" date="13 Jul 2004" refid="9,17,18"/>
</mark-unusable>
<mark-unusable>
<toolset name="gcc-2.95.3-linux"/>
<note author="Robert Ramey" date="12 Feb 05" refid="18,19"/>
</mark-unusable>
<mark-expected-failures>
<test name="*_warchive"/>
<test name="test_codecvt_null"/>
<test name="test_utf8_codecvt"/>
<toolset name="mingw*"/>
<toolset name="gcc-2.95.3-linux"/>
<note author="Robert Ramey" date="12 Feb 05" refid="19"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_void_cast*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="Robert Ramey" date="20 Sep 2004" refid="16,29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="*_warchive"/>
<test name="test_codecvt_null"/>
<test name="test_utf8_codecvt"/>
<toolset name="*como-4_3_3*"/>
<note author="Robert Ramey" date="12 Feb 05" refid="5"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_demo_portable_archive_dll"/>
<toolset name="vc*"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="iw*"/>
<toolset name="intel-win32-*"/>
<note author="Robert Ramey" date="12 Feb 05" refid="2,29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_reset_object_address*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="Robert Ramey" date="12 Feb 05" refid="6,29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_array*"/>
<test name="test_demo_fast_archive"/>
<test name="test_demo_fast_archive_dll"/>
<toolset name="borland*"/>
<note author="Robert Ramey" date="12 Feb 05" refid="26">
Borland compilers don't handle templates with array type arguments properly.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_demo"/>
<test name="test_demo_dll"/>
<test name="test_demo_exception"/>
<test name="test_demo_exception_dll"/>
<test name="test_demo_shared_ptr"/>
<test name="test_demo_shared_ptr_dll"/>
<test name="test_demo_xml_save"/>
<test name="test_demo_xml_load"/>
<test name="test_demo_xml_save_dll"/>
<test name="test_demo_xml_load_dll"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Robert Ramey" refid="6"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_demo_fast_archive"/>
<test name="test_demo_fast_archive_dll"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="Robert Ramey" refid="6"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_const"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Aleksey Gurtovoy" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_demo_pimpl"/>
<test name="test_demo_pimpl_dll"/>
<test name="test_diamond*"/>
<test name="test_mult_archive_types"/>
<test name="test_mult_archive_types_dll"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Robert Ramey" refid="6">
msvc 6 compiler failure. The facility being tested conflicts the the
compiler in a fundamental way and cannnot be worked around.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_mi*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="Robert Ramey" refid="6">
msvc 6 compiler failure. The facility being tested conflicts the the
compiler in a fundamental way and cannnot be worked around.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="*_dll"/>
<toolset name="msvc-stlport"/>
<toolset name="vc-6_5-stlport"/>
<note author="Robert Ramey">
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="*"/>
<toolset name="gcc-2.95.3-stlport*"/>
<note author="Aleksey Gurtovoy">
The library is believed to work in this configuration <i>if compiled against
Spirit 1.6</i>. The latter is not provided by the particular testing
environment these tests have been run in.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_demo"/>
<test name="test_demo_dll"/>
<test name="test_demo_exception*"/>
<test name="test_demo_shared_ptr*"/>
<test name="test_demo_xml*"/>
<test name="test_exported*"/>
<test name="test_mi*"/>
<test name="test_mult_archive_types*"/>
<test name="test_no_rtti*"/>
<test name="test_non_default_ctor2*"/>
<test name="test_registered*"/>
<test name="test_shared_ptr*"/>
<test name="test_unregistered*"/>
<toolset name="cw*"/>
<note author="Robert Ramey" refid="29">
All tests that serialize derived pointers currently fail with Metrowerks compilers.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_no_rtti_*"/>
<test name="test_set_*"/>
<toolset name="borland-5_6_4"/>
<note author="Aleksey Gurtovoy" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_array_binary_archive"/>
<test name="test_array_text_*"/>
<note author="Aleksey Gurtovoy" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_smart_cast"/>
<toolset name="intel-7.1-linux"/>
<note author="Aleksey Gurtovoy" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_array_text_archive_dll"/>
<test name="test_array_text_warchive_dll"/>
<test name="test_array_xml_archive_dll"/>
<test name="test_array_xml_warchive_dll"/>
<test name="test_binary_text_archive_dll"/>
<test name="test_binary_text_warchive_dll"/>
<test name="test_binary_xml_archive_dll"/>
<test name="test_binary_xml_warchive_dll"/>
<test name="test_class_info_save_text_archive_dll"/>
<test name="test_class_info_save_text_warchive_dll"/>
<test name="test_class_info_save_xml_warchive_dll"/>
<test name="test_contained_class_text_archive_dll"/>
<test name="test_contained_class_text_warchive_dll"/>
<test name="test_contained_class_xml_archive_dll"/>
<test name="test_contained_class_xml_warchive_dll"/>
<test name="test_cyclic_ptrs_text_archive_dll"/>
<test name="test_cyclic_ptrs_text_warchive_dll"/>
<test name="test_cyclic_ptrs_xml_archive_dll"/>
<test name="test_cyclic_ptrs_xml_warchive_dll"/>
<test name="test_delete_pointer_text_archive_dll"/>
<test name="test_delete_pointer_text_warchive_dll"/>
<test name="test_delete_pointer_xml_archive_dll"/>
<test name="test_delete_pointer_xml_warchive_dll"/>
<test name="test_demo_auto_ptr_dll"/>
<test name="test_demo_dll"/>
<test name="test_demo_exception_dll"/>
<test name="test_demo_pimpl_dll"/>
<test name="test_demo_polymorphic_dll"/>
<test name="test_deque_text_archive_dll"/>
<test name="test_deque_text_warchive_dll"/>
<test name="test_deque_xml_archive_dll"/>
<test name="test_deque_xml_warchive_dll"/>
<test name="test_derived_class_ptr_text_archive_dll"/>
<test name="test_derived_class_ptr_text_warchive_dll"/>
<test name="test_derived_class_ptr_xml_archive_dll"/>
<test name="test_derived_class_ptr_xml_warchive_dll"/>
<test name="test_derived_class_text_archive_dll"/>
<test name="test_derived_class_text_warchive_dll"/>
<test name="test_derived_class_xml_archive_dll"/>
<test name="test_derived_class_xml_warchive_dll"/>
<test name="test_derived_text_archive_dll"/>
<test name="test_derived_text_warchive_dll"/>
<test name="test_derived_xml_warchive_dll"/>
<test name="test_list_ptrs_text_archive_dll"/>
<test name="test_list_ptrs_text_warchive_dll"/>
<test name="test_list_ptrs_xml_archive_dll"/>
<test name="test_list_ptrs_xml_warchive_dll"/>
<test name="test_list_text_archive_dll"/>
<test name="test_list_text_warchive_dll"/>
<test name="test_list_xml_archive_dll"/>
<test name="test_list_xml_warchive_dll"/>
<test name="test_map_text_archive_dll"/>
<test name="test_map_text_warchive_dll"/>
<test name="test_map_xml_archive_dll"/>
<test name="test_map_xml_warchive_dll"/>
<test name="test_multiple_ptrs_text_archive_dll"/>
<test name="test_multiple_ptrs_text_warchive_dll"/>
<test name="test_multiple_ptrs_xml_archive_dll"/>
<test name="test_multiple_ptrs_xml_warchive_dll"/>
<test name="test_non_default_ctor_text_archive_dll"/>
<test name="test_non_default_ctor_text_warchive_dll"/>
<test name="test_non_default_ctor_xml_archive_dll"/>
<test name="test_non_default_ctor_xml_warchive_dll"/>
<test name="test_non_intrusive_ctor_text_archive_dll"/>
<test name="test_non_intrusive_ctor_text_warchive_dll"/>
<test name="test_non_intrusive_ctor_xml_archive_dll"/>
<test name="test_non_intrusive_ctor_xml_warchive_dll"/>
<test name="test_non_intrusive_text_archive_dll"/>
<test name="test_non_intrusive_text_warchive_dll"/>
<test name="test_non_intrusive_xml_archive_dll"/>
<test name="test_non_intrusive_xml_warchive_dll"/>
<test name="test_null_ptr_text_archive_dll"/>
<test name="test_null_ptr_text_warchive_dll"/>
<test name="test_null_ptr_xml_archive_dll"/>
<test name="test_null_ptr_xml_warchive_dll"/>
<test name="test_nvp_text_archive_dll"/>
<test name="test_nvp_text_warchive_dll"/>
<test name="test_nvp_xml_archive_dll"/>
<test name="test_nvp_xml_warchive_dll"/>
<test name="test_object_text_warchive_dll"/>
<test name="test_object_xml_warchive_dll"/>
<test name="test_optional_text_archive_dll"/>
<test name="test_optional_text_warchive_dll"/>
<test name="test_optional_xml_archive_dll"/>
<test name="test_optional_xml_warchive_dll"/>
<test name="test_polymorphic_text_archive_dll"/>
<test name="test_polymorphic_text_warchive_dll"/>
<test name="test_polymorphic_xml_archive_dll"/>
<test name="test_polymorphic_xml_warchive_dll"/>
<test name="test_primitive_text_warchive_dll"/>
<test name="test_primitive_xml_warchive_dll"/>
<test name="test_private_ctor_dll"/>
<test name="test_recursion_text_archive_dll"/>
<test name="test_recursion_text_warchive_dll"/>
<test name="test_recursion_xml_archive_dll"/>
<test name="test_recursion_xml_warchive_dll"/>
<test name="test_reset_object_address_dll"/>
<test name="test_set_text_archive_dll"/>
<test name="test_set_text_warchive_dll"/>
<test name="test_set_xml_archive_dll"/>
<test name="test_set_xml_warchive_dll"/>
<test name="test_simple_class_ptr_text_archive_dll"/>
<test name="test_simple_class_ptr_text_warchive_dll"/>
<test name="test_simple_class_ptr_xml_archive_dll"/>
<test name="test_simple_class_ptr_xml_warchive_dll"/>
<test name="test_simple_class_text_archive_dll"/>
<test name="test_simple_class_text_warchive_dll"/>
<test name="test_simple_class_xml_archive_dll"/>
<test name="test_simple_class_xml_warchive_dll"/>
<test name="test_split_text_archive_dll"/>
<test name="test_split_text_warchive_dll"/>
<test name="test_split_xml_warchive_dll"/>
<test name="test_tracking_text_archive_dll"/>
<test name="test_tracking_text_warchive_dll"/>
<test name="test_tracking_xml_warchive_dll"/>
<test name="test_variant_text_archive_dll"/>
<test name="test_variant_text_warchive_dll"/>
<test name="test_variant_xml_archive_dll"/>
<test name="test_variant_xml_warchive_dll"/>
<test name="test_vector_text_archive_dll"/>
<test name="test_vector_text_warchive_dll"/>
<test name="test_vector_xml_archive_dll"/>
<test name="test_vector_xml_warchive_dll"/>
<toolset name="cw-9_5-darwin"/>
<note author="Doug Gregor" refid="35"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_demo_fast_archive"/>
<toolset name="cw-8*"/>
<note author="Rene Rivera">
This is caused by a compiler bug in this particular version, but not present
in version thereafter. The compiler has some difficulties resolving operators
to methods in the archive classes. This can be worked around by calling the
operator directly, and such a work around is already present in library code.
This test demonstrates that this can happen in user code.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_diamond*"/>
<toolset name="cw-8*"/>
<toolset name="cw-9_5-darwin"/>
<note author="Rene Rivera">
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_class_info_load_text*"/>
<test name="test_class_info_load_xml_warchive*"/>
<toolset name="cw-9_5-darwin"/>
<note author="Rene Rivera" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_class_info_load_text_warchive_dll"/>
<toolset name="vc-6_5"/>
<note author="Doug Gregor" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_const_load_fail1"/>
<test name="test_const_load_fail1_nvp"/>
<test name="test_const_load_fail2"/>
<test name="test_const_load_fail2_nvp"/>
<toolset name="borland-5_6_4"/>
<note author="Doug Gregor" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_const_save_fail1"/>
<test name="test_const_save_fail2"/>
<test name="test_const_save_fail3"/>
<toolset name="vc-6_5"/>
<toolset name="vc-6_5-stlport"/>
<toolset name="vc-7_0"/>
<note author="Doug Gregor" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_map_binary_archive_dll"/>
<test name="test_map_text_archive_dll"/>
<test name="test_map_text_warchive_dll"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="Doug Gregor" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_shared_ptr_132_xml_archive_dll"/>
<toolset name="intel-win32-8_1"/>
<note author="Doug Gregor" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_demo_dll"/>
<test name="test_demo_exception_dll"/>
<test name="test_demo_shared_ptr_dll"/>
<test name="test_demo_xml_load_dll"/>
<test name="test_demo_xml_save_dll"/>
<toolset name="intel-win32-8_1"/>
<note author="Doug Gregor" refid="35"/>
</mark-expected-failures>
</library>
<!-- smart_ptr -->
<library name="smart_ptr">
<mark-expected-failures>
<test name="shared_ptr_assign_fail"/>
<toolset name="gcc-2.9*"/>
<toolset name="sunpro-5_3-sunos"/>
<note refid="32" author="Peter Dimov"/>
</mark-expected-failures>
</library>
<!-- spirit -->
<library name="spirit">
<mark-unusable>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="borland-5_5_1"/>
<toolset name="borland-5_6_4"/>
<toolset name="vc-7_0"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="sunpro-5_3-sunos"/>
<note>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</note>
</mark-unusable>
<mark-expected-failures>
<test name="action_tests*"/>
<toolset name="iw-7_1-vc6"/>
<note author="Aleksey Gurtovoy" refid="4"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="ast_calc_tests*"/>
<test name="closure_tests*"/>
<test name="multi_pass_compile_tests"/>
<test name="repeat_ast_tests*"/>
<toolset name="intel-8.0-linux"/>
<toolset name="intel-8.1-linux"/>
<note author="Aleksey Gurtovoy">
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="escape_char_parser_tests*"/>
<toolset name="intel-7.1-linux"/>
<toolset name="intel-7.1-stdlib-default-linux"/>
<note author="Aleksey Gurtovoy" refid="19"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="escape_char_parser_tests*"/>
<toolset name="iw-7_1-vc6*"/>
<note author="Aleksey Gurtovoy" refid="28"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="chset_tests*"/>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<note author="Aleksey Gurtovoy" refid="28"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="traverse_tests*"/>
<toolset name="intel-win32-9_0"/>
<note author="S. Slapeta" refid="31"/>
</mark-expected-failures>
</library>
<!-- function -->
<library name="function">
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
<note author="Douglas Gregor" refid="3"/>
</mark-unusable>
<test name="allocator_test">
<mark-failure>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="5"/>
</mark-failure>
</test>
<test name="contains_test">
<mark-failure>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note refid="3" author="D. Gregor"/>
</mark-failure>
</test>
<test name="function_30">
<mark-failure>
<toolset name="vacpp"/>
<note refid="16" author="D. Gregor"/>
</mark-failure>
</test>
<test name="function_arith_cxx98">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
<test name="function_ref_cxx98">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
<test name="lambda_test">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
<mark-failure>
<toolset name="cw-8_3*"/>
<note author="B. Dawes" refid="2"/>
</mark-failure>
</test>
<test name="lib_function_test">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
<mark-failure>
<toolset name="cw-8_3*"/>
<note author="B. Dawes" refid="2"/>
</mark-failure>
</test>
<test name="mem_fun_cxx98">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
<mark-failure>
<toolset name="cw-8_3*"/>
<note author="B. Dawes" refid="2"/>
</mark-failure>
</test>
<test name="std_bind_cxx98">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
<test name="std_bind_portable">
<mark-failure>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<note author="B. Dawes" refid="5"/>
</mark-failure>
</test>
<test name="sum_avg_cxx98">
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
</library>
<!-- iterator -->
<library name="iterator">
<test name="interoperable_fail" category="Corner-case tests">
<mark-failure>
<toolset name="gcc-3.3*"/>
<toolset name="gcc-3_3*"/>
<toolset name="gcc-3.2*"/>
<toolset name="gcc-2*"/>
<toolset name="gcc"/>
<toolset name="mingw"/>
<toolset name="borland*"/>
<toolset name="cw-8*"/>
<note author="D. Abrahams">
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.
</note>
</mark-failure>
</test>
<test name="is_convertible_fail" category="Corner-case tests">
<mark-failure>
<toolset name="gcc-2*"/>
<toolset name="gcc"/>
<toolset name="mingw"/>
<toolset name="borland*"/>
<toolset name="cw-8*"/>
<toolset name="vc-6*"/>
<toolset name="vc-7_0*"/>
<toolset name="msvc"/>
<note author="D. Abrahams">
This failure is caused by a compiler bug.
<code>is_convertible&lt;T,U&gt;::value</code> may be true for unrelated
iterators <code>T</code> and <code>U</code>
(including many of the Boost specialized adaptors) which use
<code>enable_if_convertible</code> to restrict the applicability
of converting constructors, even when <code>T</code> is not
convertible to <code>U</code> because instantiating the
conversion will cause a compilation failure.
</note>
</mark-failure>
</test>
<test name="indirect_iter_member_types" category="Corner-case tests"/>
<mark-expected-failures>
<test name="indirect_iter_member_types"/>
<test name="pointee"/>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<note author="D. Abrahams">
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 <code>T*</code> and <code>T&amp;</code> that should
have been <code>T const*</code> and <code>T const&amp;</code>.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="zip_iterator_test"/>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<note author="Aleksey Gurtovoy" date="19 Sep 2004" refid="26"/>
</mark-expected-failures>
</library>
<!-- math -->
<library name="math">
<mark-unusable>
<toolset name="gcc-2.95.3-*"/>
<note author="Doug Gregor" refid="3"/>
</mark-unusable>
<test name="quaternion_mult_incl_test">
<mark-failure>
<toolset name="intel-win32"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
<mark-expected-failures>
<test name="octonion_test"/>
<test name="quaternion_test"/>
<toolset name="gcc-3_4_3-sunos"/>
<note author="Caleb Epstein">
There appears to be a bug in gcc's <code>std::exp (long
double)</code> on this platform.
</note>
</mark-expected-failures>
</library>
<!-- numeric/conversion -->
<library name="numeric/conversion">
<test name="udt_example_0">
<mark-failure>
<toolset name="vc-6_5-stlport"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="Fernando Cacciola" refid="30"/>
</mark-failure>
</test>
<test name="udt_support_test">
<mark-failure>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note author="Fernando Cacciola" refid="3"/>
</mark-failure>
</test>
</library>
<!-- numeric/interval -->
<library name="numeric/interval">
<mark-unusable>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
</mark-unusable>
<test name="test_float">
<mark-failure>
<toolset name="borland-5_5_1"/>
<toolset name="iw-7_1-vc6"/>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<note author="G. Melquiond">
This test ensures the inclusion property of interval
arithmetic is available for built-in floating-point types
<code>float</code> and <code>double</code>. If the test
fails, <code>interval&lt;float&gt;</code> and
<code>interval&lt;double&gt;</code> should not be used
on this compiler/platform since there will be no
numerical guarantee.
</note>
</mark-failure>
</test>
<mark-expected-failures>
<test name="cmp_exn"/>
<test name="cmp_set"/>
<test name="cmp_tribool"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note author="Aleksey Gurtovoy" refid="2"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="det"/>
<toolset name="cw-8_3*"/>
<note author="Aleksey Gurtovoy" refid="2"/>
</mark-expected-failures>
</library>
<!-- numeric/ublas -->
<library name="numeric/ublas">
<mark-unusable>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-3_3-darwin"/>
<note author="M.Stevens" refid="17"/>
</mark-unusable>
<mark-unusable>
<toolset name="cw-8_3"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="iw-7_1-vc6"/>
<toolset name="gcc-2.95*"/>
<note author="M.Stevens" refid="30"/>
</mark-unusable>
</library>
<!-- program_options -->
<library name="program_options">
<!-- Mark unusable toolsets -->
<mark-unusable>
<toolset name="gcc-2.95.3-linux"/>
<note>
The failure is caused by standard library deficiencies
-- it lacks the basic_string class template and
the &lt;locale&gt; header.
</note>
</mark-unusable>
<mark-unusable>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note refid="2"/>
</mark-unusable>
<mark-unusable>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note refid="17"/>
</mark-unusable>
<mark-unusable>
<toolset name="vc-7_0"/>
<note refid="29"/>
</mark-unusable>
<!-- Mark expected failures -->
<test name="unicode_test*">
<mark-failure>
<toolset name="iw-7_1-vc6"/>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note>The failures are caused by problems
with std::locale implementation</note>
</mark-failure>
</test>
<test name="options_description_test_dll">
<mark-failure>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="iw-7_1-vc6"/>
<note refid="23"/>
</mark-failure>
</test>
<test name="variable_map_test_dll">
<mark-failure>
<toolset name="iw-7_1-vc6"/>
<note refid="23"/>
</mark-failure>
</test>
<test name="*dll">
<mark-failure>
<toolset name="cw-8_3*"/>
<note refid="18"/>
</mark-failure>
</test>
<test name="*dll">
<mark-failure>
<toolset name="*como-4_3_3*"/>
<note refid="24"/>
</mark-failure>
</test>
<mark-expected-failures>
<test name="variable_map_test"/>
<test name="variable_map_test_dll"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note>
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="cmdline_test_dll"/>
<test name="options_description_test_dll"/>
<test name="parsers_test_dll"/>
<test name="variable_map_test_dll"/>
<test name="positional_options_test_dll"/>
<toolset name="mingw-3*"/>
<note author="Aleksey Gurtovoy" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="unicode_test*"/>
<toolset name="mingw-3*"/>
<note refid="19"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="unicode_test_dll"/>
<toolset name="*-darwin"/>
<note refid="35" author="Doug Gregor"/>
</mark-expected-failures>
</library>
<!-- pointer container -->
<library name="ptr_container">
<mark-unusable>
<toolset name="gcc-2.95.3*"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65-042"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="dmc-8_43-stlport-4_5_3"/>
</mark-unusable>
<mark-expected-failures>
<test name="ptr_list"/>
<toolset name="gcc-4.0.*"/>
<note author="Thorsten Ottosen">
The error is due to problems in the standard library implementation.
It should be fixed in newer versions of the compiler.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="ptr_list"/>
<toolset name="gcc-4.0.0*"/>
<note author="Thorsten Ottosen">
The error is due to problems in the standard library implementation.
It should be fixed in newer versions of the compiler.
</note>
</mark-expected-failures>
</library>
<!-- python -->
<library name="python">
<mark-unusable>
<toolset name="borland"/>
<toolset name="borland-5_5_1"/>
<toolset name="borland-5_6_4"/>
<note refid="2"/>
<note refid="17"/>
</mark-unusable>
<mark-expected-failures>
<test name="args"/>
<test name="auto_ptr"/>
<test name="builtin_convertors"/>
<test name="callbacks"/>
<test name="crossmod_exception"/>
<test name="data_members"/>
<test name="enum"/>
<test name="exception_translator"/>
<test name="extract"/>
<test name="implicit"/>
<test name="iterator"/>
<test name="list"/>
<test name="map_indexing_suite"/>
<test name="object"/>
<test name="opaque"/>
<test name="pickle2"/>
<test name="polymorphism"/>
<test name="polymorphism2"/>
<test name="shared_ptr"/>
<test name="slice"/>
<test name="test_pointer_adoption"/>
<test name="try"/>
<test name="vector_indexing_suite"/>
<test name="virtual_functions"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note author="D. Abrahams">
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="args"/>
<test name="auto_ptr"/>
<test name="back_reference"/>
<test name="ben_scott1"/>
<test name="bienstman1"/>
<test name="bienstman2"/>
<test name="bienstman3"/>
<test name="bienstman4"/>
<test name="bienstman5"/>
<test name="callbacks"/>
<test name="cltree"/>
<test name="const_argument"/>
<test name="crossmod_exception_a"/>
<test name="crossmod_exception_b"/>
<test name="data_members"/>
<test name="defaults"/>
<test name="dict"/>
<test name="docstring"/>
<test name="enum"/>
<test name="exception_translator"/>
<test name="extract"/>
<test name="implicit"/>
<test name="injected"/>
<test name="input_iterator"/>
<test name="int_map_indexing_suite"/>
<test name="iterator"/>
<test name="keywords"/>
<test name="list"/>
<test name="long"/>
<test name="m1"/>
<test name="m2"/>
<test name="map_indexing_suite"/>
<test name="minimal"/>
<test name="module_tail"/>
<test name="multi_arg_constructor"/>
<test name="nested"/>
<test name="object"/>
<test name="opaque"/>
<test name="operators"/>
<test name="pickle1"/>
<test name="pickle2"/>
<test name="pickle3"/>
<test name="pickle4"/>
<test name="polymorphism"/>
<test name="polymorphism2"/>
<test name="properties"/>
<test name="register_ptr"/>
<test name="return_arg"/>
<test name="shared_ptr"/>
<test name="slice"/>
<test name="staticmethod"/>
<test name="str"/>
<test name="test_builtin_converters"/>
<test name="test_pointer_adoption"/>
<test name="tuple"/>
<test name="vector_indexing_suite"/>
<test name="virtual_functions"/>
<toolset name="intel-7.1-linux"/>
<toolset name="intel-8.0-linux"/>
<note author="Aleksey Gurtovoy">
The library is <a href="http://article.gmane.org/gmane.comp.lib.boost.devel/110420">known to work</a>
in this configuration. The failures are due to configuration issues of
the particular testing environment these tests have been run in. The
regression runners and library developers are aware of the problem and
plan to fix it for the next release.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="builtin_converters"/>
<test name="extract"/>
<test name="list"/>
<test name="operators"/>
<test name="pickle1"/>
<test name="pickle2"/>
<test name="pickle3"/>
<test name="pickle4"/>
<toolset name="gcc-3.4.2-linux"/>
<note author="Aleksey Gurtovoy">
The test is <a href="http://article.gmane.org/gmane.comp.lib.boost.devel/110671">known to work</a>
in this configuration. The failures are due to configuration issues of
the particular testing environment these tests have been run in.
</note>
</mark-expected-failures>
</library>
<!-- random -->
<library name="random">
<mark-unusable>
<toolset name="msvc"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="10"/>
</mark-unusable>
<test name="random_test">
<mark-failure>
<toolset name="cw-8_3*"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<note author="B. Dawes" refid="2"/>
</mark-failure>
<mark-failure>
<toolset name="intel-win32-*"/>
<note author="S. Slapeta" refid="1"/>
</mark-failure>
</test>
</library>
<!-- range -->
<library name="range">
<mark-unusable>
<toolset name="mipspro"/>
<toolset name="dmc-8_43-stlport-4_5_3"/>
<toolset name="gcc-2.95.3*"/>
<toolset name="sunpro-5_3-sunos"/>
</mark-unusable>
<mark-expected-failures>
<test name="array"/>
<toolset name="como-4_3_3*"/>
<toolset name="borland-5_6_4"/>
<note refid="27" author="Thorsten Ottosen"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="iterator_range"/>
<toolset name="msvc-stlport"/>
<toolset name="vc-6_5-stlport"/>
<toolset name="tru64cxx65"/>
<note author="Thorsten Ottosen">
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="partial_workaround"/>
<toolset name="vc-7_1"/>
<toolset name="vc-8_0"/>
<toolset name="intel-win32-8_1"/>
<toolset name="intel-win32-9_0"/>
<note author="Thorsten Ottosen">
This failure is of no importance to this compiler.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="reversible_range"/>
<toolset name="tru64cxx65"/>
<note author="Thorsten Ottosen">
This test probably fails because it uses built-in arrays. So do expect these
functions to work in normal code.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="string"/>
<toolset name="tru64cxx65"/>
<toolset name="borland-5_6_4"/>
<note author="Thorsten Ottosen">
The string functionality is expected to work if
the user employs std::string and stays away from built-in
arrays.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="sub_range"/>
<toolset name="vc-8_0"/>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<toolset name="msvc-stlport"/>
<toolset name="vc-6_5-stlport"/>
<toolset name="vc-7_0"/>
<toolset name="tru64cxx65"/>
<note refid="6" author="Thorsten Ottosen">
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="sub_range"/>
<toolset name="cw-9_5-darwin"/>
<note author="Thorsten Ottosen">
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.
</note>
</mark-expected-failures>
</library>
<!-- regex -->
<library name="regex">
<test name="regex_token_iterator_eg_2">
<mark-failure>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<note author="J. Maddock"/>
</mark-failure>
</test>
<test name="posix_api_check">
<mark-failure>
<toolset name="como-4_3_3-vc7*"/>
<note author="J. Maddock"/>
</mark-failure>
</test>
<test name="*_dll">
<mark-failure>
<toolset name="*como-4_3_3*"/>
<note author="J. Maddock">
This test requires features that are unsupported by Como:
use and building of dll's mainly.
</note>
</mark-failure>
</test>
<mark-expected-failures>
<test name="static_mutex_test"/>
<test name="grep"/>
<toolset name="*como-4_3_3*"/>
<note author="J. Maddock">
This test requires features that are unsupported by Como:
use and building of dll's mainly.
</note>
</mark-expected-failures>
<test name="concept_check">
<mark-failure>
<toolset name="vc-8_0"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65-042"/>
<note author="John Maddock" refid="2"/>
</mark-failure>
</test>
<test name="grep">
<mark-failure>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="John Maddock">
This test fails because a dependency (Boost.Program Options) doesn't build with this compiler.
</note>
</mark-failure>
</test>
<mark-expected-failures>
<test name="regex_regress"/>
<test name="regex_regress_dll"/>
<toolset name="iw-7_1-vc6-stlp-4_5_3"/>
<note author="John Maddock" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="unicode_iterator_test"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note author="John Maddock" refid="6"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="regex_timer"/>
<toolset name="vc-6_5-stlport"/>
<note author="John Maddock">
Test fails due to unresilved externals from STLport: appears to be
an STLport bug. </note>
</mark-expected-failures>
</library>
<!-- signals -->
<library name="signals">
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
</mark-unusable>
<test name="dead_slot_test">
<mark-failure>
<toolset name="*como-4_3_3*"/>
<note refid="3" author="D. Gregor"/>
</mark-failure>
</test>
<test name="signal_test">
<mark-failure>
<toolset name="cw-8_3*"/>
<note author="B. Dawes" refid="2"/>
</mark-failure>
<mark-failure>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="msvc"/>
<toolset name="vc-6_5"/>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="3"/>
</mark-failure>
</test>
<test name="trackable_test">
<mark-failure>
<toolset name="*como-4_3_3*"/>
<note refid="3" author="D. Gregor"/>
</mark-failure>
</test>
</library>
<!-- static_assert -->
<library name="static_assert">
<test name="static_assert_example_2">
<mark-failure>
<toolset name="sunpro-5_3-sunos"/>
<note author="J. Maddock" refid="4"/>
</mark-failure>
</test>
</library>
<!-- test -->
<library name="test">
<mark-expected-failures>
<test name="ifstream_line_iterator_test"/>
<toolset name="sunpro*"/>
<note author="Gennadiy Rozental" refid="2"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="custom_exception_test"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<note author="Gennadiy Rozental" refid="2"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="errors_handling_test"/>
<toolset name="*como-4_3_3*"/>
<note author="B. Dawes" refid="3"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="token_iterator_test"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="iw-7_1-vc6"/>
<toolset name="vc-7_0"/>
<toolset name="vc-7_0-stlport"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="tru64cxx65-042"/>
<toolset name="sunpro*"/>
<toolset name="borland*"/>
<note author="Gennadiy Rozental" refid="3"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_fp_comparisons"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="vc-7_0-stlport"/>
<toolset name="borland-5_6_4"/>
<note author="Gennadiy Rozental" refid="3"/>
</mark-expected-failures>
<mark-expected-failures reason="?">
<test name="basic_cstring_test"/>
<toolset name="gcc-2.95.3-linux"/>
<note refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="errors_handling_test"/>
<test name="test_tools_test"/>
<toolset name="cw-9_5-darwin"/>
<note refid="29" author="Doug Gregor"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="errors_handling_test"/>
<toolset name="vc-8_0"/>
<note refid="29" author="Doug Gregor"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="errors_handling_test"/>
<test name="test_tools_test"/>
<toolset name="cw-9_4"/>
<note refid="29" author="Doug Gregor"/>
</mark-expected-failures>
</library>
<!-- thread -->
<library name="thread">
<mark-unusable>
<toolset name="*como-4_3_3*"/>
<note author="B. Dawes" refid="10"/>
</mark-unusable>
<test name="test_mutex">
<mark-failure>
<toolset name="vc-7_0"/>
<note author="B. Dawes" refid="0"/>
<note author="B. Dawes" refid="6"/>
</mark-failure>
</test>
<test name="test_tss_lib">
<mark-failure>
<toolset name="mingw*"/>
<toolset name="borland-5_6_4"/>
<toolset name="cw-*"/>
<toolset name="vc-7_0"/>
<note author="Aleksey Gurtovoy" date="19 Sep 2004">
This functionality has not been implemented yet. The library
developers plan to implement it for the next release.
</note>
</mark-failure>
</test>
<mark-expected-failures>
<test name="*_lib"/>
<toolset name="intel-8.0-linux*"/>
<note author="Aleksey Gurtovoy">
This failure is caused by a conflict between the compiler
and the testing environment: the tests are run on a platform with
<i>too recent</i> version of glibc, which is not currently
supported by the compiler vendor (Intel).
If you are having the same problem and <i>really</i> want to make
things work, renaming <code>strol</code> symbol in the
compiler's static runtime library (<code>libcprts.a</code>) to
something else is known to resolve the issue.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_barrier_lib"/>
<toolset name="vc-8_0"/>
<note author="Aleksey Gurtovoy" refid="6"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="test_thread"/>
<toolset name="vc-7_1"/>
<note author="Aleksey Gurtovoy" refid="6"/>
</mark-expected-failures>
<mark-expected-failures reason="?">
<test name="*_lib"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note author="Aleksey Gurtovoy" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="*_lib"/>
<toolset name="gcc-*-sunos"/>
<note author="Caleb Epstein">
SunOS does not provide static versions of -lrt or
-lpthread, and gcc -static refuses to link with any
shared objects, so these tests don't compile.
</note>
</mark-expected-failures>
</library>
<!-- tuple -->
<library name="tuple">
<mark-unusable>
<toolset name="sunpro-5_3-sunos"/>
</mark-unusable>
<test name="io_test">
<toolset name="intel-win32"/>
<note author="B. Dawes" refid="3"/>
</test>
</library>
<!-- type_traits -->
<library name="type_traits">
<mark-expected-failures>
<test name="function_traits_test"/>
<test name="remove_bounds_test"/>
<test name="remove_const_test"/>
<test name="remove_cv_test"/>
<test name="remove_pointer_test"/>
<test name="remove_reference_test"/>
<test name="remove_volatile_test"/>
<test name="decay_test"/>
<test name="extent_test"/>
<test name="remove_extent_test"/>
<test name="remove_all_extents_test"/>
<test name="rank_test"/>
<test name="is_unsigned_test"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Aleksey Gurtovoy">
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
<a href="http://www.boost.org/libs/type_traits/index.html#transformations">
http://www.boost.org/libs/type_traits/index.html#transformations</a> for
details).
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="tricky_incomplete_type_test"/>
<test name="decay_test"/>
<test name="extent_test"/>
<test name="is_base_of_test"/>
<test name="rank_test"/>
<test name="remove_all_extents_test"/>
<test name="remove_extent_test"/>
<test name="tricky_function_type_test"/>
<toolset name="borland-5_6_4"/>
<note author="John Maddock" refid="2"/>
</mark-expected-failures>
<test name="tricky_is_enum_test">
<mark-failure>
<toolset name="borland-5_6_4"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="gcc-2.95.3-*"/>
</mark-failure>
</test>
<test name="tricky_incomplete_type_test">
<mark-failure>
<toolset name="iw-7_1*"/>
<note author="John Maddock" refid="2"/>
</mark-failure>
</test>
<test name="is_abstract_test">
<mark-failure>
<toolset name="borland-5_6_4"/>
<toolset name="cw-8_3*"/>
<toolset name="cw-9_3*"/>
<toolset name="cw-9_4*"/>
<toolset name="cw-9_5*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="mingw-3_3*"/>
<toolset name="gcc-2*"/>
<toolset name="gcc-3.2*"/>
<toolset name="gcc-3.3*"/>
<toolset name="gcc-3_3*"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65-042"/>
<toolset name="darwin"/>
<toolset name="mingw"/>
<note author="Aleksey Gurtovoy">
This functionality is available only on compilers that implement C++ Core Language
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#337">Defect Report 337</a>.
</note>
</mark-failure>
</test>
<mark-expected-failures>
<test name="is_polymorphic_test"/>
<toolset name="gcc-2.95.3-stlport-*"/>
<note author="Doug Gregor" refid="3"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="decay_test"/>
<test name="extent_test"/>
<test name="has_nothrow_assign_test"/>
<test name="has_nothrow_constr_test"/>
<test name="has_nothrow_copy_test"/>
<test name="has_trivial_assign_test"/>
<test name="has_trivial_constr_test"/>
<test name="has_trivial_copy_test"/>
<test name="has_trivial_destructor_test"/>
<test name="is_array_test"/>
<test name="is_base_and_derived_test"/>
<test name="is_base_of_test"/>
<test name="is_class_test"/>
<test name="is_convertible_test"/>
<test name="is_object_test"/>
<test name="is_pod_test"/>
<test name="is_polymorphic_test"/>
<test name="rank_test"/>
<test name="remove_all_extents_test"/>
<test name="remove_bounds_test"/>
<test name="remove_extent_test"/>
<toolset name="sunpro-5_3-sunos"/>
<note author="John Maddock">
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.
</note>
</mark-expected-failures>
<mark-expected-failures>
<test name="is_empty_test"/>
<test name="is_function_test"/>
<test name="is_member_func_test"/>
<test name="is_member_obj_test"/>
<test name="is_reference_test"/>
<test name="tricky_function_type_test"/>
<test name="tricky_incomplete_type_test"/>
<test name="tricky_is_enum_test"/>
<toolset name="sunpro-5_3-sunos"/>
<note author="John Maddock" refid="2"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="tricky_function_type_test"/>
<test name="is_convertible_test"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<toolset name="gcc-2.95.3-linux"/>
<note author="John Maddock" refid="2"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="aligned_storage_test"/>
<toolset name="cw-8_3"/>
<note author="John Maddock">
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.
</note>
</mark-expected-failures>
</library>
<!-- utility/enable_if -->
<library name="utility/enable_if">
<mark-unusable>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<toolset name="cw-8_3*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note refid="3"/>
</mark-unusable>
</library>
<!-- utility -->
<library name="utility">
<test name="addressof_test">
<mark-failure>
<toolset name="sunpro-5_3-sunos"/>
<note author="D. Gregor" refid="3"/>
</mark-failure>
</test>
<test name="fun_out_iter_example">
<mark-failure>
<toolset name="como-win32"/>
<note author="B. Dawes" refid="4"/>
</mark-failure>
</test>
<test name="result_of_test">
<mark-failure>
<toolset name="borland-5*"/>
<toolset name="cw-8_3*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<toolset name="gcc-2.95.3*"/>
<toolset name="sunpro-5_3-sunos"/>
<note refid="3" author="D. Gregor"/>
</mark-failure>
</test>
<mark-expected-failures>
<test name="value_init_test"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note author="Aleksey Gurtovoy">
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).
</note>
</mark-expected-failures>
</library>
<!-- variant -->
<library name="variant">
<mark-unusable>
<toolset name="mipspro"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="tru64cxx65*"/>
<note refid="2"/>
</mark-unusable>
<test name="recursive_variant_test">
<mark-failure>
<toolset name="como-win32"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note refid="3"/>
</mark-failure>
</test>
<mark-expected-failures>
<test name="recursive_variant_test"/>
<test name="variant_test1"/>
<test name="variant_test5"/>
<test name="variant_visit_test"/>
<toolset name="borland"/>
<toolset name="borland-5_6_4"/>
<note author="Aleksey Gurtovoy" refid="3"/>
</mark-expected-failures>
<test name="variant_reference_test">
<mark-failure>
<toolset name="cw-8_3*"/>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="vc-7_0"/>
<note refid="3"/>
</mark-failure>
<mark-failure>
<toolset name="intel-win32"/>
<toolset name="iw-7_1*"/>
<toolset name="intel-7.1*"/>
<note refid="2"/>
</mark-failure>
</test>
</library>
<!-- wave -->
<library name="wave">
<mark-unusable>
<toolset name="msvc*"/>
<toolset name="vc-6_5*"/>
<toolset name="sunpro-5_3-sunos"/>
<toolset name="borland-5_5_1"/>
<toolset name="borland-5_6_4"/>
<toolset name="gcc-2.95.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
<toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
<note refid="29"/>
</mark-unusable>
<mark-unusable>
<toolset name="vc-7_0"/>
<note>
This toolset isn't supported because of the used Spirit V1.8.x, which in turn is
not usable with this toolset.
</note>
</mark-unusable>
<mark-expected-failures>
<test name="testwave"/>
<toolset name="cw-9_5-darwin"/>
<toolset name="cw-8*"/>
<note author="Rene Rivera" refid="29"/>
</mark-expected-failures>
<mark-expected-failures>
<test name="testwave"/>
<toolset name="gcc-3.2.3-linux"/>
<!-- toolset name="gcc-3.3.6-linux"/ -->
<note author="Hartmut Kaiser" refid="29"/>
</mark-expected-failures>
</library>
<!-- /////////////// Standard note definitions /////////////// -->
<note id="0">
This test fails only intermittently.
</note>
<note id="1">
The failure is caused by a problem in Boost code. The Boost developers is aware of
the problem and plan to fix it.
</note>
<note id="2">
The failure is caused by a compiler bug.
</note>
<note id="3">
The failure is caused by a compiler bug, which has been reported to the compiler
supplier (or is already known to them).
</note>
<note id="4">
The failure is caused by a standard library bug.
</note>
<note id="5">
The failure is caused by a standard library bug, which has been reported to the
standard library supplier (or is already known to them).
</note>
<note id="6">
The failure is probably caused by the test code, harness, or configuration. Thus
it may not affect users of the library.
</note>
<note id="9">
The failure is serious and likely to prevent all use of this Boost library with this compiler.
</note>
<note id="10">
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).
</note>
<note id="14">
The failure is caused by a platform API bug.
</note>
<note id="15">
The failure is caused by a platform API bug, which has been reported to the platform API
supplier (or is already known to them).
</note>
<note id="16">
The failure is not serious and will not affect most users. The library degrades gracefully.
</note>
<note id="17">
This compiler's bugs are not supported by the library.
</note>
<note id="18">
Locales missing or adequately supported by this compiler.
</note>
<note id="19">
Missing or inadequate wchar/wstring/wstream support for this compiler.
</note>
<note id="20">
No std iterator traits for this compiler.
</note>
<note id="21">
Library has limited input/output support due to compiler inadequacies.
</note>
<note id="22">
No high precision clock for this platform.
</note>
<note id="23">
A bug in standard library prevents passing std::set from DLL to
application. A fixed &lt;tree&gt; header is available from
http://www.dinkumware.com/vc_fixes.html.
</note>
<note id="24">
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.
</note>
<note id="25">
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, <code>so</code>, etc.
</note>
<note id="26">
This failure is caused by a compiler bug with no known workaround.
Patches are welcome!
</note>
<note id="27" >
This failure is caused by bugs in the standard library implementation and/or
bugs in the compiler.
</note>
<note id="28">
Unresearched failure, please contact library developers for more
information about possible causes.
</note>
<note id="29">
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.
</note>
<note id="30">
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.
</note>
<note id="31">
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.
</note>
<note id="32">
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.
</note>
<note id="33">
The failures are caused by the wrong handling of the
<code>std::internal</code> flag in the iostreams implementation of the
standard library used on that compiler/platform combo. Apart from that,
the format library works as expected.
</note>
<note id="34">
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.
</note>
<note id="35">
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.
</note>
</explicit-failures-markup>
Reference in a new issue View git blame Copy permalink