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!
    
    Locally, the xmlint tool can be used:
    
        xmllint <two-dashes>valid explicit-failures-markup.xml <two-dashes>schema explicit-failures.xsd

    The following online services can be used to validate your changes to this
    file:

        - http://syseng.nist.gov/b2bTestbed/projects/xmlvalidation/instance_validation.html
        - http://xmlvalidation.com/

     With both tools 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.

    -->

    <!-- /////////////// Toolsets /////////////// -->
    <mark-toolset name="borland-5.6.4" status="required"/>
    <mark-toolset name="borland-5.8.2" status="required"/>
    <mark-toolset name="cw-9.4" status="required"/>
    <mark-toolset name="msvc-6.5" status="required"/>
    <mark-toolset name="msvc-6.5_stlport4" status="required"/>
    <mark-toolset name="msvc-7.0" status="required"/>
    <mark-toolset name="msvc-7.1_stlport4" status="required"/>
    <mark-toolset name="msvc-7.1" status="required"/>
    <mark-toolset name="msvc-8.0" status="required"/>
    <mark-toolset name="gcc-mingw-3.4.2" status="required"/>
    <mark-toolset name="gcc-mingw-3.4.5" status="required"/>
    <mark-toolset name="gcc-3.3.6" status="required"/>
    <mark-toolset name="gcc-cygwin-3.4.4" 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.5_linux" status="required"/>
    <mark-toolset name="gcc-3.4.5_linux" status="required"/>
    <mark-toolset name="gcc-4.0.3_linux" status="required"/>
    <mark-toolset name="gcc-4.1.0_linux" status="required"/>
    <mark-toolset name="gcc-3.4.5_linux_x86_64" status="required"/>
    <mark-toolset name="gcc-4.1.0_linux_x86_64" status="required"/>
    <mark-toolset name="darwin-4.0.1" status="required"/>
    <mark-toolset name="intel-vc71-win-9.1" status="required"/>
    <mark-toolset name="intel-linux-9.0" status="required"/>
    <mark-toolset name="hp_cxx-71_006_tru64" status="required"/>
    <mark-toolset name="sun-5.8" status="required"/>
    <mark-toolset name="gcc-4.1.1_sunos_i86pc" 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-6.5*"/>
            <toolset name="msvc-7.1_stlport4"/>
            <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>
        <test name="regex">
            <mark-failure>
                <toolset name="borland-5.8*"/>
			    <toolset name="borland-5.6.4"/>
                <note author="P.Droba">
                    The toolset is not supported by Boost.Regex.
                </note>
            </mark-failure>
        </test>
    </library>

    <!-- any -->
    <library name="any">
        <test name="any_to_ref_test">
          <mark-failure>
              <toolset name="msvc-6.5*"/>
              <note author="Vladimir Prus">
                The test fail with ICE, but the exact reason for ICE is not
                known. A minimal example of casting any to reference type
                seem to work. Anyone interested in using this functionality
                with msvc is suggested to do additional testing.
              </note>
          </mark-failure>
        </test>
    </library>


    <!-- array -->
    <library name="array">
        <test name="array0">
            <mark-failure>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-6.5_stlport4"/>
                <toolset name="msvc-7.0"/>
                <note author="A.Meredith">
                    Compilers need to support partial template specialization
                    to work with zero length arrays.
                </note>
            </mark-failure>
        </test>
        <test name="array3">
            <mark-failure>
                <toolset name="borland"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-6.5_stlport4"/>
                <toolset name="msvc-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-6.5"/>
                <toolset name="msvc-6.5_stlport4"/>
                <toolset name="msvc-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-6.5_stlport4"/>
            <toolset name="msvc-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="msvc-7.0"/>
            <toolset name="sunpro-5_3-sunos"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <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="hp_cxx-65*"/>
            <toolset name="borland-5*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-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_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="sun-5.8"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <toolset name="borland-5*"/>
            <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-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="mipspro"/>
            <toolset name="tru64cxx65"/>
            <toolset name="hp_cxx-65*"/>
            <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="hp_cxx-65*"/>
            <toolset name="borland-5*"/>
            <toolset name="gcc-2.95.3*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-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="hp_cxx-65*"/>
            <toolset name="borland-5*"/>
            <toolset name="gcc-2.95.3*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="mipspro"/>
            <note author="Thorsten Ottosen" >
                The test depends on Boost.Pointer Container which probably does not work for
                this compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ptr_map_inserter"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <toolset name="borland-5*"/>
            <toolset name="gcc-2.95.3*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="mipspro"/>
            <note author="Thorsten Ottosen" >
                The test depends on Boost.Pointer Container which probably does not work for
                this compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="std"/>
            <toolset name="sunpro-5_3-sunos"/>
            <note author="Thorsten Ottosen" >
                The test does not work for
                this compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="tuple_list_of"/>
            <toolset name="sunpro-5_3-sunos"/>
            <toolset name="borland-5*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-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-6.5*"/>
            <toolset name="msvc-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="sunpro-5_3-sunos"/>
            <note refid="31" author="Peter Dimov"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="bind_function_test"/>
            <toolset name="sunpro-5_8u1-sunos"/>
            <note author="Peter Dimov">
               This failure is caused by Boost.Function.
            </note>
        </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>
        <mark-expected-failures>
            <test name="bind_rv_sp_test"/>
            <toolset name="tru64cxx*"/>
            <toolset name="hp_cxx-65*"/>
            <toolset name="hp_cxx-71*"/>
            <note author="Markus Schoepflin">
              This failure is caused by a bug in the compiler triggered by the
              use of the debug flag '-gall'. It has been reported to the
              compiler vendor.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="bind_dm3_test"/>
            <toolset name="borland-5*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note refid="31" author="Peter Dimov"/>
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="mem_fn_eq_test"/>
          <toolset name="msvc-7.1"/>
          <note author="Peter Dimov">
            This failure is only present in release mode and is caused by /OPT:ICF.
          </note>
        </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>
        <test name="class_concept_fail_expected">
            <mark-failure>
                <toolset name="borland-5*"/>
                <toolset name="msvc-6.5*"/>
                <toolset name="msvc-7.0"/>
                <note author="Jeremy Siek"/>
            </mark-failure>
        </test>
        <test name="stl_concept_covering">
            <mark-failure>
                <toolset name="*"/>
                <note author="Jeremy Siek" refid="1"/>
            </mark-failure>
        </test>
    </library>

    <!-- config -->
    <library name="config">
        <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="gcc-3_4_4_tru64"/>
                <note author="John Maddock">
                   Long double NaN's are apparently handled incorrectly on this platform.
                </note>
            </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="limits_test">
            <mark-failure>
                <toolset name="borland-5.8*"/>
                <note author="A.Meredith">
                    This failure is due to NaNs trapping.
                </note>
            </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="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="como-4_3_3-vc7_1"/>
            <toolset name="sunpro-5_3-sunos"/>
            <toolset name="msvc-6.5"/>
            <toolset name="msvc-6.5_stlport5"/>
            <toolset name="msvc-6.5_stlport4"/>
            <toolset name="msvc-7.0"/>
            <toolset name="msvc-7.0_stlport5"/>
            <toolset name="iw-7_1-vc6-stlp-4_5_3"/>
            <toolset name="iw-7_1-vc6"/>
            <toolset name="dmc-*"/>
        </mark-unusable>

        <test name="testgreg_serialize*">
            <mark-failure>
            <toolset name="gcc-2.*"/>
            <toolset name="msvc-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="msvc-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-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="msvc-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-6.5*"/>
                <toolset name="msvc-7.0*"/>
                <toolset name="cw-8.3*"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="mingw*"/>
                <toolset name="*mingw*"/>
                <toolset name="*cygwin*"/>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="*como-4_3_3*"/>
                <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="borland-5.8*"/>
            <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-6.5"/>
            <toolset name="msvc-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-6.5"/>
            <toolset name="*como-4_3_3*"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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="testlocal_time_iterator">
            <mark-failure>
            <toolset name="msvc-6.5"/>
            <toolset name="*como-4_3_3*"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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="testlocal_time_period">
            <mark-failure>
            <toolset name="msvc-6.5"/>
            <toolset name="*como-4_3_3*"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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="borland-5.8*"/>
            <toolset name="gcc-2.95.3-linux"/>
            <toolset name="msvc-7.0"/>
            <toolset name="msvc-6.5"/>
                <note author="J. Garland">
                   Some compilers are confused by the template code here.
                   These are new features to date-time in 1.33 and there is no
                   plan to backport to these non-compliant compilers.
                </note>
            </mark-failure>
        </test>

        <test name="testlocal_time_input_facet">
            <mark-failure>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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-6.5"/>
            <toolset name="msvc-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="borland-5.8*"/>
            <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-6.5"/>
            <toolset name="msvc-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="borland-5.8.1"/>
            <toolset name="gcc-2.95.3-linux"/>
            <toolset name="*como-4_3_3*"/>
            <toolset name="msvc-6.5"/>
                <note author="J. Garland">
                   Some older compilers are confused by the template code here.
                   These are new features to date-time in 1.33 and there is no
                   plan to backport to these non-compliant compilers.
                </note>
            </mark-failure>
        </test>

        <test name="testposix_time_zone">
            <mark-failure>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.1"/>
            <toolset name="gcc-2.95.3-linux"/>
            <toolset name="msvc-6.5"/>
                <note author="J. Garland">
                   Some older compilers are confused by the template code here.
                   These are new features to date-time in 1.33 and there is no
                   plan to backport to these non-compliant compilers.
                </note>
            </mark-failure>
        </test>

        <test name="testtz_database">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8.1"/>
                <toolset name="*como-4_3_3*"/>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="msvc-6.5"/>
                <note author="J. Garland">
                   Some compilers are confused by the template code here.
                   These are new features to date-time in 1.33 and there is no
                   plan to backport to these non-compliant compilers.
                </note>
            </mark-failure>
        </test>

        <test name="testtime_wstream">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="mingw*"/>
                <toolset name="*mingw*"/>
                <toolset name="*cygwin*"/>
                <toolset name="*como-4_3_3*"/>
                <toolset name="tru64cxx65-042"/>
                <toolset name="hp_cxx-65*"/>
                <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-6.5"/>
                <toolset name="msvc-7.0"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="mingw*"/>
                <toolset name="*como-4_3_3*"/>
                <toolset name="tru64cxx65-042"/>
                <toolset name="hp_cxx-65*"/>
                <note author="B. Garst" refid="19,21,22"/>
            </mark-failure>
        </test>
        <test name="testdate_facet_new">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="cw-8.3*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="J. Garland">
                These compilers are unfortunately able to correctly compile the
                new format-based input-output code for date time.  Suitable, but 
                less flexible, alternatives are available on these compilers.
               </note>
            </mark-failure>
        </test>
        <test name="testdate_facet_new_dll">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="cw-8.3*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="J. Garland">
                These compilers are unfortunately able to correctly compile the
                new format-based input-output code for date time.  Suitable, but 
                less flexible, alternatives are available on these compilers.
               </note>
            </mark-failure>
        </test>
        <test name="testtime_facet">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="cw-8.3*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="J. Garland">
                These compilers are unfortunately able to correctly compile the
                new format-based input-output code for date time.  Suitable, but 
                less flexible, alternatives are available on these compilers.
               </note>
            </mark-failure>
        </test>

        <test name="testwcustom_time_zone">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.4.2_mingw"/>
                <toolset name="gcc-3.4.5_mingw"/>
                <toolset name="*mingw*"/>
                <toolset name="*cygwin*"/>
                <note author="J. Garland">
                These compilers are unfortunately able to correctly compile the
                new format-based input-output code for date time.  Suitable, but 
                less flexible, alternatives are available on these compilers.
               </note>
            </mark-failure>
        </test>

        <test name="testwposix_time_zone">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.4.2_mingw"/>
                <toolset name="gcc-3.4.5_mingw"/>
                <toolset name="*mingw*"/>
                <toolset name="*cygwin*"/>
                <note author="J. Garland">
                These compilers are unfortunately able to correctly compile the
                new format-based input-output code for date time.  Suitable, but 
                less flexible, alternatives are available on these compilers.
               </note>
            </mark-failure>
        </test>

        <test name="testfacet">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="msvc-6.5"/>
                <toolset name="mingw*"/>
                <toolset name="*mingw*"/>
                <toolset name="*cygwin*"/>
                <toolset name="gcc-3.4.2_mingw"/>
                <toolset name="gcc-3.4.5_mingw"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <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-6.5"/>
                <toolset name="mingw*"/>
                <toolset name="*mingw*"/>
                <toolset name="*cygwin*"/>
                <toolset name="gcc-3.4.2_mingw"/>
                <toolset name="gcc-3.4.5_mingw"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="*como-4_3_3*"/>
                <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-6.5"/>
                <toolset name="msvc-7.0"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <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="testmicrosec_time_clock">
            <mark-failure>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <note author="J. Garland">
               There is apparently a bug in Borland library
               such that  std::local_time and std::gmtime are 
               returning a time that's 1 hour ahead GetSystemTimeAsFileTime 
               during DST.  This is a rather serious problem in that 
               some of the date-time clock interfaces will give the wrong
               current time.
            </note>
            </mark-failure>
        </test>
        <test name="teststreams">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="gcc-3.1-darwin"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="mingw-3*"/>
                <toolset name="gcc-3.4.2_mingw"/>
                <toolset name="gcc-3.4.5_mingw"/>
                <toolset name="*mingw*"/>
                <toolset name="*cygwin*"/>
                <toolset name="mingw"/>
                <toolset name="*como-4_3_3*"/>
                <note author="B. Garst" refid="18,19,20"/>
            </mark-failure>
        </test>
        <test name="testdate_dll">
            <mark-failure>
                <toolset name="*como-4_3_3*"/>
                <note author="J. Garland" date="30 Jan 2004" id="24"/>
            </mark-failure>
        </test>
        <test name="testgreg_day_dll">
            <mark-failure>
                <toolset name="*como-4_3_3*"/>
                <note author="J. Garland" date="30 Jan 2004" id="24"/>
            </mark-failure>
        </test>
        <test name="*_dll">
            <mark-failure>
                <toolset name="*como-4_3_3*"/>
                <note author="J. Garland" date="30 Jan 2004" id="24"/>
            </mark-failure>
        </test>

        <mark-expected-failures>
            <test name="testdate_dll"/>
            <test name="testdate_duration_dll"/>
            <test name="testdate_input_facet_dll"/>
            <test name="testdate_iterator_dll"/>
            <test name="testfacet_dll"/>
            <test name="testformatters_dll"/>
            <test name="testgenerators_dll"/>
            <test name="testgreg_durations_dll"/>
            <test name="testperiod_dll"/>
            <toolset name="cw-8.3*"/>
            <note author="R. Rivera" refid="25"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testdate_facet_new"/>
            <test name="testdate_facet_new_dll"/>
            <test name="testdate_input_facet"/>
            <test name="testdate_input_facet_dll"/>
            <test name="testdate_facet"/>
            <test name="testdate_facet_dll"/>
            <test name="testtime_facet"/>
            <test name="testtime_input_facet"/>
            <toolset name="sun-5.8"/>
            <note author="J. Garland">
               The sun 5.8 compiler and standard library have a problem with 
               the classic facet which causes some of the io tests for date-time
               to fail.  Overall this should not affect most uses of the library.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testdate_input_facet"/>
            <test name="testdate_input_facet_dll"/>
            <toolset name="msvc-7.1_stlport4"/>
            <note author="J. Garland">
               The STLPort standard library has issues with some custom
               facet settings causing an unexplained failure in these
               facet tests.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testdate_facet_new"/>
            <test name="testdate_facet_new_dll"/>
            <test name="testtime_facet"/>
            <toolset name="msvc-8.0_stlport5"/>
            <toolset name="msvc-7.1_stlport4"/>
            <note author="J. Garland">
               The STLPort standard library has issues with the handling
               of the classic facet which causes some fo the i/o tests
               for date-time to fail.  Overall this should not affect 
               most uses of the library.
            </note>
        </mark-expected-failures>


        <mark-expected-failures>
            <test name="testgreg_wstream"/>
            <test name="testtime_facet"/>
            <test name="testtime_input_facet"/>
            <test name="testtime_wstream"/>
            <toolset name="msvc-7.1_stlport4"/>
            <note author="J. Garland">
               MSVC 7.1 with its standard library passes all date-time tests.
               For some reason when paired with stlport a few widestream
               io tests do not format output correctly.   Overall this should 
               not affect most uses of the library.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testlocal_time_input_facet"/>
            <test name="testtime_input_facet"/>
            <toolset name="cw-9.4"/>
            <toolset name="cw-9.5*"/>
            <note author="J. Garland">
                 Although these tests compile, the execution aborts for
                 an unknown reason. Note that sometimes the excution is
                 ok on cw-9_4. This may be fixable if someone
                 can track down the source of the problem.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testlocal_time"/>
            <test name="testlocal_time_input_facet"/>
            <test name="testtime_input_facet"/>
            <toolset name="msvc-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>

        <mark-expected-failures>
            <test name="testtime_serialize*"/>
            <test name="testgreg_serialize*"/>
            <toolset name="vacpp"/>
            <note author="J. Garland">
              These tests are for serialization which has been marked as unusable.
              The issue was specifically noted on 
              AIX version : 5.2.0.41 using IBM XL Version 8.0.0.0.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testfacet"/>
            <test name="testfacet_dll"/>
            <toolset name="tru64cxx*"/>
            <toolset name="hp_cxx*"/>
            <toolset name="acc"/>
            <note author="Markus Schoepflin">
            The failure is caused by a standard library bug. It doesn't
            support user defined facets which are not default
            constructible. This has been reported to the compiler vendor.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testdate_input_facet_dll"/>
            <test name="testdate_input_facet"/>
            <test name="testtime_input_facet"/>
            <test name="testlocal_time_input_facet"/>
            <toolset name="acc"/>
            <note author="Jeff Garland">
            These tests rely on the ability of an std::map to be
            instantiated on an incomplete type. The Rogue Wave
            version 2.2 and higher does not allow this.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testtime_wstream"/>
            <toolset name="hp_cxx-65*"/>
            <note author="Jeff Garland">
            The failure is caused by a standard library bug. It doesn't
            support user defined facets which are not default
            constructible. This has been reported to the compiler vendor.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testgreg_wstream"/>
            <test name="testparse_date"/>
            <test name="teststreams"/>
            <toolset name="tru64cxx*"/>
            <toolset name="hp_cxx*"/>
            <note author="Markus Schoepflin">
            The failure is caused by a standard library bug. The end-of-stream
            istream iterator can only be constructed when the istream iterator
            has been instantiated with char as the character type. This has
            been reported to the compiler vendor.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testfacet"/>
            <test name="testfacet_dll"/>
            <test name="testgreg_wstream"/>
            <test name="teststreams"/>
            <test name="testtime_wstream"/>
            <test name="testwcustom_time_zone"/>
            <test name="testwposix_time_zone"/>
            <toolset name="qcc-3.3.5_gpp"/>
            <note author="Jim Douglas" date="12 Feb 06" refid="36"/>
        </mark-expected-failures>

    </library>


    <!-- dynamic_bitset -->
    <library name="dynamic_bitset">
        <test name="dyn_bitset_unit_tests1">
            <mark-failure>
                <toolset name="msvc-6.5_stlport4"/>
                <note author="Gennaro Prota" refid="37" />
            </mark-failure>
        </test>
        <test name="dyn_bitset_unit_tests2">
            <mark-failure>
                <toolset name="borland-5.8.2"/>
                <note author="Roland Schwarz">
                    The exact reason of this (linker related) bug is unresearched. The test passes
                    on some environments. The test was found to fail on a platform whit a german
                    version of the compiler.
                </note>
            </mark-failure>
        </test>
        <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 standard library bugs this configuration is not supported by
                the most recent version of the library.
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="cw-8.3"/>
            <note author="Beman Dawes">
                Due to standard library bugs, this version is not supported.
                More recent version of the library should work OK.
            </note>
        </mark-unusable>
        <mark-expected-failures>
          <test name="fstream_test"/>
          <toolset name="msvc-6.5*"/>
          <note author="Beman Dawes">
              fstream for this compiler has serious problems and is not supported
          </note>
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="operations_test_dll"/>
          <test name="path_test_dll"/>
          <toolset name="borland-5.6.4"/>
          <toolset name="borland-5.8.2"/>
          <toolset name="gcc-3.4.2_mingw"/>
          <toolset name="gcc-3.4.2_mingw"/>
          <note author="Beman Dawes" refid="35"/> <!-- dll's don't work - use static -->
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="operations_test"/>
          <test name="operations_test_dll"/>
            <toolset name="msvc-6.5*"/>
          <note author="Beman Dawes" refid="31"/> <!-- esoteric features don't work -->
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="mbcopy"/>
          <test name="mbpath"/>
          <test name="wide_test"/>
          <toolset name="gcc-3.4.2_mingw"/>
          <toolset name="gcc-3.4.5_mingw"/>
          <toolset name="gcc-mingw-3.4.5"/>
          <toolset name="gcc-mingw-3.4.2"/>
          <toolset name="gcc-cygwin-3.4.4"/>
          <note author="Beman Dawes" refid="19"/> <!-- no wchar_t, wstring support -->
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="mbcopy"/>
          <test name="mbpath"/>
          <test name="wide_test"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.1"/>
            <toolset name="borland-5.8.2"/>
            <toolset name="cw-8.3"/>
            <toolset name="dmc-8_4_7*"/>
          <note author="Beman Dawes">
              The library does not support wide paths on this compiler because
              it does not support SFINAE.
          </note>
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="mbcopy"/>
          <test name="mbpath"/>
          <test name="wide_test"/>
          <toolset name="qcc-3.3.5_gpp"/>
          <note author="Jim Douglas" refid="36"/>
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="mbcopy"/>
          <test name="wide_test"/>
          <toolset name="sun-5.8"/>
           <note author="John Maddock">
              These failures are reported to be fixed in Sun's 
              next compiler release.
           </note>
        </mark-expected-failures>
      </library>

    <!-- foreach -->
    <library name="foreach">
        <mark-unusable>
            <toolset name="dmc*"/>
            <toolset name="sunpro-5_3-sunos"/>
            <note author="Eric Niebler">
                This compiler does not support the Boost.Range
                library, on which Boost.Foreach depends.
            </note>
        </mark-unusable>

        <mark-expected-failures>
            <test name="rvalue_const"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="gcc-2*"/>
            <toolset name="gcc-3.2*"/>
            <toolset name="gcc-3_3-darwin"/>
            <toolset name="intel-linux"/>
            <toolset name="vacpp"/>
            <toolset name="cw-8.3"/>
            <toolset name="cw-9.4"/>
            <toolset name="cw-9.5-darwin"/>
            <toolset name="sunpro*"/>
            <toolset name="mingw"/>
            <toolset name="tru64cxx*"/>
            <toolset name="hp_cxx*"/>
            <toolset name="intel-win32-8_1"/>
            <toolset name="sun-5.8"/>
            <note author="Eric Niebler">
                This compiler does not support detection of
                const rvalues.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="rvalue_nonconst"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="tru64cxx*"/>
            <toolset name="hp_cxx*"/>
            <toolset name="sunpro*"/>
            <toolset name="sun-5.8"/>
            <note author="Eric Niebler">
                This compiler does not support detection of
                rvalues.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="dependent_type"/>
            <toolset name="gcc-2.95.3*"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <note author="Eric Niebler">
                These compilers cannot handle BOOST_FOREACH
                in a template, where the collection type
                depends on a template parameter.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="user_defined"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0*"/>
            <note author="Eric Niebler">
                This failure is because the Boost.Range extension
                mechanism is broken on these compilers. It requires
                ADL which these compilers do not support.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="noncopyable"/>
            <toolset name="sun-5.8"/>
            <note author="Eric Niebler">
                is_base_and_derived&lt;&gt; is broken on this compiler, but
                the problem can be worked around by specializing
                boost::foreach::is_noncopyable&lt;&gt; for collection
                types that are noncopyable.
            </note>
        </mark-expected-failures>
    </library>

    <!-- format -->
    <library name="format">
        <mark-unusable>
            <toolset name="iw-7_1*"/>
            <note author="Aleksey Gurtovoy">
                The failure is caused by a standard library bug: the
                iostream components fail to handle <code>ios::internal</code>
                flag.
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="sunpro-5_3-sunos"/>
        </mark-unusable>
        <mark-expected-failures>
            <test name="format_test2"/>
            <test name="format_test3"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <toolset name="acc"/>
            <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-6.5*"/>
            <toolset name="msvc-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-6.5*"/>
            <toolset name="msvc-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>

        <mark-expected-failures>
            <test name="hash_float_test"/>
            <toolset name="gcc-cygwin*"/>
            <note author="Daniel James">
                On this platform both std::frexp and std::ldexp treat long
                doubles as longs, so the hashing algorithm does the same.
                This means that you'll get very bad results for long doubles
                that can't be represented by doubles.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="point" />
            <test name="books" />
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0*"/>
            <note author="Daniel James">
                These examples only work on compilers with support for ADL.
                It is possible to work around this, but I wanted to keep the
                example code as clean as possible.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="point" />
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <note author="Daniel James">
                It appears that Borland doesn't find friend functions defined
                in a class by ADL. This is easily fixed but this example is
                meant to show the typical way of customising boost::hash, not
                the portable way.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="hash_global_namespace_test" />
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <note author="Daniel James">
                The test demonstrates a Borland bug - functions that aren't
                in a namespace don't appear to be found by ADL.
            </note>
        </mark-expected-failures>
    </library>

    <!-- graph -->
    <library name="graph">
        <mark-unusable>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="sunpro-5_3-sunos"/>
        </mark-unusable>
        <mark-expected-failures>
            <test name="adj_matrix_cc"/>
            <test name="biconnected_components_test"/>
            <test name="bidir_remove_edge"/>
            <test name="bfs_cc"/>
            <test name="bundled_properties"/>
            <test name="csr_graph_test"/>
            <test name="dfs_cc"/>
            <test name="dijkstra_cc"/>
            <test name="dominator_tree_test"/>
            <test name="floyd_warshall_test"/>
            <test name="gursoy_atun_layout_test"/>
            <test name="graphviz_test"/>
            <test name="matching_test"/>
            <test name="serialize"/>
            <test name="subgraph"/>
            <test name="transitive_closure_test"/>
            <test name="vector_graph_cc"/>
            <toolset name="msvc-7.0"/>
            <note refid="3" author="Doug Gregor"/>
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="graphviz_test"/>
          <toolset name="vc-8_0"/>
          <toolset name="msvc-8_0"/>
          <toolset name="intel-vc71-win-9.1"/>
          <note refid="1" author="Doug Gregor"/>
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="serialize"/>
          <toolset name="sun-5.8"/>
          <note refid="2" author="Doug Gregor"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="betweenness_centrality_test"/>
            <toolset name="iw-7_1-vc6*"/>
            <toolset name="msvc-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.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="csr_graph_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"/>
          <note refid="28" author="Vladimir Prus"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="bundled_properties"/>
            <toolset name="qcc-3.3*"/>
            <note author="Jim Douglas" date="18 Feb 06" refid="27"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="csr_graph_test"/>
            <toolset name="msvc-8.0"/>
            <note author="Doug Gregor">
              This failure is due to a problem with partial ordering
              of class template partial specializations.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="dijkstra_heap_performance"/>
            <test name="layout_test"/>
            <test name="relaxed_heap_test"/>
            <toolset name="msvc-7.0"/>
            <note author="Vladimir Prus">
              The test fails due to compile error in relaxed_heap.hpp. 
              The compile error is likely caused by a compiler bug.      
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="graphviz_test"/>
          <toolset name="msvc-7.1_stlport4"/>
          <note author="Vladimir Prus">
            The test fails from completely unknown reason -- it might
            be compiler bug, or compiler misconfiguration or testing
            system bug.
          </note>
        </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="borland-5.8.2"/>
            <toolset name="iw-7_1-vc6*"/>
            <toolset name="msvc-6.5*"/>
            <note refid="4" author="Aleksey Gurtovoy"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ios_state_test"/>
            <test name="ios_state_unit_test"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <note refid="34" author="Markus Schoepflin"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ios_state_unit_test"/>
            <toolset name="gcc-2.95.3-*"/>
            <note refid="3" author="Doug Gregor"/>
        </mark-expected-failures>
       <mark-expected-failures>
          <test name="ios_state_unit_test"/>
          <toolset name="gcc-4.1.0*"/>
          <note author="John Maddock">
             This is gcc bug 26526, and is fixed in later releases.
          </note>
       </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>
            <!-- STLPort bug -->
            <test name="seekable_file_test"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="iw-7_1-vc6-stlp-4_5_3"/>
            <toolset name="*como-4_3_3*"/>
            <toolset name="*stlport"/>
            <note author="Jonathan Turkanis" refid="4"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <!-- Insufficient wide character support -->
            <test name="code_converter_test"/>
            <test name="wide_stream_test"/>
            <toolset name="gcc-2.95.3-linux"/>
            <!-- Must enumerate MinGW's since some use STLPort -->
            <toolset name="gcc-3.4.2_mingw"/>
            <toolset name="mingw-3_4_4"/>
            <toolset name="gcc-3.4.5_mingw"/>
            <toolset name="gcc-3.4.5_mingw"/>
            <toolset name="*cygwin*"/>
            <toolset name="gcc-3.3.6-osf1"/>
            <note author="Jonathan Turkanis" refid="19"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <!-- Insufficient wide character support -->
            <test name="code_converter_test"/>
            <test name="wide_stream_test"/>
            <toolset name="qcc-3.3.5*gpp"/>
            <note author="Jim Douglas" date="12 Feb 06" refid="36"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="bzip2_test"/>
            <test name="file_descriptor_test"/>
            <test name="mapped_file_test"/>
            <toolset name="*como-4_3_3*"/>
            <note author="Jonathan Turkanis">
                compiler can't compile "windows.h" in strict mode
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="gzip_test"/>
            <test name="zlib_test"/>
            <toolset name="como-4_3_3-vc7_1"/>
            <note author="Jonathan Turkanis">
                The failure reflects a problem with the build system: the zlib 
                object files are generated in the wrong directory.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="stdio_filter_test"/>
            <toolset name="*como-4_3_3*"/>
            <note author="Jonathan Turkanis" refid="0"/>
        </mark-expected-failures>
        <mark-expected-failures reason="?">
            <test name="direct_adapter_test"/>
            <test name="gzip_test"/>
            <toolset name="gcc-2.95.3-linux"/>
            <note author="Jonathan Turkanis" refid="29"/>
        </mark-expected-failures>
        <mark-expected-failures reason="?">
            <test name="file_descriptor_test"/>
            <toolset name="gcc-3_4_4-cygwin"/>
            <note author="Jonathan Turkanis" refid="29"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="finite_state_filter_test"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="gcc-2.95.3*"/>
            <note author="Jonathan Turkanis" refid="2"/>
        </mark-expected-failures>
        <mark-expected-failures>
          <test name="finite_state_filter_test"/>
          <toolset name="cw-9.4"/>
          <note author="Jonathan Turkanis" date="20 Dec 06">
            I'm not sure whether CodeWarrior is correct to report that the member 
            in question is inaccessible; however, when the member is made public
            an internal error occur that I have not been able to fix, so for
            now the question is moot.
          </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="mapped_file_test"/>
            <toolset name="qcc-3.3*"/>
            <note author="Jim Douglas" date="19 Feb 06">
                Memory mapped files are not supported in QNX Neutrino version 6.3.0.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="compose_test"/>
            <toolset name="borland-5.6.4"/>
            <note author="Jonathan Turkanis">
				Fails to compile on some installations but not others; may 
            	depend on which compiler updates have been installed
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="compose_test"/>
            <toolset name="msvc-6.5_stlport4"/>
            <note author="Jonathan Turkanis">
				These six tests pass individually but cause a compiler stack overflow
            	when compiled as a group
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="bzip2_test"/>
            <toolset name="gcc-3.4.3_sunos"/>
            <note author="Caleb Epstein">
                No bzip2 support on the testing machine and no way to
                disable this test with BBv2 at present.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="file_descriptor_test"/>
            <toolset name="gcc-cygwin-3.4.4"/>
            <note author="Vladimir Prus">
              The test fails at runtime for unknown reasons.
            </note>
        </mark-expected-failures>

    </library>

    <!-- lambda -->
    <library name="lambda">
        <mark-unusable>
            <toolset name="msvc-6.5*"/>
            <toolset name="borland-5.5.1"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="sunpro-5_3-sunos"/>
            <note refid="17">
            </note>
        </mark-unusable>
        <mark-expected-failures>
            <test name="bll_and_function"/>
            <toolset name="msvc-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-6.5_stlport4"/>
          <toolset name="gcc-2.95.3-linux"/>
          <toolset name="sunpro-5_3-sunos"/>
          <toolset name="tru64cxx65*"/>
          <toolset name="hp_cxx-65*"/>
          <note author="Douglas Gregor" refid="4"/>
        </mark-failure>
      </test>
    </library>


    <!-- MPL -->
    <library name="mpl">

        <mark-unusable>
            <toolset name="sunpro-5_3-sunos"/>
            <note author="Aleksey Gurtovoy" date="10 Jul 2005">
                The compiler is not supported by the library due to an
                utterly broken templates support.
            </note>
        </mark-unusable>

        <mark-expected-failures>
            <test name="as_sequence"/>
            <test name="is_sequence"/>
            <test name="has_xxx"/>
            <test name="no_has_xxx"/>
            <test name="single_view"/>
            <toolset name="cw-8.3*"/>
            <note author="Aleksey Gurtovoy" date="17 Sep 2004">
                This failure is caused by a deficient SFINAE implementation; the bug
                was fixed in the next major compiler version (CodeWarrior 9.x).
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="is_sequence"/>
            <test name="as_sequence"/>
            <test name="has_xxx"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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="arithmetic"/>
            <test name="at"/>
            <test name="back"/>
            <test name="bitwise"/>
            <test name="contains"/>
            <test name="copy"/>
            <test name="count"/>
            <test name="count_if"/>
            <test name="deque"/>
            <test name="distance"/>
            <test name="find_if"/>
            <test name="for_each"/>
            <test name="front"/>
            <test name="insert"/>
            <test name="insert_range"/>
            <test name="joint_view"/>
            <test name="numeric_ops"/>
            <test name="pair_view"/>
            <test name="partition"/>
            <test name="range_c"/>
            <test name="remove"/>
            <test name="reverse"/>
            <test name="sort"/>
            <test name="stable_partition"/>
            <test name="transform"/>
            <test name="unpack_args"/>
            <test name="vector"/>
            <test name="vector_c"/>

            <toolset name="borland-5.8.1"/>

            <note author="A. Meredith" date="17 May 2006">
                This failure is caused by a problem with recursive templates and default template parameters, fixed in Update 2.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="apply"/>
            <test name="multiset"/>
            <test name="zip_view"/>

            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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="borland-5.8*"/>
            <toolset name="msvc-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="borland-5.8*"/>
            <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-6.5*"/>
            <toolset name="msvc-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>

        <mark-expected-failures>
            <test name="apply"/>
            <toolset name="gcc-4.1.0*"/>
            <toolset name="gcc-4.1.1*"/>
            <note author="Caleb Epstein">
              This is a regression in the gcc 4.1 series that will be
              fixed in gcc 4.1.2.  See <a
              href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088">bug
              #28088</a> for details.
            </note>
        </mark-expected-failures>
       <mark-expected-failures>
          <test name="vector_c"/>
          <toolset name="sun-5.8"/>
          <note author="John Maddock">
             This is reported to be fixed in the next Sun
             compiler release.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
            <test name="copy"/>
            <toolset name="acc"/>
            <note author="Boris Gubenko">
                When compiling this test, aCC6 runs out of memory. The HP
                compiler group is aware of this issue and is working on the fix.
            </note>
       </mark-expected-failures>

    </library>

    <!-- multi_array -->
    <library name="multi_array">
        <mark-unusable>
            <toolset name="borland-5.5.1"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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>
        <!-- RG: testing usability <mark-unusable>
            <toolset name="gcc-2.95.3*"/>
            <toolset name="gcc-2.95.3-linux"/>
            <toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
            <note author="Ronald Garcia" date="08 Jan 2006">
                <p>
          These compiler/standard library combinations don't
          support enable_if. 
                </p>
            </note>
        </mark-unusable> -->
        <test name="constructors">
            <mark-failure>
               <toolset name="msvc-6.5"/>
               <note author="Ronald Garcia" date="13 Jul 2004">
                  Known error in MSVC. see
