boost/status/explicit-failures-markup.xml

<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="vc-8_0" 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-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-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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
              <toolset name="vc-6_5-stlport"/>
              <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-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-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="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="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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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-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-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="*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"/>
                <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-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-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"/>
                <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"/>
                <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"/>
                <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-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-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="testfacet">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="msvc"/>
                <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="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-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-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="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_5*"/>
            <note author="J. Garland">
                 Although these tests compile, the execution aborts for
                 an unknown reason.  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>
    </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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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>
    </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="mingw-3_4_2"/>
            <toolset name="gcc-3_3_3-cygwin"/>
            <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="stdio_filter_test"/>
            <toolset name="*como-4_3_3*"/>
            <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_3_3-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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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-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"/>
               <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"/>
            <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>
    </library>


    <!-- optional -->
    <library name="optional">
        <mark-expected-failures>
            <test name="optional_test_ref"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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>

    <!-- serialization -->
    <library name="serialization">
        <mark-unusable>
            <toolset name="acc*" />
            <toolset name="vacpp*" />
            <toolset name="mipspro*" />
            <toolset name="dmc*" />
            <toolset name="sunpro-5_3-sunos" />
            <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="msvc*"/>
             <toolset name="vc-6_5*"/>
             <toolset name="iw*"/>
             <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"/>
            <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_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"/>
            <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_diamond*"/>
            <test name="test_mult_archive_types"/>
            <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_exception"/>
            <test name="test_demo_xml*"/>
            <test name="test_shared_ptr*"/>
            <test name="test_mi*"/>
            <test name="test_non_default_ctor2*"/>
            <test name="test_exported*"/>
            <test name="test_registered*"/>
            <test name="test_unregistered*"/>
            <test name="test_shared_ptr*"/>
            <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_demo_fast_archive"/>
            <test name="test_no_rtti_*"/>
            <toolset name="cw*"/>
            <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>
    </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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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>
    </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-7_0"/>
                <note author="B. Dawes" refid="5"/>
            </mark-failure>
        </test>
        <test name="contains_test">
            <mark-failure>
                <toolset name="msvc"/>
                <toolset name="msvc-stlport"/>
                <toolset name="vc-6_5-stlport"/>
                <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-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-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-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-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-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-7_0"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
        <test name="std_bind_portable">
            <mark-failure>
                <toolset name="msvc"/>
                <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-7_0"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
    </library>


    <!-- iterator -->
    <library name="iterator">
        <test name="interoperable_fail">
            <mark-failure>
                <toolset name="borland"/>
                <toolset name="borland-5_6_4"/>
                <toolset name="msvc"/>
                <toolset name="vc-7_0"/>
                <note author="B. Dawes" refid="2"/>
            </mark-failure>
            <mark-failure>
                <toolset name="gcc"/>
                <note refid="3"/>
            </mark-failure>
            <mark-failure>
                <toolset name="*"/>
                <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="borland"/>
                <toolset name="borland-5_6_4"/>
                <toolset name="msvc"/>
                <toolset name="vc-7_0"/>
                <note refid="2"/>
            </mark-failure>
            <mark-failure>
                <toolset name="*"/>
                <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/interval -->
    <library name="numeric/interval">
        <mark-unusable>
            <toolset name="borland"/>
            <toolset name="borland-5_6_4"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <toolset name="vc-7_0"/>
            <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"/>
            <note author="M.Stevens" refid="30"/>
        </mark-unusable>
        <test name="test2">
            <mark-failure>
                <toolset name="tru64cxx65-041"/>
                <note author="M.Stevens" refid="6"/>
            </mark-failure>
        </test>
    </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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <note refid="17"/>
        </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="msvc-stlport"/>
                <toolset name="vc-6_5-stlport"/>
                <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="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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="options_description_test_dll"/>
            <test name="parsers_test_dll"/>
            <test name="variable_map_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>

    </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.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*">
            <mark-failure>
                <toolset name="intel-win32-8_0"/>
                <note author="S. Slapeta" refid="3"/>
            </mark-failure>
        </test>
        <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>
        </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"/>
                <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-stlport"/>
                <toolset name="vc-6_5-stlport"/>
                <toolset name="msvc"/>
                <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-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_test_fail_8">
            <mark-failure>
                <toolset name="cw-8_3*"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
        <test name="static_assert_example_2">
            <mark-failure>
                <toolset name="sunpro-5_3-sunos"/>
                <note author="J. Maddock" refid="4"/>
            </mark-failure>
        </test>
        <test name="static_assert_test_fail_function">
            <mark-failure>
                <toolset name="cw-8*"/>
                <note author="R. Rivera">
                    This failure is caused by a compiler optimization. The compiler
                    doesn't instantiate types not affecting semantics of the program,
                    per section 14.7.1 [temp.inst].
                </note>
            </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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <toolset name="vc-7_0"/>
            <toolset name="vc-7_0-stlport"/>
            <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>

    </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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
                <toolset name="vc-6_5-stlport"/>
                <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="msvc-stlport"/>
                <toolset name="vc-6_5-stlport"/>
                <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="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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="msvc-stlport"/>
                <toolset name="vc-6_5-stlport"/>
                <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"/>
            <note refid="2"/>
        </mark-unusable>
        <test name="recursive_variant_test">
            <mark-failure>
                <toolset name="como-win32"/>
                <toolset name="msvc"/>
                <toolset name="msvc-stlport"/>
                <toolset name="vc-6_5-stlport"/>
                <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="msvc-stlport"/>
                <toolset name="vc-6_5-stlport"/>
                <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="sunpro-5_3-sunos"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc-6_5-stlport"/>
            <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>
    </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>

</explicit-failures-markup>