boost/status/explicit-failures-markup.xml

<explicit-failures-markup 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:noNamespaceSchemaLocation="explicit-failures.xsd"
    >

    <!-- 
    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.3" status="required"/>
    <mark-toolset name="cw-8.3" status="required"/>
    <mark-toolset name="msvc" status="required"/>
    <mark-toolset name="msvc-stlport" status="required"/>
    <mark-toolset name="vc7" status="required"/>
    <mark-toolset name="vc7.1" status="required"/>
    <mark-toolset name="vc8.0" status="required"/>
    <mark-toolset name="mingw-3.4.2" status="required"/>
    <mark-toolset name="mingw-3.3.1" status="required"/>
    <mark-toolset name="intel-win32-7.1-vc6" status="required"/>
    <mark-toolset name="intel-win32-7.1-vc6-stlport-4.5.3" status="required"/>
    <mark-toolset name="intel-win32-8.0" 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-3.3.3-linux" status="required"/>
    <mark-toolset name="gcc-3.4.2-linux" status="required"/>
    <mark-toolset name="intel-7.1-linux" status="required"/>
    <mark-toolset name="intel-8.0-linux" status="required"/>

    <!-- /////////////// Libraries /////////////// -->

    <!-- string_algo -->
    <library name="algorithm/string">
        <mark-unusable>
            <toolset name="borland"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="intel-win32-7.1-vc6"/>
            <toolset name="gcc-2.95.3-linux"/>
            <toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
            <toolset name="mipspro"/>
            <note author="P.Droba"/>
        </mark-unusable>
    </library>

    <!-- array -->
    <library name="array">
        <test name="array3">
            <mark-failure>
                <toolset name="borland"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="msvc"/>
                <toolset name="vc7"/>
                <note refid="3"/>
            </mark-failure>
        </test>
        <test name="array4">
            <mark-failure>
                <toolset name="borland"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="msvc"/>
                <toolset name="vc7"/>
                <note refid="3"/>
            </mark-failure>
        </test>
    </library>

    <!-- assign -->
    <library name="assign">
        <mark-expected-failures>
            <test name="array"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc7"/>
            <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="vc7"/>
            <note refid="6" author="Thorsten Ottosen"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="list_of"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc7"/>
            <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="multi_index_container"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="gcc-2.95.3*"/>
            <toolset name="intel-8.0-linux"/>
            <toolset name="gcc-3.4.1*"/>
            <toolset name="gcc-3.4.2*"/>
            <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="vc7"/>
            <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>
    </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>
    </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-win32-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="intel-win32-7.1-vc6-stlport-4.5.3"/>
                <note author="Aleksey Gurtovoy" refid="4"/>
            </mark-failure>
        </test>
    </library>


    <!-- conversion -->
    <library name="conversion">
        <test name="lexical_cast_test">
            <mark-failure>
                <toolset name="vc8.0"/>
                <note author="Aleksey Gurtovoy" refid="4"/>
            </mark-failure>
        </test>
    </library>


    <!-- date_time -->
    <library name="date_time">
        <mark-unusable>
            <toolset name="msvc-stlport"/>
            <toolset name="intel-win32-7.1-vc6-stlport-4.5.3"/>
            <toolset name="intel-win32-7.1-vc6"/>
        </mark-unusable>

        <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="vc7"/>
                <toolset name="cw-8.3*"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="mingw-3*"/>
                <toolset name="gcc"/>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="*como-win32-4.3.3*"/>
                <note author="B. Garst" refid="19,21"/>
            </mark-failure>
        </test>
        <test name="testtime_wstream">
            <mark-failure>
                <toolset name="gcc"/>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="msvc"/>
                <toolset name="vc7"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="mingw-3*"/>
                <toolset name="*como-win32-4.3.3*"/>
                <note author="B. Garst" refid="19,21,22"/>
            </mark-failure>
        </test>
        <test name="testtime_wstream_std_config">
            <mark-failure>
                <toolset name="gcc"/>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="msvc"/>
                <toolset name="vc7"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="mingw-3*"/>
                <toolset name="*como-win32-4.3.3*"/>
                <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*"/>
                <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-2.95.3-stlport-4.5.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="msvc"/>
                <toolset name="mingw-3*"/>
                <toolset name="*como-win32-4.3.3*"/>
                <note author="B. Garst" refid="18,19"/>
            </mark-failure>
            <mark-failure>
                <toolset name="cw-8.3*"/>
                <note author="R. Rivera" refid="25"/>
            </mark-failure>
        </test>
        <test name="testday_dll">
            <mark-failure>
                <toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
            </mark-failure>
        </test>
        <test name="testgreg_year_dll">
            <mark-failure>
                <toolset name="*como-win32-4.3.3*"/>
                <toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
            </mark-failure>
        </test>
        <test name="testparse_date">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="msvc"/>
                <toolset name="vc7"/>
                <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-win32-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"/>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="msvc"/>
                <toolset name="cw-8.3*"/>
                <toolset name="vc7"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="mingw-3*"/>
                <toolset name="*como-win32-4.3.3*"/>
                <note author="B. Garst" refid="18,19,20"/>
            </mark-failure>
        </test>
        <test name="testdate_dll">
            <mark-failure>
                <toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
                <toolset name="*como-win32-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="gcc-2.95.3-stlport-4.5.3-linux"/>
                <toolset name="*como-win32-4.3.3*"/>
                <note author="J. Garland" date="30 Jan 2004" id="24"/>
            </mark-failure>
        </test>
        <test name="*_dll">
            <mark-failure>
                <toolset name="*como-win32-4.3.3*"/>
                <note author="J. Garland" date="30 Jan 2004" id="24"/>
            </mark-failure>
        </test>
        <test name="*">
            <mark-failure>
                <toolset name="intel-win32"/>
                <note refid="10"/>
            </mark-failure>
        </test>
    </library>


    <!-- dynamic_bitset -->
    <library name="dynamic_bitset">
        <test name="dyn_bitset_unit_tests4">
            <mark-failure>
                <toolset name="cw-9.3"/>
                <toolset name="intel-8.0-linux"/>
                <note author="Aleksey Gurtovoy" 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>
        <test name="operations_test">
            <mark-failure>
                <toolset name="vc8.0"/>
                <note author="Aleksey Gurtovoy" refid="4"/>
            </mark-failure>
        </test>
    </library>


    <!-- graph -->
    <library name="graph">
        <mark-unusable>
            <toolset name="borland-5.6.4"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
        </mark-unusable>
        <mark-expected-failures>
            <test name="adj_matrix_cc"/>
            <test name="bfs_cc"/>
            <test name="bundled_properties"/>
            <test name="dfs_cc"/>
            <test name="dijkstra_cc"/>
            <test name="subgraph"/>
            <test name="transitive_closure_test"/>
            <test name="vector_graph_cc"/>
            <toolset name="vc7"/>
            <note refid="3" author="D. Gregor"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="betweenness_centrality_test"/>
            <toolset name="intel-win32-7.1-vc6*"/>
            <toolset name="vc7"/>
            <note refid="3" author="Aleksey Gurtovoy"/>
        </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="intel-win32-7.1-v6*"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <note refid="4" author="Aleksey Gurtovoy"/>
        </mark-expected-failures>
    </library>


    <!-- lambda -->
    <library name="lambda">
        <mark-unusable>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="borland"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.5.1"/>
            <toolset name="vc7"/>
            <note refid="17">
            </note>
        </mark-unusable>
    </library>

    <!-- logic -->
    <library name="logic">
      <test name="tribool_io_test">
        <mark-failure>
          <toolset name="msvc-stlport"/>
          <toolset name="gcc-2.95.3-linux"/>
          <note author="Douglas Gregor" date="27 Jul 2004" 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"/>            
            <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="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"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="msvc*"/>
            <toolset name="vc7"/>
            <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>

    </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>
        <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>
    </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"/>
            <note author="J. L&#243;pez" date="09 Jul 2004" refid="17"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="meta-como-win32-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>
    </library>


    <!-- optional -->
    <library name="optional">
        <mark-expected-failures>
            <test name="optional_test_ref"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc7"/>
            <note author="Aleksey Gurtovoy" refid="3"/>
        </mark-expected-failures>
    </library>


    <!-- serialization -->
    <library name="serialization">
        <mark-unusable>
            <toolset name="acc" />
            <toolset name="vacpp" />
            <toolset name="mipspro" />
            <toolset name="tru64cxx" />
            <toolset name="tru64cxx65" />
            <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="20 Sep 2004" refid="18,19"/>
        </mark-unusable>
        <test name="void_cast">
            <mark-failure>
                <toolset name="msvc"/>
                <note author="Robert Ramey" date="20 Sep 2004" refid="16"/>
            </mark-failure>
        </test>
        <test name="*_warchive">
            <mark-failure>
                <toolset name="mingw*"/>
                <toolset name="gcc-2.95.3-linux"/>
                <note author="Robert Ramey" date="20 Sep 2004" refid="19"/>
            </mark-failure>
            <mark-failure>
                <toolset name="*como-win32-4.3.3*"/>
                <note author="Robert Ramey" date="20 Sep 2004" refid="5"/>
            </mark-failure>
        </test>
        <test name="test_codecvt_null">
            <mark-failure>
                <toolset name="mingw-3*"/>
            </mark-failure>
            <note author="Robert Ramey" date="20 Sep 2004" refid="19"/>
        </test>
        <test name="test_utf8_codecvt">
            <mark-failure>
                <toolset name="mingw*"/>
            </mark-failure>
            <note author="Robert Ramey" date="20 Sep 2004" refid="19"/>
        </test>
        <mark-expected-failures>
            <test name="*"/>
            <toolset name="vc8.0"/>
            <note author="Aleksey Gurtovoy">
                This failure is caused by a compiler bug in version 14.00.40809 that has 
                been fixed in the latest development "alpha".
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="test_array*"/>
            <test name="test_demo_fast_binary_archive"/>
            <toolset name="borland*"/>
            <note author="Robert Ramey" 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_exception"/>
            <test name="test_demo_fast_binary_archive"/>
            <test name="test_demo_shared_ptr"/>
            <test name="test_demo_xml*"/>
            <toolset name="msvc*"/>
            <toolset name="vc7"/>
            <note author="Robert Ramey" refid="6">
                msvc 6 compiler failure.  Sometimes can be worked around
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="test_demo_pimpl"/>
            <test name="test_diamond*"/>
            <test name="test_mi*"/>
            <test name="test_mult_archive_types"/>
            <toolset name="msvc*"/>
            <toolset name="vc7"/>
            <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_level_class_info_load*"/>
            <toolset name="*"/>
            <note author="Robert Ramey" refid="0">
                Some tests depend upon the existence of an output file
                created by another test. If tests are not executed in expected sequence,
                a test may fail.  This usually harmless.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="*"/>
            <toolset name="msvc-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 known 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">
                All tests that serialize derived pointers currently fail with Metrowerks Compilers
        </note>
        </mark-expected-failures>
    </library>


    <!-- spirit -->
    <library name="spirit">
        <mark-unusable>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="borland-5.5.1"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="vc7"/>
            <toolset name="gcc-2.95.3-linux"/>
            <toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
            <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="intel-win32-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"/>
            <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="bug_fixes*"/>
            <test name="chset_tests*"/>
            <test name="epsilon_tests*"/>
            <toolset name="vc8.0"/>
            <note author="Aleksey Gurtovoy">
                This failure is caused by a compiler bug in version 14.00.40809 that has 
                been fixed in the latest development "alpha".
            </note>
        </mark-expected-failures>

    </library>

    <!-- function -->
    <library name="function">
        <test name="allocator_test">
            <mark-failure>
                <toolset name="msvc"/>
                <toolset name="vc7"/>
                <note author="B. Dawes" refid="5"/>
            </mark-failure>
        </test>
        <test name="contains_test">
            <mark-failure>
                <toolset name="msvc"/>
                <toolset name="msvc-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="vc7"/>
                <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="vc7"/>
                <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="vc7"/>
                <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="vc7"/>
                <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="vc7"/>
                <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="vc7"/>
                <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="vc7"/>
                <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="vc7"/>
                <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" corner-case="yes">
            <mark-failure>
                <toolset name="borland"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="msvc"/>
                <toolset name="vc7"/>
                <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" corner-case="yes"/>
        
        <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">
        <test name="quaternion_mult_incl_test">
            <mark-failure>
                <toolset name="intel-win32"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
    </library>


    <!-- numeric/conversion -->
    <library name="numeric/conversion">
        <mark-unusable>
            <toolset name="gcc-2.95.3-linux"/>            
            <note author="Aleksey Gurtovoy" refid="5"/>
        </mark-unusable>
        <mark-expected-failures>
            <test name="udt_support_test"/>
            <toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
            <toolset name="intel-7.1-linux"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <note author="Aleksey Gurtovoy" refid="2"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="converter_test"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc7"/>
            <note author="Aleksey Gurtovoy" refid="2"/>
        </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="vc7"/>
        </mark-unusable>
        <test name="test_float">
            <mark-failure>
                <toolset name="borland-5.5.1"/>
                <toolset name="intel-win32-7.1-vc6"/>
                <toolset name="intel-win32-7.1-vc6-stlport-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"/>
            <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"/>
            <note author="M.Stevens" refid="2"/>
        </mark-unusable>
        <test name="test2">
            <mark-failure>
                <toolset name="tru64cxx65"/>
                <note author="M.Stevens" refid="6"/>
            </mark-failure>
        </test>
        <test name="test3">
            <mark-failure>
                <toolset name="intel-win32-8.1"/>
                <note author="S. Slapeta" refid="3"/>
            </mark-failure>
        </test>
        <test name="test4">
            <mark-failure>
                <toolset name="intel-win32-8.1"/>
                <note author="S. Slapeta" refid="3"/>
            </mark-failure>
        </test>
        <test name="test5">
            <mark-failure>
                <toolset name="intel-win32-8.1"/>
                <note author="S. Slapeta" refid="3"/>
            </mark-failure>
        </test>
        <test name="test6">
            <mark-failure>
                <toolset name="intel-win32-8.1"/>
                <note author="S. Slapeta" refid="3"/>
            </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"/>
            <note refid="2"/>
        </mark-unusable>

        <!-- Mark expected failures -->

        <test name="unicode_test*">
            <mark-failure>
                <toolset name="intel-win32-7.1-vc6"/>
                <toolset name="intel-win32-7.1-vc6-stlport-4.5.3"/>
                <toolset name="msvc"/>
                <toolset name="msvc-stlport"/>
                <toolset name="vc7"/>
                <note>The failures are caused by problems 
                    with std::locale implementation</note>
            </mark-failure>
        </test>

        <test name="unicode_test">
            <mark-failure>
                <toolset name="cw-8.3*"/>
                <note>The test fails at runtime for unknown reason</note>
            </mark-failure>
        </test>


        <test name="options_description_test_dll">
             <mark-failure>
                <toolset name="msvc"/>
                <toolset name="intel-win32-7.1-vc6"/>
                <note refid="23"/>
            </mark-failure>
        </test>

        <test name="variable_map_test_dll">
             <mark-failure>
                <toolset name="intel-win32-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-win32-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"/>            
            <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>

    </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"/>            
            <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>
    </library>

    <!-- random -->
    <library name="random">
        <mark-unusable>
            <toolset name="msvc"/>
            <toolset name="vc7"/>
            <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="gcc-2.95.3*"/>
            <toolset name="mipspro"/>
            <note author="Thorsten Ottosen"/>
        </mark-unusable>
        <mark-expected-failures>
            <test name="array_test"/>
            <toolset name="como-win32-4.3.3*"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc7"/>
            <note refid="27" author="Thorsten Ottosen"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="iterator_range"/>
            <toolset name="cw-8.3*"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc7"/>
            <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.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="reversible_range_test"/>
            <toolset name="vc7"/>
            <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_test"/>
            <toolset name="vc7"/>
            <toolset name="tru64cxx65"/>
            <note author="Thorsten Ottosen">
                The string functionality is expected to work if
                the user employs std::string.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="sub_range"/>
            <toolset name="vc8.0"/>
            <toolset name="intel-win32-7.1-vc6-stlport-4.5.3"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc7"/>
            <toolset name="cw-8.3*"/> 
            <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>
    </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-win32-4.3.3-vc7*"/>
                <note author="J. Maddock"/>
            </mark-failure>
        </test>
        <test name="*_dll">
            <mark-failure>
                <toolset name="*como-win32-4.3.3*"/>
                <note author="J. Maddock"/>
            </mark-failure>
        </test>
    </library>

    <!-- signals -->
    <library name="signals">
        <test name="dead_slot_test">
            <mark-failure>
                <toolset name="*como-win32-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="vc7"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
        <test name="trackable_test">
            <mark-failure>
                <toolset name="*como-win32-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>
    </library>

    <!-- test -->
    <library name="test">
        <mark-expected-failures>
            <test name="custom_exception_test"/>
            <toolset name="msvc*"/>
            <note author="Gennadiy Rozental" refid="2"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="errors_handling_test"/>
            <toolset name="*como-win32-4.3.3*"/>
            <note author="B. Dawes" refid="3"/>
        </mark-expected-failures>

    </library>


    <!-- thread -->
    <library name="thread">
        <mark-unusable>
            <toolset name="*como-win32-4.3.3*"/>
            <note author="B. Dawes" refid="10"/>
        </mark-unusable>
        <test name="test_mutex">
            <mark-failure>
                <toolset name="vc7"/>
                <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-8.3*"/>
                <toolset name="cw-9.3"/>
                <toolset name="vc7"/>
                <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>
    </library>


    <!-- tuple -->
    <library name="tuple">
        <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"/>
            <toolset name="msvc"/>
            <toolset name="vc7"/>
            <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>
        <test name="tricky_incomplete_type_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
            </mark-failure>
        </test>
        <test name="tricky_is_enum_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="msvc"/>
                <toolset name="msvc-stlport"/>
            </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="msvc"/>
                <toolset name="msvc-stlport"/>
                <toolset name="vc7"/>
            </mark-failure>
        </test>
    </library>


    <!-- utility -->
    <library name="utility">
        <mark-expected-failures>
            <test name="enable_if_constructors"/>
            <test name="enable_if_dummy_arg_disambiguation"/>
            <test name="enable_if_lazy"/>
            <test name="enable_if_lazy_test"/>
            <test name="enable_if_member_templates"/>
            <test name="enable_if_namespace_disambiguation"/>
            <test name="enable_if_no_disambiguation"/>
            <test name="enable_if_partial_specializations"/>
            <toolset name="borland"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="cw-8.3*"/>
            <toolset name="msvc"/>
            <toolset name="msvc-stlport"/>
            <toolset name="vc7"/>
            <note refid="3"/>
        </mark-expected-failures>
        <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.6.4"/>
                <toolset name="cw-8.3*"/>
                <toolset name="msvc"/>
                <toolset name="msvc-stlport"/>
                <toolset name="vc7"/>
                <note refid="3" author="D. Gregor"/>
            </mark-failure>
        </test>
    </library>


    <!-- variant -->
    <library name="variant">
        <mark-unusable>
            <toolset name="mipspro"/>
            <note refid="2"/>
        </mark-unusable>
        <test name="recursive_variant_test">
            <mark-failure>
                <toolset name="borland"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="como-win32"/>
                <toolset name="msvc"/>
                <toolset name="msvc-stlport"/>
                <toolset name="vc7"/>
                <note refid="3"/>
            </mark-failure>
        </test>
        <test name="variant_test1">
            <mark-failure>
                <toolset name="borland"/>
                <toolset name="borland-5.6.4"/>
                <note refid="2"/>
            </mark-failure>
        </test>
        <test name="variant_reference_test">
            <mark-failure>
                <toolset name="cw-8.3*"/>
                <toolset name="msvc"/>
                <toolset name="msvc-stlport"/>
                <toolset name="vc7"/>
                <note refid="3"/>
            </mark-failure>
            <mark-failure>
                <toolset name="intel-win32"/>
                <toolset name="intel-win32-7.1*"/>
                <toolset name="intel-7.1*"/>
                <note refid="2"/>
            </mark-failure>
        </test>
    </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 developer is aware of 
        the problem and plans 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>
    
    <!-- R. Rivera -->
    <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, so, etc.
    </note>

    <note id="26">
        This failure is caused by a compiler bug with no known workaround. 
        Patches are welcome!
    </note>

    <!-- Thorsten Ottosen -->
    <note id="27" >
        This failure is caused by bugs in the standard library implementation and/or
        bugs in the compiler. 
    </note>

</explicit-failures-markup>