<a href="http://boost-consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_60">
http://boost-consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_60</a>
for more information.
               </note>
            </mark-failure>
        </test>
        <mark-expected-failures>
            <test name="assign_to_array"/>
            <toolset name="gcc-2.95.3*"/>
            <note author="Aleksey Gurtovoy" date="21 Sep 2004" refid="2"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="assign"/>
            <test name="compare"/>
            <test name="concept_checks"/>
            <test name="constructors"/>
            <test name="iterators"/>
            <test name="resize"/>
            <test name="stl_interaction"/>
            <toolset name="gcc-2.95.3*"/>
            <note author="Doug Gregor" date="23 Jun 2005" refid="3"/>
        </mark-expected-failures>
    </library>


    <!-- multi_index -->
    <library name="multi_index">
        <mark-unusable>
            <toolset name="borland-5.6.4"/>
            <note author="J. L&#243;pez" date="05 Jul 2004" refid="17"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="borland-5.8*"/>
            <note author="Alisdair Meredith" date="26 May 2006"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="gcc-2.95.3-linux"/>
            <toolset name="gcc-2.95.3-stlport-4.5.3-linux"/>
            <toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
            <note author="J. L&#243;pez" date="09 Jul 2004" refid="17"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="*como-4_3_3-msvc"/>
            <note author="J. L&#243;pez" date="30 Jul 2004">
                The VC++ 6.0 backend runs out of internal resources while
                trying to process the Comeau output for this library;
                Comeau Computing has been asked about a solution.
                On the other hand, Comeau 4.3.3 with VC++ 7.0 backend works
                fine.
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="sunpro-5_3-sunos"/>
            <toolset name="sunpro-5_8u1-sunos"/>
            <note author="J. L&#243;pez" date="22 Apr 2005" refid="17"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="dmc-8_43-stlport-4_5_3"/>
            <toolset name="dmc-8_44b-stlport-4_5_3"/>
            <toolset name="dmc-8_47-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="msvc-6.5_stlport4"/>
            <note author="J. L&#243;pez" date="10 Jan 2005">
              This error shows when using the dynamic version of the STLport
              library. The problem is reportedly fixed in STLport 5.0 (in beta
              stage as of this writing.)
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="test_serialization"/>
            <toolset name="vacpp"/>
            <note author="J. L&#243;pez" date="07 Jul 2005">
              Boost.Serialization is not supported on this platform.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="test_serialization"/>
            <toolset name="tru64cxx71-006"/>
            <toolset name="hp_cxx-65*"/>
            <toolset name="hp_cxx-71*"/>
            <note author="J. L&#243;pez" date="16 Mar 2006">
              This test fails due to limitations of the template
              instantiation model used in the testing environment
              (-timplicit_local) resulting in erroneous duplication of some
              function-static variables. The test passes with other template
              instantiation models.
            </note>
        </mark-expected-failures>
    </library>


    <!-- optional -->
    <library name="optional">
        <mark-expected-failures>
            <test name="optional_test"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note author="Fernando Cacciola" refid="6"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="optional_test_ref"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-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"/>
            <toolset name="borland-5.8*"/>
            <note author="Fernando Cacciola" refid="2"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="optional_test_fail3a"/>
            <toolset name="gcc-3_3-darwin"/>
            <note author="Fernando Cacciola" refid="2"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="optional_test_inplace_fail2"/>
            <toolset name="gcc-3_3-darwin"/>
            <note author="Fernando Cacciola" refid="2"/>
        </mark-expected-failures>
    </library>

    <library name="pool">
      <mark-unusable>
        <toolset name="gcc-2.95.3-*"/>
        <note author="Doug Gregor" refid="2"/>
      </mark-unusable>
    </library>

    <!-- preprocessor -->
    <library name="preprocessor">
        <mark-expected-failures>
            <test name="seq"/>
            <toolset name="cw-8.3"/>
            <note author="Paul Mensonides" refid="2"/>
        </mark-expected-failures>
    </library>

    <!-- rational -->
    <library name="rational">
        <mark-expected-failures>
            <test name="rational_test"/>
            <toolset name="sun-5.8"/>
            <note author="J. L&#243;pez" date="19 Oct 2006">
              The test is exposing the following known error of Sun Studio 11:
              overload resolution fails if
              a) some class has a conversion operator to a reference to
              a built-in type, and
              b) overload resolution involves a user-defined operator as well
              as a built-in operator, and
              c) the built-in operator takes the result of the conversion
              mentioned in a) as an operand.
              A fix will be reportedly included in patch no 6 of Sun Studio 11.
            </note>
        </mark-expected-failures>
    </library>

    <!-- serialization -->
    <library name="serialization">
        <mark-unusable>
            <toolset name="vacpp*" />
            <toolset name="mipspro*" />
            <toolset name="dmc*" />
            <toolset name="sunpro*" />
            <note author="Robert Ramey" date="13 Jul 2004" refid="9,17,18"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="gcc-2.95.3-linux"/>
            <note author="Robert Ramey" date="12 Feb 05" refid="18,19"/>
        </mark-unusable>

        <mark-expected-failures>
            <test name="*_warchive"/>
            <test name="*_warchive_dll"/>
            <test name="test_codecvt_null"/>
            <test name="test_utf8_codecvt"/>
            <toolset name="mingw*"/>
            <toolset name="*mingw*"/>
            <toolset name="*cygwin*"/>
            <toolset name="gcc-2.95.3-linux"/>
            <note author="Robert Ramey,Roland Schwarz" date="16 Feb 07" refid="19"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_void_cast*"/>
            <toolset name="msvc-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_reset_object_address*"/>
             <toolset name="msvc-6.5*"/>
             <note author="Robert Ramey" date="12 Feb 05" refid="6,29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_reset_object_address*"/>
            <toolset name="msvc-7.0"/>
            <note author="J. L&#243;pez" date="20 Dec 2006">
              This error shows when the code has become too complex for the
              compiler to handle. The problem has no relationship with the
              functionality being tested, which in fact does work for
              MSVC++ 7.0.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_demo"/>
            <test name="test_demo_dll"/>
            <test name="test_demo_exception"/>
            <test name="test_demo_exception_dll"/>
            <test name="test_demo_shared_ptr"/>
            <test name="test_demo_shared_ptr_dll"/>
            <test name="test_demo_xml_save"/>
            <test name="test_demo_xml_load"/>
            <test name="test_demo_xml_save_dll"/>
            <test name="test_demo_xml_load_dll"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note author="Robert Ramey" refid="6"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_demo_fast_archive"/>
            <test name="test_demo_fast_archive_dll"/>
            <toolset name="msvc-6.5*"/>
            <note author="Robert Ramey" refid="6"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_const"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note author="Aleksey Gurtovoy" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_demo_pimpl"/>
            <test name="test_demo_pimpl_dll"/>
            <test name="test_diamond*"/>
            <test name="test_mult_archive_types"/>
            <test name="test_mult_archive_types_dll"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-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-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="msvc-6.5_stlport4"/>
            <note author="Robert Ramey">
                This failure appears when STLPort is built and used as a DLL with msvc 6.
                STLPort suggests that the next version of STLPort(5.0) will include a workaround
                for this problem.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="*"/>
            <toolset name="gcc-2.95.3-stlport*"/>
            <note author="Aleksey Gurtovoy">
                The library is believed to work in this configuration <i>if compiled against
                Spirit 1.6</i>. The latter is not provided by the particular testing
                environment these tests have been run in.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_demo"/>
            <test name="test_demo_dll"/>
            <test name="test_demo_exception*"/>
            <test name="test_demo_shared_ptr*"/>
            <test name="test_demo_xml*"/>
            <test name="test_exported*"/>
            <test name="test_mi*"/>
            <test name="test_mult_archive_types*"/>
            <test name="test_no_rtti*"/>
            <test name="test_non_default_ctor2*"/>
            <test name="test_registered*"/>
            <test name="test_shared_ptr*"/>
            <test name="test_unregistered*"/>
            <toolset name="cw*"/>
            <note author="Robert Ramey" refid="29">
                All tests that serialize derived pointers currently fail with Metrowerks compilers.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_no_rtti_*"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <note author="Aleksey Gurtovoy" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_smart_cast"/>
            <toolset name="intel-7.1-linux"/>
            <note author="Aleksey Gurtovoy" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="*_dll"/>
            <toolset name="cw*"/>
            <note author="Doug Gregor" refid="35"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_demo_fast_archive"/>
            <toolset name="cw-8*"/>
            <note author="Rene Rivera">
                This is caused by a compiler bug in this particular version, but not present
                in version thereafter. The compiler has some difficulties resolving operators
                to methods in the archive classes. This can be worked around by calling the
                operator directly, and such a work around is already present in library code.
                This test demonstrates that this can happen in user code.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_diamond*"/>
            <toolset name="cw-8*"/>
            <toolset name="cw-9.5-darwin"/>
            <note author="Rene Rivera">
                The CW compilers have problems with the static construction idiom used to
                implement the type registration in the Boost.Serialization library. In many
                cases CW specific work arounds are implemented in the library but this one
                is not immediately solvable. There is a user work around possible, please
                contact the library developers on the Boost list for information on the
                work around if needed.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_class_info_load_text*"/>
            <test name="test_class_info_load_xml_warchive*"/>
            <toolset name="cw-9.5-darwin"/>
            <note author="Rene Rivera" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_class_info_load_text_warchive_dll"/>
            <toolset name="msvc-6.5"/>
            <note author="Doug Gregor" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_const_load_fail1"/>
            <test name="test_const_load_fail1_nvp"/>
            <test name="test_const_load_fail2"/>
            <test name="test_const_load_fail2_nvp"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <note author="Doug Gregor" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_const_save_fail1"/>
            <test name="test_const_save_fail2"/>
            <test name="test_const_save_fail3"/>
            <toolset name="msvc-6.5"/>
            <toolset name="msvc-6.5_stlport4"/>
            <toolset name="msvc-7.0"/>
            <note author="Doug Gregor" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_map_binary_archive_dll"/>
            <test name="test_map_text_archive_dll"/>
            <test name="test_map_text_warchive_dll"/>
            <toolset name="msvc-6.5"/>
            <toolset name="msvc-7.0"/>
            <note author="Doug Gregor" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_variant_*"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <note author="Markus Schoepflin">
                The variant library is not supported for this compiler version.
                Therefore serialization of variants doesn't work.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="*_warchive"/>
            <test name="*_warchive_dll"/>
            <toolset name="qcc-3.3.5*gpp"/>
            <note author="Jim Douglas" date="12 Feb 06" refid="36"/>
        </mark-expected-failures>
	
	<mark-expected-failures>
            <test name="test_variant_*"/>
            <toolset name="borland-5.8.2*"/>
            <note author="Vladimir Prus">
                The compiler fails with an error supposedly related to std::fpos&lt;&gt;::_Stz from the
		&lt;iosfwd&gt; header. It is not known what causes the compiler to instantiate this
		field and what causes the instantiation to fail.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_demo_shared_ptr_dll"/>
            <toolset name="qcc-3.3.5_gpp"/>
            <note author="J. L&#243;pez" date="21 Dec 2006">
              This failure is caused by an unresearched compiler bug; the
              conditions under which the bug manifests itself seem to be
              uncommon, however, and the static version of this same test
              builds and runs correctly.
            </note>
        </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>
        <mark-expected-failures>
            <test name="weak_ptr_test"/>
            <toolset name="tru64cxx71-006"/>
            <toolset name="hp_cxx-71_006_*"/>
            <note author="Markus Schoepflin" refid="3"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="auto_ptr_rv_test"/>
            <toolset name="gcc-2.9*"/>
            <toolset name="borland-5*"/>
            <toolset name="cw-8*"/>
            <note refid="31" author="Peter Dimov"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="pointer_to_other_test"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note refid="31" author="Peter Dimov"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="shared_ptr_alloc2_test"/>
            <toolset name="msvc-6.5*"/>
            <note refid="31" author="Peter Dimov"/>
        </mark-expected-failures>
    </library>

    <!-- spirit -->
    <library name="spirit">
        <mark-unusable>
            <toolset name="msvc-6.5*"/>
            <toolset name="borland-5.5.1"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="msvc-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>

    <!-- typeof -->
    <library name="typeof">
        <mark-unusable>
            <toolset name="borland*"/>
            <toolset name="gcc-2.95.*"/>
            <toolset name="sunpro*"/>
            <note author="Arkadiy Vertleyb">
                This compiler is not supported.
            </note>
        </mark-unusable>
        <mark-expected-failures>
            <test name="*_native"/>
            <toolset name="acc"/>
            <toolset name="vc-8_0*"/>
            <toolset name="msvc-8.0*"/>
            <toolset name="intel-vc71-win*"/>
            <toolset name="intel-vc8-win*"/>
            <toolset name="como-4_3_3-vc7_1"/>
            <toolset name="tru64*"/>
            <toolset name="hp_cxx*"/>
            <toolset name="sun-5.8"/>
            <toolset name="dmc*"/>
            <note author="Arkadiy Vertleyb">
                Native mode is not supported for this compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="*_emulation"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="cw-8_*"/>
            <note author="Arkadiy Vertleyb">
                Emulation mode is not supported for this compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="function_native"/>
            <test name="template_tpl_native"/>
            <test name="function_binding_native"/>
            <test name="odr_no_uns"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note author="Arkadiy Vertleyb">
                The feature is not supported by this compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="function_native"/>
            <toolset name="cw-8_*"/>
            <note author="Arkadiy Vertleyb">
                The feature is not supported by this compiler.
            </note>
        </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-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="B. Dawes" refid="5"/>
            </mark-failure>
        </test>
        <test name="contains_test">
            <mark-failure>
                <toolset name="msvc-6.5*"/>
                <note refid="3" author="D. Gregor"/>
            </mark-failure>
        </test>
        <test name="function_30">
            <mark-failure>
                <toolset name="vacpp"/>
                <note refid="16" author="D. Gregor"/>
            </mark-failure>
        </test>
        <test name="function_arith_cxx98">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
        <test name="function_ref_cxx98">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
        <test name="lambda_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-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-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-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-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-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-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
        <test name="std_bind_portable">
            <mark-failure>
                <toolset name="msvc-6.5"/>
                <note author="B. Dawes" refid="5"/>
            </mark-failure>
        </test>
        <test name="sum_avg_cxx98">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
    </library>


    <!-- iterator -->
    <library name="iterator">
        <test name="interoperable_fail" category="Corner-case tests">
            <mark-failure>
                <toolset name="gcc-3.3*"/>
                <toolset name="gcc-3.2*"/>
                <toolset name="gcc-2*"/>
                <toolset name="gcc"/>
                <toolset name="mingw"/>
                <toolset name="borland*"/>
                <toolset name="cw-8*"/>
                <toolset name="qcc-3.3*"/>
                <note author="D. Abrahams">
                    This failure is caused by a compiler bug.  Templated operators
                    that combine different iterators built with iterator_facade or
                    iterator_adaptor may be present in an overload set even when those
                    iterators are not interoperable.  The usual result is that error
                    messages generated by illegal use of these operators will be of
                    lower quality.
                </note>
            </mark-failure>
        </test>

        <test name="is_convertible_fail" category="Corner-case tests">
            <mark-failure>
                <toolset name="gcc-2*"/>
                <toolset name="gcc"/>
                <toolset name="mingw"/>
                <toolset name="borland*"/>
                <toolset name="cw-8*"/>
                <toolset name="msvc-6*"/>
                <toolset name="msvc-7.0*"/>
                <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-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <note author="Aleksey Gurtovoy" date="19 Sep 2004" refid="26"/>
        </mark-expected-failures>

       <mark-expected-failures>
            <test name="zip_iterator_test"/>
            <toolset name="msvc-6.5_stlport4"/>
            <note author="Thomas Witt">
                This test fails with a link error that is most likely
                a STLport issue. As STLport 4 is officially unsupported
                there is no known resolution.
            </note>
       </mark-expected-failures>

       <mark-expected-failures>
            <test name="is_lvalue_iterator"/>
            <toolset name="acc"/>
            <note author="Boris Gubenko">
                For some currently unknown reason, with aCC6, this test can be compiled
                only in strict ansi mode. Since on HP-UX/aCC6 boost testing is done in the
                default compilation mode, this test fails to compile on this platform.
            </note>
       </mark-expected-failures>

    </library>


    <!-- math -->
    <library name="math">
        <mark-unusable>
          <toolset name="gcc-2.95.3-*"/>
          <note author="Doug Gregor" refid="3"/>
        </mark-unusable>
        <mark-unusable>
          <toolset name="borland-5.6.4"/>
          <note author="A.Meredith"/>
        </mark-unusable>
        <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>
        <mark-expected-failures>
            <test name="complex_test"/>
            <test name="log1p_expm1_test"/>
            <toolset name="sunpro*"/>
            <note author="John Maddock">
              std::numeric_limits&gt;long double&lt;::infinity() is apparently
              broken in this compiler: it's filed as bug 6347520 with Sun.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="complex_test"/>
            <test name="hypot_test"/>
            <toolset name="borland-5.8.2"/>
            <note author="A.Meredith">
              Not yet diagnosed the precise reason these tests give bad results.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="log1p_expm1_test"/>
            <toolset name="borland-5.8.2"/>
            <note author="A.Meredith">
              std::numeric_limits&gt;long double&lt;::infinity() is apparently
              broken in this compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="complex_test"/>
            <toolset name="msvc-6*"/>
            <note author="John Maddock">
              Incomplete std::complex support make these tests pointless
              (the complex trig functions are absent).
            </note>
        </mark-expected-failures>
       <mark-expected-failures>
          <test name="special_functions_test"/>
          <test name="octonion_test"/>
          <test name="quaternion_test"/>
          <test name="quaternion_mult_incl_test"/>
          <toolset name="sun-5.8"/>
          <note author="John Maddock">
             These have yet to fully investigated, but the code is known
             to compile with more conforming compilers, probably workarounds
             are possible if someone is prepared to invest the time.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
          <test name="special_functions_test"/>
          <test name="octonion_test"/>
          <test name="quaternion_test"/>
          <test name="quaternion_mult_incl_test"/>
          <toolset name="msvc-6*"/>
          <note author="John Maddock">
             This compiler is not sufficiently conforming to compile these tests.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
          <test name="quaternion_test"/>
          <toolset name="msvc-7.1_stlport4"/>
          <note author="John Maddock">
             Appears to be a bug in STLport's complex abs function, but needs more investigation.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
          <test name="special_functions_test"/>
          <toolset name="msvc-7.1_stlport4"/>
          <note author="John Maddock">
             This appears to be a problem with STLPort's abs function: the issue only effects the
             test code.  A workaround should be possible but users should be encouraged to use
             STLport 5 instead.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
          <test name="quaternion_test"/>
          <test name="octonion_test"/>
          <toolset name="gcc-cygwin*"/>
          <note author="John Maddock">
            No true long double standard lib support causes these tests to fail.
          </note>
       </mark-expected-failures>

       <mark-expected-failures>
          <test name="quaternion_test"/>
          <test name="complex_test"/>
          <test name="special_functions_test"/>
          <toolset name="intel-linux*"/>
          <note author="John Maddock">
            This is Intel issue 409291, it should be fixed from
            compiler package l_cc_c_9.1.046 onwards.
          </note>
       </mark-expected-failures>

       <mark-expected-failures>
            <test name="complex_test"/>
            <toolset name="qcc-3.3.5*cpp"/>
            <note author="Jim Douglas" date="14 Feb 06" refid="27"/>
       </mark-expected-failures>

       <mark-expected-failures>
            <test name="common_factor_test"/>
            <toolset name="msvc-6.5_stlport*"/>
            <toolset name="msvc-7.1_stlport*"/>
            <note author="John Maddock">
            This failure appears to be caused by a compiler bug: please note
            that the issue only effects the test suite, not the library itself.
            A workaround is available but breaks other compilers.
            </note>
       </mark-expected-failures>
    </library>

    <!-- numeric/conversion -->
    <library name="numeric/conversion">
        <test name="bounds_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8.2"/>
                <note author="Fernando Cacciola" refid="3"/>
            </mark-failure>
        </test>
        <test name="converter_test">
            <mark-failure>
                <toolset name="gcc-3.4.5_linux_x86_64"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8.2"/>
                <note author="Fernando Cacciola" refid="3"/>
            </mark-failure>
        </test>
        <test name="traits_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8.2"/>
                <note author="Fernando Cacciola" refid="3"/>
            </mark-failure>
        </test>
        <test name="udt_example_0">
            <mark-failure>
                <toolset name="acc"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8.2"/>
                <toolset name="msvc-6.5*"/>
                <note author="Fernando Cacciola" refid="30"/>
            </mark-failure>
        </test>
        <test name="udt_support_test">
            <mark-failure>
                <toolset name="gcc-2.95.3-stlport-4.6.2-linux"/>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8.2"/>
                <note author="Fernando Cacciola" refid="3"/>
            </mark-failure>
        </test>
    </library>

    <!-- numeric/interval -->
    <library name="numeric/interval">
        <mark-unusable>
            <toolset name="borland-5.6.4"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
        </mark-unusable>
        <mark-expected-failures>
            <test name="det"/>
            <test name="mul"/>
            <test name="overflow"/>
            <toolset name="tru64cxx*"/>
            <toolset name="hp_cxx*"/>
            <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-expected-failures>
        <mark-expected-failures>
            <test name="det"/>
            <test name="integer"/>
            <test name="overflow"/>
            <toolset name="borland-5.8.2"/>
            <note author="A.Meredith">
                This compiler has some problems with name looup / overload resolution.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="cmp_exn"/>
            <test name="cmp_set"/>
            <test name="cmp_tribool"/>
            <toolset name="gcc-2.95.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>
        <mark-expected-failures>
            <test name="test_float"/>
            <toolset name="msvc-7.1_stlport4"/>
            <note author="Vladimir Prus">
              This failure is unresearched. Presumably, the problem
              is that the abs function is not available in the "right"
              namespace with this compiler/stdlib combination.
            </note>
        </mark-expected-failures>

    </library>


    <!-- numeric/ublas -->
    <library name="numeric/ublas">
        <mark-unusable>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="gcc-3_3-darwin"/>
            <note author="M.Stevens" refid="17"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="cw-9.4"/>
            <note author="M.Stevens" refid="2"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="sun-5.8"/>
            <note author="M.Stevens" refid="4"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="cw-8.3"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="iw-7_1-vc6"/>
            <toolset name="gcc-2.95*"/>
            <note author="M.Stevens" refid="30"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="msvc-7.1_stlport4"/>
            <note author="Roland Schwarz">
                This old version of the stlport library causes the BOOST_NO_STDC_NAMESPACE 
                macro to be set. But this conflicts with the requirements of the library.
            </note>
        </mark-unusable>
        <mark-expected-failures>
            <test name="test3"/>
            <toolset name="qcc-3.3.5*cpp"/>
            <note author="Jim Douglas" date="14 Feb 06" refid="27"/>
       </mark-expected-failures>
    </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-6.5*"/>
            <note refid="17"/>
        </mark-unusable>

        <mark-unusable>
            <toolset name="msvc-7.0"/>
            <note refid="29"/>
        </mark-unusable>

        <!-- Mark expected failures -->

        <test name="unicode_test*">
            <mark-failure>
                <toolset name="iw-7_1-vc6"/>
                <toolset name="iw-7_1-vc6-stlp-4_5_3"/>
                <toolset name="msvc-6.5*"/>
                <note>The failures are caused by problems
                    with std::locale implementation</note>
            </mark-failure>
        </test>

        <test name="options_description_test_dll">
             <mark-failure>
                <toolset name="msvc-6.5"/>
                <toolset name="iw-7_1-vc6"/>
                <note refid="23"/>
            </mark-failure>
        </test>

        <test name="variable_map_test_dll">
             <mark-failure>
                <toolset name="iw-7_1-vc6"/>
                <note refid="23"/>
            </mark-failure>
        </test>

        <test name="*dll">
            <mark-failure>
                <toolset name="cw-8.3*"/>
                <note refid="18"/>
            </mark-failure>
        </test>

        <test name="*dll">
             <mark-failure>
                <toolset name="*como-4_3_3*"/>
                <note refid="24"/>
            </mark-failure>
        </test>

        <mark-expected-failures>
            <test name="variable_map_test"/>
            <test name="variable_map_test_dll"/>
            <toolset name="msvc-6.5*"/>
            <note>
               The failures are caused by compiler bug: it's not possible to
               explicitly pass template arguments to member template function. The
               failure is serious and makes one of the primary interfaces
               unusable.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="cmdline_test_dll"/>
            <test name="options_description_test_dll"/>
            <test name="parsers_test_dll"/>
            <test name="variable_map_test_dll"/>
            <test name="positional_options_test_dll"/>
            <toolset name="mingw-3*"/>
            <note author="Aleksey Gurtovoy" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="unicode_test*"/>
            <toolset name="mingw-3*"/>
            <toolset name="gcc-3.4.2_mingw"/>
            <toolset name="gcc-3.4.5_mingw"/>
            <toolset name="gcc-mingw-3.4.5"/>
            <toolset name="gcc-mingw-3.4.2"/>
            <toolset name="gcc-cygwin-3.4.4"/>
            <note refid="19"/>
        </mark-expected-failures>
        
        <mark-expected-failures>
          <test name="unicode_test_dll"/>
          <toolset name="*-darwin"/>
          <note refid="35" author="Doug Gregor"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="unicode_test*"/>
            <toolset name="qcc-3.3.5*gpp"/>
            <note author="Jim Douglas" date="12 Feb 06" refid="36"/>
        </mark-expected-failures>

    </library>

    <!-- parameter -->
    <library name="parameter">
        <mark-expected-failures>
            <test name="duplicates"/>
            <toolset name="borland-5.6*"/>
            <toolset name="borland-5.8*"/>
            <note refid="32" author="David Abrahams"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="unnamed_fail"/>
            <toolset name="msvc-7.0"/>
            <toolset name="msvc-6*"/>
            <note refid="32" author="David Abrahams"/>
        </mark-expected-failures>
        <test name="preprocessor">
          <toolset name="[Ss]un-5.8"/>
            <note>
              Several compiler bugs were worked around in order to get
              this test to pass, so it could be considered to be only
              partially working.  However, the library's macro system,
              which is really being tested here, does work on this
              compiler, which is why we worked around the failures.
              Please see the <a
              href="http://www.boost.org/libs/parameter/test/preprocessor.cpp">test's
              source file</a> for details.
            </note>
        </test>

        <mark-expected-failures>
            <test name="maybe"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <toolset name="msvc-6*"/>
            <toolset name="msvc-7.0"/>
            <note refid="31" author="Daniel Wallin"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="python-parameter-test"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <toolset name="msvc-6*"/>
            <toolset name="msvc-7.0"/>
            <note refid="31" author="Daniel Wallin"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="python_test"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <toolset name="msvc-6*"/>
            <toolset name="msvc-7.0"/>
            <note refid="31" author="Daniel Wallin"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="optional_deduced_sfinae"/>
            <toolset name="msvc-6*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <note author="Daniel Wallin">
              These compilers do not support SFINAE, so are expected to
              fail this test.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="preprocessor_deduced"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <note author="Daniel Wallin">
              Borland does not support this feature. A compatibility syntax
              might be developed later on.
            </note>
        </mark-expected-failures>       

        <mark-expected-failures>
            <test name="normalized_argument_types"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <toolset name="msvc-6*"/>
            <toolset name="msvc-7.0"/>
            <note author="Daniel Wallin">
              This feature generally requires advanced compiler
              features not supported by these compilers. It might
              be possible to work around the issue on VC6/7, but
              at this time no such workaround has been done.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="unnamed"/>
            <toolset name="*"/>
            <note author="Daniel Wallin">
              This is old and should not be tested any more.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="deduced_dependent_predicate"/>
            <toolset name="msvc-6*"/>
            <note refid="31" author="Daniel Wallin"/>
        </mark-expected-failures>
       <mark-expected-failures>
          <test name="optional_deduced_sfinae"/>
          <test name="preprocessor_deduced"/>
          <test name="python_test"/>
          <toolset name="sun-5.8"/>
          <note author="John Maddock">
             These test failure are reported to be under investigation
             at Sun's compiler labs.
          </note>
       </mark-expected-failures>

        <mark-expected-failures>
            <test name="result_of"/>
            <toolset name="msvc-6*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8.2"/>
            <note refid="31" author="Daniel Wallin"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="python_test"/>
            <toolset name="qcc-3.3.5_gpp"/>
            <note refid="6" author="Daniel Wallin"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="sfinae"/>
            <toolset name="borland-5.8.2"/>
            <toolset name="msvc-6.5_stlport4"/>
            <note refid="29" author="Daniel Wallin"/>
        </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*"/>
            <toolset name="hp_cxx-65*"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="dmc-8_47-stlport-4_5_3"/>
            <toolset name="hp_cxx-65_042_tru64"/>
        </mark-unusable>
        <mark-expected-failures>
            <test name="ptr_list"/>
            <toolset name="gcc-4.0.*"/>
            <note author="Thorsten Ottosen">
                The error is due to problems in the standard library implementation.
                It should be fixed in newer versions of the compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ptr_list"/>
            <toolset name="gcc-4.0.0*"/>
            <note author="Thorsten Ottosen">
                The error is due to problems in the standard library implementation.
                It should be fixed in newer versions of the compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="incomplete_type_test"/>
            <toolset name="cw-9.4"/>
            <note author="Thorsten Ottosen">
                This error seems to be a bug the compiler. Please submit a 
                patch.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="iterator_test"/>
            <toolset name="gcc-3.2.3*"/>
            <toolset name="gcc-3.3.6*"/>
            <toolset name="gcc"/>
            <toolset name="qcc-3.3.5*"/>  
            <note author="Thorsten Ottosen">
                This error seems to be a bug the standard library. Please submit a 
                patch.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="no_exceptions"/>
            <toolset name="cw-9.4"/>
            <toolset name="sun-5.8"/>
            <note author="Thorsten Ottosen">
                This test fails because the test ptr_vector fails. Please see the note
                for that test.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ptr_deque"/>
            <toolset name="cw-9.4"/>
            <toolset name="sun-5.8"/>
            <note author="Thorsten Ottosen">
                For sun the problem is that <code>insert(iterator,range)</code>
                is not available due to partial ordering errors (the core library remains usable).
                For codewarrior the problem is at least <code>std::auto_ptr</code> overloads (the core library remains usable).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ptr_list"/>
            <toolset name="cw-9.4"/>
            <toolset name="sun-5.8"/>
            <note author="Thorsten Ottosen">
                For sun the problem is that <code>insert(iterator,range)</code>
                is not available due to partial ordering errors (the core library remains usable).
                For codewarrior the problem is at least <code>std::auto_ptr</code> overloads (the core library remains usable).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ptr_vector"/>
            <toolset name="cw-9.4"/>
            <toolset name="sun-5.8"/>
            <note author="Thorsten Ottosen">
                For sun the problem is that <code>insert(iterator,range)</code>
                is not available due to partial ordering errors (the core library remains usable).
                For codewarrior the problem is at least <code>std::auto_ptr</code> overloads (the core library remains usable).
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ptr_map"/>
            <toolset name="hp_cxx-71_006_tru64"/>
            <toolset name="cw-9.4"/>
            <toolset name="sun-5.8"/>
            <note author="Thorsten Ottosen">
                For hp, this compiler bug is insignificant.
                For sun the problem is that <code>transfer(range,ptr_map)</code>
                is not available due to partial ordering errors (the core library remains usable).
                For codewarrior the problem is not known so please submit a patch.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="ptr_set"/>
            <toolset name="cw-9.4"/>
            <toolset name="sun-5.8"/>
            <note author="Thorsten Ottosen">
                For sun the problem is that <code>transfer(range,ptr_map)</code> and
                <code>insert(range)</code>code>
                is not available due to partial ordering errors (the core library remains usable).
                For codewarrior the problem is at least <code>std::auto_ptr</code> overloads (the core library remains usable)..
            </note>
        </mark-expected-failures>
           <mark-expected-failures>
            <test name="serialization"/>
            <toolset name="cw*"/>
            <note author="Thorsten Ottosen">
                This cause of this problem is unknown. Please submit a patch.
            </note>
        </mark-expected-failures>
           <mark-expected-failures>
               <test name="tree_test"/>
               <toolset name="sun-5.8"/>
               <note author="Thorsten Ottosen">
                   For sun the problem is due to Boost.Test.                  
               </note>
           </mark-expected-failures>
           <mark-expected-failures>
               <test name="tut1"/>
               <toolset name="cw-9.4"/>
               <note author="Thorsten Ottosen">
                   Seem like a bug in the compiler. Please submit a patch.                  
               </note>
           </mark-expected-failures>
           <mark-expected-failures>
               <test name="view_example"/>
               <toolset name="cw-9.4"/>
               <note author="Thorsten Ottosen">
                   Seem like a bug in the compiler. Please submit a patch.                  
               </note>
           </mark-expected-failures>
    </library>

    <!-- python -->
    <library name="python">
        <mark-unusable>
            <toolset name="borland-5.5.1"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <note refid="2"/>
            <note refid="17"/>
        </mark-unusable>
        <mark-unusable>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <note author="Markus Schoepflin">
            The library fails to compile because of an error in the C++
            standard library implementation on this platform. It incorrectly
            assumes that fpos_t is of an integral type, which is not always
            the case. This is fixed in a later release.
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="sun-5.8*"/>
            <note author="David Abrahams">
            This compiler seems to be having trouble digesting
            Boost.Tuple.  Until it can handle Boost.Tuple there's
            little chance it will handle Boost.Python
            </note>
        </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="pointer_vector"/>
            <test name="polymorphism"/>
            <toolset name="tru64cxx7*"/>
            <toolset name="hp_cxx*"/>
            <note author="Markus Schoepflin" refid="29"/>
        </mark-expected-failures>
       <mark-expected-failures>
            <test name="data_members"/>
            <toolset name="acc"/>
            <note author="Boris Gubenko">
                This test assumes standard-compliant dependent template name lookup which
                is performed by aCC6 only in strict ansi mode. Since on HP-UX/aCC6 boost
                testing is done in the default compilation mode, this test fails to
                compile on this platform (in strict ansi mode, it compiles and succeeds).
            </note>
       </mark-expected-failures>
    </library>

    <!-- random -->
    <library name="random">
        <mark-unusable>
            <toolset name="msvc"/>
            <toolset name="msvc-7.0"/>
            <note author="B. Dawes" refid="10"/>
        </mark-unusable>
        <test name="random_test">
            <mark-failure>
                <toolset name="cw-8.3*"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <note author="B. Dawes" refid="2"/>
            </mark-failure>
            <mark-failure>
                <toolset name="intel-vc71-win*"/>
                <toolset name="intel-vc8-win*"/>
                <note author="S. Slapeta" refid="1"/>
            </mark-failure>
            <mark-failure>
                <toolset name="intel-linux-9.0"/>
                <note author="John Maddock">
                  Reported to Intel as issue 409291, and confirmed
                  as a problem.  Probably this relates to a specific
                  Linux-Kernal or GLibC version.
                </note>
            </mark-failure>
            <mark-failure>
                <toolset name="qcc-3.3.5*"/>
                <note author="Jim Douglas" date="13 Feb 06">
                    Test fails with ranlux*_O1 RNGs when saving and recalling the state due to a bug in the
                    double to string conversion. The problem has been reported to QNX as PR29252.
                </note>
            </mark-failure>
            <mark-failure>
                <toolset name="gcc-*_tru64"/>
                <note author="Markus Schoepflin">
                This test fails because of limitations in the system assembler
                version used by GCC. It most probably would pass if the test
                were split into multiple source files.
                </note>
            </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"/>
            <toolset name="sun-5.8"/>
            <toolset name="borland-5.8*"/>
            <note refid="27" author="Thorsten Ottosen"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="iterator_range"/>
            <toolset name="msvc-stlport"/>
            <toolset name="msvc-6.5_stlport4"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <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="reversible_range"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <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="hp_cxx-65*"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="sun-5.8"/>
            <toolset name="borland-5.8*"/>
            <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="msvc-8.0"/>
            <toolset name="intel-vc8-*"/>
            <toolset name="iw-7_1-vc6-stlp-4_5_3"/>
            <toolset name="msvc-6.5_stlport4"/>
            <toolset name="msvc-7.0"/>
            <toolset name="msvc-7.1_stlport4"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <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>
        <mark-expected-failures>
            <test name="extension_mechanism"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note author="Thorsten Ottosen">
                The test requires support for Argument Dependent Lookup (ADL)
                which the compiler in question does not provide.
            </note>
        </mark-expected-failures>
    </library>

    <!-- regex -->
    <library name="regex">
        <test name="regex_token_iterator_eg_2">
            <mark-failure>
                <toolset name="msvc-6.5"/>
                <note author="J. Maddock"/>
            </mark-failure>
        </test>
        <test name="posix_api_check">
            <mark-failure>
                <toolset name="como-4_3_3-vc7*"/>
                <note author="J. Maddock"/>
            </mark-failure>
        </test>
        <test name="wide_posix_api_check">
            <mark-failure>
                <toolset name="qcc-3.3.5_gpp"/>
                <note author="J. Maddock">
                    No Wide character support on this platform.
                </note>
            </mark-failure>
        </test>
        <test name="wide_posix_api_check_c">
            <mark-failure>
                <toolset name="qcc-3.3.5_gpp"/>
                <note author="J. Maddock">
                    No Wide character support on this platform.
                </note>
            </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="test_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>
        <mark-expected-failures>
            <test name="regex_regress_threaded"/>
            <toolset name="gcc-*_tru64"/>
            <note author="J. Maddock">
              GCC on tru64 appears not to cope with C++ exceptions
              thrown from within threads.
            </note>
        </mark-expected-failures>
        <test name="concept_check">
            <mark-failure>
                <toolset name="msvc-8.0"/>
                <toolset name="sunpro-5_3-sunos"/>
                <toolset name="sun-5.8"/>
                <toolset name="borland-5.8.2"/>
                <toolset name="qcc-3.3.5_cpp"/>
                <note author="John Maddock" refid="2"/>
            </mark-failure>
            <mark-failure>
                <toolset name="tru64cxx*"/>
                <note author="Markus Schoepflin" refid="3"/>
            </mark-failure>
        </test>
        <test name="test_grep">
            <mark-failure>
                <toolset name="gcc-2.95.3-linux"/>
                <toolset name="sunpro-5_3-sunos"/>
               <toolset name="sun-5.8"/>
               <toolset name="msvc-6.5*"/>
                <toolset name="msvc-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="regex_regress"/>
            <test name="regex_regress_threaded"/>
            <test name="regex_regress_dll"/>
            <toolset name="borland*"/>
            <note author="John Maddock">
              There appears to be a linker bug that prevents these
              projects from building, see http://qc.borland.com/wc/qcmain.aspx?d=32020.
            </note>
        </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_regress"/>
            <test name="regex_regress_threaded"/>
            <test name="regex_regress_dll"/>
            <toolset name="borland*"/>
            <note author="John Maddock">
              There appears to be a linker bug that prevents these
              projects from building, see http://qc.borland.com/wc/qcmain.aspx?d=32020.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="regex_timer"/>
            <toolset name="msvc-6.5_stlport4"/>
            <note author="John Maddock">
               Test fails due to unresilved externals from STLport: appears to be
               an STLport bug. </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="regex_regress_threaded"/>
            <test name="static_mutex_test"/>
            <toolset name="msvc-6.5_stlport*"/>
            <toolset name="msvc-7.1_stlport*"/>
            <toolset name="msvc-8.0"/>
            <toolset name="gcc-cygwin*"/>
            <note author="John Maddock">
               These tests pass when run directly from the command line, 
               but fail when run under the regression test script. 
               The issue has never been fully pinned down, but appears
               to be related to how long the tests take to run.</note>
        </mark-expected-failures>
    </library>

    <!-- signals -->
    <library name="signals">
        <mark-unusable>
            <toolset name="sunpro-5_3-sunos"/>
        </mark-unusable>
        <test name="signal_test">
            <mark-failure>
                <toolset name="cw-8.3*"/>
                <note author="B. Dawes" refid="2"/>
            </mark-failure>
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5"/>
                <toolset name="msvc-7.0"/>
                <note author="B. Dawes" refid="3"/>
            </mark-failure>
        </test>
    </library>

    <!-- statechart -->
    <library name="statechart">
        <mark-unusable>
            <toolset name="borland-5*"/>
            <toolset name="cw-8*"/>
            <toolset name="dmc-8*"/>
            <toolset name="gcc-2*"/>
            <toolset name="hp_cxx-65*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0*"/>
            <toolset name="sun-5*"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <note author="Andreas Huber" refid="17"/>
        </mark-unusable>
        <mark-expected-failures>
            <test name="DllTestNormal"/>
            <toolset name="*cygwin*"/>
            <toolset name="*mingw*"/>
            <toolset name="hp_cxx-71*"/>
            <toolset name="cw-9*"/>
            <note author="Andreas Huber">
                A runtime failure of this test indicates that this platform
                <b>dynamically</b> links code in a manner such that under
                certain circumstances more than one instance of a
                header-defined static class member can exist at runtime. See
                <a href="http://www.boost.org/libs/statechart/doc/faq.html#Dll">here</a>
                for more information.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="LibTestNormal"/>
            <toolset name="hp_cxx-71*"/>
            <note author="Andreas Huber">
                A runtime failure of this test indicates that this platform
                <b>statically</b> links code in a manner such that under
                certain circumstances more than one instance of a
                header-defined static class member can exist at runtime. See
                <a href="http://www.boost.org/libs/statechart/doc/faq.html#Dll">here</a>
                for more information.
            </note>
        </mark-expected-failures>
        <mark-expected-failures reason="?">
            <test name="CameraExample"/>
            <test name="CustomReactionTest*"/>
            <test name="PerformanceExample"/>
            <test name="TransitionTest*"/>
            <toolset name="cw-9*"/>
            <note author="Andreas Huber" refid="29"/>
        </mark-expected-failures>
        <mark-expected-failures reason="?">
            <test name="CustomReactionTest*"/>
            <test name="TransitionTest*"/>
            <toolset name="hp_cxx-71*"/>
            <note author="Andreas Huber" refid="29"/>
        </mark-expected-failures>
        <mark-expected-failures reason="?">
            <test name="CustomReactionTest*"/>
            <toolset name="acc"/>
            <note author="Andreas Huber" refid="29"/>
        </mark-expected-failures>
    </library>

    <!-- static_assert -->
    <library name="static_assert">
        <test name="static_assert_example_2">
            <mark-failure>
                <toolset name="sunpro-5_3-sunos"/>
                <note author="J. Maddock" refid="4"/>
            </mark-failure>
        </test>
        <test name="static_assert_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <note author="A.Meredith" date="26 May 2006">
                  This test runs without problem on Borland compilers,
                  which means the static assertion is not being caught.
                </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-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-6.5*"/>
            <toolset name="iw-7_1-vc6"/>
            <toolset name="msvc-7.0"/>
            <toolset name="msvc-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-*"/>
            <toolset name="hp_cxx-65*"/>
            <toolset name="sunpro*"/>
            <toolset name="borland*"/>
            <note author="Gennadiy Rozental" refid="3"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="token_iterator_test"/>
            <toolset name="qcc-3.3.5*gpp"/>
            <note author="Jim Douglas" date="14 Feb 06" refid="36"/>
       </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_fp_comparisons"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="msvc-7.0-stlport"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <note author="Gennadiy Rozental" refid="3"/>
        </mark-expected-failures>

        <mark-expected-failures reason="?">
            <test name="basic_cstring_test"/>
            <toolset name="gcc-2.95.3-linux"/>
            <note refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
          <test name="errors_handling_test"/>
          <test name="test_tools_test"/>
          <toolset name="cw-9_5-darwin"/>
          <note refid="29" author="Doug Gregor"/>
        </mark-expected-failures>

        <mark-expected-failures>
          <test name="test_tools_test"/>
          <toolset name="cw-9.4"/>
          <note refid="29" author="Doug Gregor"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="prg_exec_fail2"/>
            <toolset name="darwin-4.0.1"/>
            <note author="Vladimir Prus">
              The test verifies that Boost.Test detects division by
              zero. Division by zero has an undefined result 
              on PowerPC processors. The compiler has to emit extra 
              code to assert that the divisor isn't zero. 

              Compiler options -fno-trapping-math and -fnon-call-exceptions 
              might affect this. However, in default configuration
              no check is done, and division by zero is not detected.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="prg_exec_fail3"/>
            <toolset name="cw-9.4"/>
            <note author="Vladimir Prus">
              The test appears to test that failed assertion result
              in non-zero exit status.  That seems to be not the
              case, for unknown reasons.
            </note>
        </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="msvc-7.0"/>
                <note author="B. Dawes" refid="0"/>
                <note author="B. Dawes" refid="6"/>
            </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 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>
        <!--
        It is unclear why this has been marked as expected failure. The
        pthread_timedwait is giving an error code of EINVAL, which needs to
        be resolved, since the timed behaviour is affected by this bug.
        Marked as a failure again by Roland Schwarz, 2007-01-12
        <mark-expected-failures>
            <test name="test_mutex"/>
            <test name="test_mutex_lib"/>
            <toolset name="qcc-3.3*"/>
            <note author="Jim Douglas" date="13 Feb 06" refid="16"/>
        </mark-expected-failures>
        -->
        <mark-expected-failures>
            <test name="test_tss_lib"/>
            <toolset name="borland-*"/>
            <toolset name="cw-9.4"/>
            <toolset name="gcc-mingw*"/>
            <note author="Roland Schwarz" date="2006-12-14">
                When a thread ends, tss data needs to be cleaned up. This process
                is mostly automatic. When threads are launched by the Boost.Thread API
                cleanup is handled by the library implementation. For threads, launched
                by the native operating system API it is not possible to get this cleanup
                on every compiler/platform. A warning (error) will be present in this case,
                which cleary states this fact. It is recommended to start threads only
                by means of the Boost.Thread API if you need to avoid the leaks that appear
                on the end of the thread. If this is not possible the cleanup can be invoked
                from user code before the process actually ends. For library implementors
                this means to call these functions during library initialization and 
                finalization.   
            </note>
        </mark-expected-failures>
    </library>

    <!-- tuple -->
    <library name="tuple">
        <mark-unusable>
            <toolset name="sunpro-5_3-sunos"/>
        </mark-unusable>
    </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-6.5*"/>
            <toolset name="msvc-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="decay_test"/>
            <test name="extent_test"/>
            <test name="is_base_and_derived_test"/>
            <test name="is_base_of_test"/>
            <test name="is_convertible_test"/>
            <test name="rank_test"/>
            <test name="remove_all_extents_test"/>
            <test name="remove_bounds_test"/>
            <test name="remove_const_test"/>
            <test name="remove_extent_test"/>
            <test name="remove_pointer_test"/>
            <test name="remove_volatile_test"/>
            <test name="tricky_add_pointer_test"/>
            <test name="tricky_function_type_test"/>
            <test name="tricky_incomplete_type_test"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="borland-5.8*"/>
            <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="borland-5.8*"/>
                <toolset name="msvc-6.5*"/>
                <toolset name="gcc-2.95.3-*"/>
            </mark-failure>
        </test>
        <test name="tricky_incomplete_type_test">
            <mark-failure>
                <toolset name="iw-7_1*"/>
                <note author="John Maddock" refid="2"/>
            </mark-failure>
        </test>
        <test name="is_abstract_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="cw-8.3*"/>
                <toolset name="cw-9.3*"/>
                <toolset name="cw-9.4"/>
                <toolset name="cw-9.5"/>
                <toolset name="msvc-6.5*"/>
                <toolset name="msvc-7.0"/>
                <toolset name="mingw-3_3*"/>
                <toolset name="gcc-2*"/>
                <toolset name="gcc-3.2*"/>
                <toolset name="gcc-3.3*"/>
                <toolset name="qcc-3.3*"/>
                <toolset name="sunpro-5_3-sunos"/>
                <toolset name="tru64cxx65-*"/>
                <toolset name="hp_cxx-65*"/>
                <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="decay_test"/>
          <test name="extent_test"/>
          <test name="is_abstract_test"/>
          <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_object_test"/>
          <test name="is_reference_test"/>
          <test name="rank_test"/>
          <test name="tricky_function_type_test"/>
          <toolset name="sun-5.8"/>

          <note author="John Maddock">
             The Type Traits library is broken when used with Sunpro-5.8 and the
             argument to the template is a function type.  Most other argument types
             do work as expected: in other words the functionality is limited
             with this compiler, but not so much as to render the library unuseable.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
            <test name="tricky_function_type_test"/>
            <test name="is_const_test"/>
            <test name="is_volatile_test"/>
            <test name="is_convertible_test"/>
            <toolset name="gcc-2*"/>
            <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>

    <!-- tr1 -->
    <library name="tr1">
        <mark-unusable>
            <toolset name="msvc-7.0"/>
            <toolset name="msvc-6*"/>
            <note author="John Maddock">
                VC6/7 has a buggy using declaration syntax which
                basically makes it impossible to implement the 
                namespace forwarding that this library relies upon.
                See KB article 263630 here: http://support.microsoft.com/default.aspx?scid=kb;en-us;263630
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="cw-*"/>
            <note author="John Maddock">
                Metrowerks Codeworrier has partial TR1 support built in
                which conflicts with this implementation.  Porting to this
                compiler is almost certainly possible, but will require some 
                work by someone who has this compiler.
            </note>
        </mark-unusable>
        <mark-expected-failures>
            <test name="test_mem_fn_tricky"/>
            <test name="test_bind_tricky"/>
            <test name="test_ref_wrapper_tricky"/>
            <test name="test_function_tricky"/>
            <test name="std_test_mem_fn_tricky"/>
            <test name="std_test_bind_tricky"/>
            <test name="std_test_ref_wrapper_tricky"/>
            <test name="std_test_function_tricky"/>
            <test name="std_test_reference_wrapper_tricky"/>
            <test name="test_reference_wrapper_tricky"/>
            <toolset name="*"/>
            <note author="John Maddock">
                These tests test features that are not supported in the
                current Boost implementations of TR1 components, they will
                currently fail on all compilers, unless that compiler has 
                native TR1 support.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_regex"/>
            <test name="std_test_regex"/>
            <test name="test_hash"/>
            <test name="std_test_hash"/>
            <toolset name="mingw*"/>
            <toolset name="qcc*gpp"/>
            <toolset name="gcc-2*"/>
            <note author="John Maddock">
               These tests fail on this platform due to a lack of
               wide character support.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_regex"/>
            <test name="std_test_regex"/>
            <toolset name="gcc-mingw*"/>
            <note author="John Maddock">
               These tests fail on this platform due to incomplete
               wide character support.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_hash"/>
            <test name="std_test_hash"/>
            <toolset name="gcc-cygwin*"/>
            <note author="John Maddock">
               These tests fail on this platform due to incomplete
               wide character support.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_array"/>
            <test name="std_test_array"/>
            <test name="test_array_tricky"/>
            <test name="std_test_array_tricky"/>
            <test name="test_complex"/>
            <test name="std_test_complex"/>
            <test name="test_function"/>
            <test name="std_test_function"/>
            <test name="test_mem_fn"/>
            <test name="std_test_mem_fn"/>
            <test name="test_random"/>
            <test name="std_test_random"/>
            <test name="test_regex"/>
            <test name="std_test_regex"/>
            <test name="test_result_of"/>
            <test name="std_test_result_of"/>
            <test name="test_shared_ptr"/>
            <test name="std_test_shared_ptr"/>
            <test name="test_tr1_include"/>
            <test name="std_test_tr1_include"/>
            <test name="test_tuple"/>
            <test name="std_test_tuple"/>
            <test name="test_tuple_tricky"/>
            <test name="std_test_tuple_tricky"/>
            <test name="test_type_traits"/>
            <test name="std_test_type_traits"/>
            <test name="run_complex_overloads"/>
            <test name="std_run_complex_overloads"/>
            <test name="run_random"/>
            <test name="std_run_random"/>
            <test name="test_tuple_tricky"/>
            <test name="tr1_add_const_test"/>
            <test name="tr1_add_cv_test"/>
            <test name="tr1_add_pointer_test"/>
            <test name="tr1_add_reference_test"/>
            <test name="tr1_add_volatile_test"/>
            <test name="tr1_aligned_storage_test"/>
            <test name="tr1_alignment_of_test"/>
            <test name="tr1_has_nothrow_assign_test"/>
            <test name="tr1_has_nothrow_constr_test"/>
            <test name="tr1_has_nothrow_copy_test"/>
            <test name="tr1_has_trivial_assign_test"/>
            <test name="tr1_has_trivial_constr_test"/>
            <test name="tr1_has_trivial_copy_test"/>
            <test name="tr1_has_trivial_destr_test"/>
            <test name="tr1_has_virtual_destr_test"/>
            <test name="tr1_is_arithmetic_test"/>
            <test name="tr1_is_array_test"/>
            <test name="tr1_is_class_test"/>
            <test name="tr1_is_compound_test"/>
            <test name="tr1_is_const_test"/>
            <test name="tr1_is_convertible_test"/>
            <test name="tr1_is_empty_test"/>
            <test name="tr1_is_enum_test"/>
            <test name="tr1_is_floating_point_test"/>
            <test name="tr1_is_function_test"/>
            <test name="tr1_is_fundamental_test"/>
            <test name="tr1_is_integral_test"/>
            <test name="tr1_is_member_func_test"/>
            <test name="tr1_is_member_obj_test"/>
            <test name="tr1_is_member_pointer_test"/>
            <test name="tr1_is_object_test"/>
            <test name="tr1_is_pod_test"/>
            <test name="tr1_is_pointer_test"/>
            <test name="tr1_is_polymorphic_test"/>
            <test name="tr1_is_reference_test"/>
            <test name="tr1_is_same_test"/>
            <test name="tr1_is_scalar_test"/>
            <test name="tr1_is_signed_test"/>
            <test name="tr1_is_union_test"/>
            <test name="tr1_is_unsigned_test"/>
            <test name="tr1_is_void_test"/>
            <test name="tr1_is_volatile_test"/>
            <test name="tr1_remove_const_test"/>
            <test name="tr1_remove_cv_test"/>
            <test name="tr1_remove_pointer_test"/>
            <test name="tr1_remove_reference_test"/>
            <test name="tr1_remove_volatile_test"/>
            <test name="tr1_tky_abstract_type_test"/>
            <test name="tr1_tricky_add_pointer_test"/>
            <test name="tr1_tky_partial_spec_test"/>
            <toolset name="borland-5.6*"/>
            <note author="John Maddock">
               Support for Borland C++ in the various TR1 libraries is pretty
               poor (due to numerous compiler bugs sadly).  The TR1 concept
               checks are *very* strict, and are expected to fail with this
               compiler.  In addition most of the type_traits tests fail
               whenever debugging support is turned on with an internal
               compiler error.  More conservative uses are more likely to succeed
               with this compiler however.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_complex"/>
            <test name="std_test_complex"/>
            <test name="test_function"/>
            <test name="std_test_function"/>
            <test name="test_mem_fn"/>
            <test name="std_test_mem_fn"/>
            <test name="test_random"/>
            <test name="std_test_random"/>
            <test name="test_result_of"/>
            <test name="std_test_result_of"/>
            <test name="test_shared_ptr"/>
            <test name="std_test_shared_ptr"/>
            <test name="test_tuple"/>
            <test name="std_test_tuple"/>
            <test name="test_tuple_tricky"/>
            <test name="std_test_tuple_tricky"/>
            <test name="test_type_traits"/>
            <test name="std_test_type_traits"/>
            <test name="run_complex_overloads"/>
            <test name="std_run_complex_overloads"/>
            <test name="run_random"/>
            <test name="std_run_random"/>
            <test name="test_tuple_tricky"/>
            <test name="tr1_is_convertible_test"/>
            <test name="tr1_remove_const_test"/>
            <test name="tr1_remove_pointer_test"/>
            <test name="tr1_remove_volatile_test"/>
            <test name="tr1_tricky_add_pointer_test"/>
            <toolset name="borland-5.8*"/>
            <note author="John Maddock">
               Support for Borland C++ in the various TR1 libraries is pretty
               poor (due to numerous compiler bugs sadly).  The TR1 concept
               checks are *very* strict, and are expected to fail with this
               compiler.  More conservative uses are more likely to succeed
               with this compiler however.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="std_test_bind"/>
            <test name="test_bind"/>
            <toolset name="gcc-4*darwin"/>
            <toolset name="darwin*"/>
            <note author="John Maddock">
               These tests fail on this platform due to a recuring GCC bug.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_type_traits"/>
            <test name="std_test_type_traits"/>
            <test name="tr1_is_abstract_test"/>
            <toolset name="gcc-3.3.*"/>
            <toolset name="gcc-3.2*"/>
            <toolset name="qcc-3.3*"/>
            <note author="John Maddock">
               These tests fail due to a known compiler bug 
               that is fixed in more recent GNU compiler releases.  Users are
               very unlikely to encounter this as a real problem 
               in practice.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_regex"/>
            <test name="std_test_regex"/>
            <test name="test_complex"/>
            <test name="std_test_complex"/>
            <test name="run_complex_overloads"/>
            <test name="std_run_complex_overloads"/>
            <toolset name="gcc-2*"/>
            <note author="John Maddock">
               These tests fail due to a known compiler bug 
               that is fixed in more recent releases.  Users are
               very unlikely to encounter this as a real problem 
               in practice.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_type_traits"/>
            <test name="std_test_type_traits"/>
            <test name="test_result_of"/>
            <test name="std_test_result_of"/>
            <test name="tr1_is_abstract_test"/>
            <test name="test_ios"/>
            <test name="test_istream"/>
            <test name="test_ostream"/>
            <test name="test_streambuf"/>
            <test name="test_limits"/>
            <test name="test_locale"/>
            <test name="test_ios_std_header"/>
            <test name="test_istream_std_header"/>
            <test name="test_limits_std_header"/>
            <test name="test_locale_std_header"/>
            <test name="test_ostream_std_header"/>
            <test name="test_streambuf_std_header"/>
            <toolset name="gcc-2*"/>
            <note author="John Maddock">
               These tests fail due to a known compiler bug 
               that is fixed in more recent releases.  This
               functionality may not be usable with this compiler.
            </note>
        </mark-expected-failures>

        <mark-expected-failures>
           <test name="run_complex_overloads"/>
           <test name="std_run_complex_overloads"/>
           <test name="std_test_complex"/>
           <test name="test_complex"/>
           <toolset name="qcc-3.3.5*gpp"/>
            <note author="John Maddock">
               These tests fail due to a known stdlib bug 
               that has been reported to the vendor.
            </note>
        </mark-expected-failures>
       
        <mark-expected-failures>
            <test name="tr1_function_traits_test"/>
            <test name="tr1_remove_bounds_test"/>
            <test name="tr1_remove_const_test"/>
            <test name="tr1_remove_cv_test"/>
            <test name="tr1_remove_pointer_test"/>
            <test name="tr1_remove_reference_test"/>
            <test name="tr1_remove_volatile_test"/>
            <test name="tr1_decay_test"/>
            <test name="tr1_extent_test"/>
            <test name="tr1_remove_extent_test"/>
            <test name="tr1_remove_all_extents_test"/>
            <test name="tr1_rank_test"/>
            <test name="tr1_is_unsigned_test"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-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="tr1_tky_incomplete_type_test"/>
            <test name="tr1_tky_incomp_type_test"/>
            <test name="tr1_decay_test"/>
            <test name="tr1_extent_test"/>
            <test name="tr1_is_base_of_test"/>
            <test name="tr1_rank_test"/>
            <test name="tr1_remove_all_extents_test"/>
            <test name="tr1_remove_extent_test"/>
            <test name="tr1_tky_function_type_test"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <note author="John Maddock" refid="2"/>
        </mark-expected-failures>
        <test name="tr1_tricky_is_enum_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="msvc-6.5*"/>
                <toolset name="gcc-2.95.3-*"/>
            </mark-failure>
        </test>
        <test name="tr1_tricky_incomplete_type_test">
            <mark-failure>
                <toolset name="iw-7_1*"/>
                <note author="John Maddock" refid="2"/>
            </mark-failure>
        </test>
        <test name="tr1_tricky_incomp_type_test">
            <mark-failure>
                <toolset name="iw-7_1*"/>
                <note author="John Maddock" refid="2"/>
            </mark-failure>
        </test>
        <test name="tr1_tky_incomp_type_test">
            <mark-failure>
                <toolset name="iw-7_1*"/>
                <note author="John Maddock" refid="2"/>
            </mark-failure>
        </test>
        <test name="tr1_is_abstract_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <toolset name="cw-8.3*"/>
                <toolset name="cw-9.3*"/>
                <toolset name="cw-9.4*"/>
                <toolset name="cw-9.5*"/>
                <toolset name="msvc-6.5*"/>
                <toolset name="msvc-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="qcc-3_3*"/>
                <toolset name="sunpro-5_3-sunos"/>
                <toolset name="tru64cxx65*"/>
                <toolset name="hp_cxx-65*"/>
                <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="tr1_is_polymorphic_test"/>
          <toolset name="gcc-2.95.3-stlport-*"/>
          <note author="Doug Gregor" refid="3"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="tr1_decay_test"/>
            <test name="tr1_extent_test"/>
            <test name="tr1_has_nothrow_assign_test"/>
            <test name="tr1_has_nothrow_constr_test"/>
            <test name="tr1_has_nothrow_copy_test"/>
            <test name="tr1_has_trivial_assign_test"/>
            <test name="tr1_has_trivial_constr_test"/>
            <test name="tr1_has_trivial_copy_test"/>
            <test name="tr1_has_trivial_destr_test"/>
            <test name="tr1_is_array_test"/>
            <test name="tr1_is_base_and_derived_test"/>
            <test name="tr1_is_base_of_test"/>
            <test name="tr1_is_class_test"/>
            <test name="tr1_is_convertible_test"/>
            <test name="tr1_is_object_test"/>
            <test name="tr1_is_pod_test"/>
            <test name="tr1_is_polymorphic_test"/>
            <test name="tr1_rank_test"/>
            <test name="tr1_remove_all_extents_test"/>
            <test name="tr1_remove_bounds_test"/>
            <test name="tr1_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="tr1_decay_test"/>
          <test name="tr1_extent_test"/>
          <test name="tr1_is_abstract_test"/>
          <test name="tr1_is_empty_test"/>
          <test name="tr1_is_function_test"/>
          <test name="tr1_is_member_func_test"/>
          <test name="tr1_is_member_obj_test"/>
          <test name="tr1_is_object_test"/>
          <test name="tr1_is_reference_test"/>
          <test name="tr1_rank_test"/>
          <test name="tr1_tricky_function_type_test"/>
          <test name="tr1_tky_function_type_test"/>
          <test name="test_type_traits"/>
          <test name="std_test_type_traits"/>
          <toolset name="sun-5.8"/>

          <note author="John Maddock">
             The Type Traits library is broken when used with Sunpro-5.8 and the
             argument to the template is a function type.  Most other argument types
             do work as expected: in other words the functionality is limited
             with this compiler, but not so much as to render the library unuseable.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
          <test name="test_random"/>
          <test name="std_test_random"/>
          <toolset name="sun-5.8"/>

          <note author="John Maddock">
             These failures appear to represent a genuine issue with the
             Boost.Random library that has yet to be addressed.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
          <test name="test_boost"/>
          <test name="test_hash"/>
          <test name="test_random"/>
          <test name="test_regex"/>
          <toolset name="msvc-7.1_stlport4"/>

          <note author="John Maddock">
             These failures are completely spurious: they're caused by the tests
             being run with bjam -j2 and the post-processing not coping with the
             resulting output.  These failures should clear if these tests
             are re-run at some point in the future.
          </note>
       </mark-expected-failures>
       <mark-expected-failures>
            <test name="tr1_is_empty_test"/>
            <test name="tr1_is_function_test"/>
            <test name="tr1_is_member_func_test"/>
            <test name="tr1_is_member_obj_test"/>
            <test name="tr1_is_reference_test"/>
            <test name="tr1_tricky_function_type_test"/>
            <test name="tr1_tricky_incomplete_type_test"/>
            <test name="tr1_tricky_incomp_type_test"/>
            <test name="tr1_tricky_is_enum_test"/>
            <toolset name="sunpro-5_3-sunos"/>
            <note author="John Maddock" refid="2"/>
        </mark-expected-failures>
       <mark-expected-failures>
            <test name="tr1_tricky_function_type_test"/>
            <test name="tr1_is_const_test"/>
            <test name="tr1_is_volatile_test"/>
            <test name="tr1_is_convertible_test"/>
            <toolset name="gcc-2*"/>
            <note author="John Maddock" refid="2"/>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="test_array"/>
            <test name="std_test_array"/>
            <test name="test_array_tricky"/>
            <test name="std_test_array_tricky"/>
            <test name="test_bind"/>
            <test name="std_test_bind"/>
            <test name="test_complex"/>
            <test name="std_test_complex"/>
            <test name="test_function"/>
            <test name="std_test_function"/>
            <test name="test_random"/>
            <test name="std_test_random"/>
            <test name="test_reference_wrapper"/>
            <test name="std_test_reference_wrapper"/>
            <test name="test_regex"/>
            <test name="std_test_regex"/>
            <test name="test_result_of"/>
            <test name="std_test_result_of"/>
            <test name="test_shared_ptr"/>
            <test name="std_test_shared_ptr"/>
            <test name="test_tuple"/>
            <test name="std_test_tuple"/>
            <toolset name="vc-7"/>
            <note author="John Maddock">
            This library is almost unusable with VC7 due to name lookup issues.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="tr1_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-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <toolset name="cw-8.3*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <toolset name="gcc-2.95.3-*"/>
            <note refid="3"/>
        </mark-unusable>

        <mark-expected-failures>
          <test name="no_disambiguation"/>
          <toolset name="gcc-3.2.*"/>
          <note refid="3"/>
        </mark-expected-failures>
    </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="numeric_traits_test">
            <mark-failure>
                <toolset name="borland-5.6.4"/>
                <toolset name="borland-5.8*"/>
                <note author="A.Meredith">
                  Compiler has a problem with BOOST_STATIC_CONSTANT in nested templates
                  inside class template specializations.
                </note>
            </mark-failure>
        </test>
        <test name="result_of_test">
            <mark-failure>
                <toolset name="borland-5*"/>
                <toolset name="cw-8.3*"/>
                <toolset name="msvc-6.5*"/>
                <toolset name="msvc-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="none_test"/>
            <toolset name="borland-5.8.2"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note author="Fernando Cacciola">
                This failure is caused by an UNRELATED compiler bug resulted from the particular test strategy.
                'boost::none' DOES work correctly in this compiler.
            </note>
        </mark-expected-failures>
        <mark-expected-failures>
            <test name="value_init_test"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-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>
        <mark-expected-failures>
            <test name="operators_test"/>
            <toolset name="gcc-3.4.5_linux_x86_64"/>
            <note author="Vladimir Prus">
                The test takes more that 30 minutes to compile and the
                compilation is automatically killed. It is likely caused
                by the compiler bug, but it unknown how much this
                bug affects regular use of the operators library. Is it
                also unknown if the test can be refactored so that
                not to trigger this bug.
            </note>
        </mark-expected-failures>
    </library>


    <!-- variant -->
    <library name="variant">
        <mark-unusable>
            <toolset name="mipspro"/>
            <toolset name="sunpro-5_3-sunos"/>
            <toolset name="tru64cxx65*"/>
            <toolset name="hp_cxx-65*"/>
            <note refid="2"/>
        </mark-unusable>
        <test name="recursive_variant_test">
            <mark-failure>
                <toolset name="como-win32"/>
                <toolset name="msvc-6.5*"/>
                <toolset name="msvc-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-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <note author="Aleksey Gurtovoy" refid="3"/>
        </mark-expected-failures>
        <test name="variant_reference_test">
            <mark-failure>
                <toolset name="cw-8.3*"/>
                <toolset name="msvc-6.5*"/>
                <toolset name="msvc-7.0"/>
                <note refid="3"/>
            </mark-failure>
            <mark-failure>
                <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-6.5*"/>
            <toolset name="sunpro-5_3-sunos"/>
            <toolset name="borland-5.5.1"/>
            <toolset name="borland-5.6.4"/>
            <toolset name="borland-5.8*"/>
            <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*"/>
            <toolset name="hp_cxx-65*"/>
            <note refid="29"/>
        </mark-unusable>
       <mark-unusable>
            <toolset name="msvc-7.0"/>
            <note>
               This toolset isn't supported because of the used Spirit V1.8.x, which in turn is
               not usable with this toolset.
            </note>
        </mark-unusable>

        <mark-expected-failures>
            <test name="testwave"/>
            <!-- toolset name="cw-9_5-darwin"/ -->
            <toolset name="cw-8*"/>
            <note author="Rene Rivera" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testwave"/>
            <toolset name="gcc-3.2.3-linux"/>
            <toolset name="gcc-3.2.3_linux"/>
            <toolset name="gcc-3.3.6-linux"/>
            <toolset name="gcc-3.3.6"/>
            <note author="Hartmut Kaiser" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testwave"/>
            <toolset name="qcc-3.3.5*gpp"/>
            <toolset name="sun-5.8"/>
            <note author="Hartmut Kaiser" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testwave_dll"/>
            <toolset name="mingw-3*"/>
            <toolset name="sun-5.8"/>
            <note author="Hartmut Kaiser" refid="29"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="testwave_dll"/>
            <toolset name="cw-9.4"/>
            <toolset name="gcc-mingw-3.4.0"/>
            <toolset name="gcc-mingw-3.4.2"/>
            <note author="Hartmut Kaiser" refid="2"/>
        </mark-expected-failures>

        <mark-expected-failures>
            <test name="test_slex_lexer"/>
            <toolset name="hp_cxx-65*"/>
            <note author="Hartmut Kaiser" refid="2"/>
        </mark-expected-failures>

    </library>

    <!-- xpressive -->
    <library name="xpressive">

        <mark-unusable>
            <toolset name="gcc-2.95.3*"/>
            <toolset name="msvc-6.5*"/>
            <toolset name="msvc-7.0"/>
            <note author="Eric Niebler">
                These compilers do not support class template partial
                specialization.
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="borland-5*"/>
            <note author="Eric Niebler">
                Boost.Fusion doesn't work on this compiler.
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="cw-8.3"/>
            <note author="Eric Niebler">
                This compiler doesn't support SFINAE / enable_if
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="dmc*"/>
            <note author="Eric Niebler">
                Digital Mars cannot seem to handle dependent default template parameters,
                such as "template &lt; class T, bool B = is_foo &lt; T &gt; ::value &gt;"
            </note>
        </mark-unusable>
        <mark-unusable>
            <toolset name="sunpro-5_3-sunos"/>
            <toolset name="sun-5.8"/>
            <note refid="17"/>
        </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 are aware of
        the problem and plan to fix it.
    </note>

    <note id="2">
        The failure is caused by a compiler bug.
    </note>

    <note id="3">
        The failure is caused by a compiler bug, which has been reported to the compiler
        supplier (or is already known to them).
    </note>

    <note id="4">
        The failure is caused by a standard library bug.
    </note>

    <note id="5">
        The failure is caused by a standard library bug, which has been reported to the
        standard library supplier (or is already known to them).
    </note>

    <note id="6">
        The failure is probably caused by the test code, harness, or configuration. Thus,
        it may not affect users of the library.
    </note>

    <note id="9">
        The failure is serious and likely to prevent all use of this Boost library with this compiler.
    </note>

    <note id="10">
        The failure is serious and likely to prevent all use of this Boost library with this
        compiler. The failure is caused by a compiler bug, which has been reported to the compiler
        supplier (or is already known to them).
    </note>

    <note id="14">
        The failure is caused by a platform API bug.
    </note>

    <note id="15">
        The failure is caused by a platform API bug, which has been reported to the platform API
        supplier (or is already known to them).
    </note>

    <note id="16">
        The failure is not serious and will not affect most users. The library degrades gracefully.
    </note>

    <note id="17">
        This compiler's bugs are not supported by the library.
    </note>

    <note id="18">
      Locales missing or adequately supported by this compiler.
    </note>

    <note id="19">
      Missing or inadequate wchar/wstring/wstream support for this compiler.
    </note>

    <note id="20">
      No std iterator traits for this compiler.
    </note>

    <note id="21">
      Library has limited input/output support due to compiler inadequacies.
    </note>

    <note id="22">
      No high precision clock for this platform.
    </note>

    <note id="23">
      A bug in standard library prevents passing std::set from DLL to
      application. A fixed &lt;tree&gt; header is available from
      http://www.dinkumware.com/vc_fixes.html.
    </note>

    <note id="24">
      Although the documentation from the Comeau website would make it appear
      that windows DLL's are supported using the --windows option,  after some
      experimentation we have been unsuccessful in making dll configurations
      work correctly.
    </note>

    <note id="25">
      The failure is caused by a runtime limitation. Locale support is only
      available with the static linked variant of the runtime. Generally
      the dynamic linked variant is required when building dynamic modules,
      DLL, <code>so</code>, etc.
    </note>

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

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

    <note id="28">
        Unresearched failure -- please contact library developers for more
        information about possible causes.
    </note>

    <note id="29">
        The test fails due to unresearched issues. The library
        developers are aware of this failure, but need help with
        investigating/addressing it for future releases.
    </note>

    <note id="30">
        The support for this deficient compiler will be dropped starting
        from Boost 1.33.0 release. Please use one of the previous Boost
        releases if you need the library to work on this compiler.
    </note>

    <note id="31">
        This failure is caused by compiler bugs or limitations. Some advanced
        or esoteric library features may be unavailable or only partially available.
        This does not impact most common uses of the library.
    </note>

    <note id="32">
        This failure is caused by a compiler bug. Certain code constructs that should
        fail compilation are accepted by the compiler. This can mask some programming
        errors, but does not impact the usability of the library.
    </note>

    <note id="33">
        The failures are caused by the wrong handling of the
        <code>std::internal</code> flag in the iostreams implementation of the
        standard library used on that compiler/platform combo. Apart from that,
        the format library works as expected.
    </note>

    <note id="34">
        The failures are caused by the fact that the iword and pword arrays seem
        to share the same memory area in the iostreams implementation of the
        standard library used on that compiler/platform combo. As long as you
        stay clear of iword and pword, the library should work ok.
    </note>

    <note id="35">
        This failure occurs only when using shared libraries for this
        compiler and platform, although the same programs should work
        properly when using static libraries. This problem has not
        been researched.
    </note>

    <note id="36">
        Wide character support is disabled in the GNU Standard C++ library as
        supplied on the QNX Neutrino version 6.3.0 distribution. 
    </note>

    <note id="37">
        This problem is due to the non-conforming STLport
        implementation of vector's swap: it can be easily
        reproduced with the following code snippet:

            typedef std::vector&lt;int&gt; vector_type;
            typedef vector_type::reference reference_type;

            vector_type v1(4u, 1);
            vector_type v2(7u, 0);

            reference_type ref = v1[2];
            int x = ref;

            std::swap(v1, v2);
            BOOST_CHECK(v2[2] == x); // ok
            v2[2] = 1 - v2[2];
            BOOST_CHECK(ref != x);   // oops
    </note>

</explicit-failures-markup>