Boost regression notification (2005-12-01 [HEAD])
Boost regression test failures ------------------------------ Report time: 2005-12-01T06:00:10Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues.... 625 failures in 21 libraries: bind (1) concept_check (14) date_time (17) filesystem (5) foreach (5) graph (3) io (1) math (3) mpl (1) multi_array (7) parameter (1) program_options (14) python (289) regex (1) serialization (36) smart_ptr (1) spirit (3) tr1 (171) typeof (24) wave (4) xpressive (24) |bind| bind_dm3_test: msvc |concept_check| stl_concept_covering: cw-9_4 cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |date_time| testc_local_adjustor: msvc testclock: msvc testdst_rules: msvc testfiletime_functions: msvc testgreg_duration_operators: msvc testgreg_serialize_dll: cw-9_4 intel-win32-8_1 vc-7_1 testiterator: msvc testlocal_adjustor: msvc testmicrosec_time_clock: msvc testparse_time: msvc testtime: msvc testtime_formatters: msvc testtime_period: msvc testwcustom_time_zone: msvc testwposix_time_zone: msvc |filesystem| path_test: mingw-3_4_2 msvc vc-7_1 path_test_dll: msvc vc-7_1 |foreach| array_byref: intel-win32-8_1 array_byval: intel-win32-8_1 rvalue_const: intel-win32-9_0 stl_byref: intel-win32-8_1 stl_byval: intel-win32-8_1 |graph| graphviz_test: vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3_4_3-sunos msvc log1p_expm1_test: msvc |mpl| size_t: gcc-4_0-darwin |multi_array| access: cw-9_4 assign: cw-9_4 assign_to_array: cw-9_4 idxgen1: cw-9_4 index_bases: cw-9_4 iterators: cw-9_4 slice: cw-9_4 |parameter| sfinae: msvc |program_options| cmdline_test: vc-7_1 cmdline_test_dll: vc-7_1 options_description_test: vc-7_1 options_description_test_dll: vc-7_1 parsers_test: vc-7_1 parsers_test_dll: vc-7_1 positional_options_test: vc-7_1 positional_options_test_dll: vc-7_1 unicode_test: vc-7_1 unicode_test_dll: vc-7_1 variable_map_test: vc-7_1 variable_map_test_dll: vc-7_1 winmain: vc-7_1 winmain_dll: vc-7_1 |python| andreas_beyer: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 args: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 auto_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 back_reference: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 ben_scott1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman3: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 builtin_converters: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 callbacks: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 const_argument: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 crossmod_exception: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 data_members: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 defaults: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 dict: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 docstring: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 enum: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 exception_translator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 exec: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos extract: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 implicit: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 injected: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 iterator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 keywords: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 list: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 long: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 map_indexing_suite: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 minimal: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 multi_arg_constructor: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 nested: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 numpy: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 object: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 opaque: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 operators: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pearu1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle3: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle4: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pointer_vector: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism2_auto_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 properties: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 raw_ctor: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 return_arg: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 select_from_python_test: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos shared_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 slice: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 staticmethod: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 stl_iterator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos msvc vc-7_1 str: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 test_pointer_adoption: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 try: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 tuple: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 vector_indexing_suite: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 virtual_functions: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 wrapper_held_type: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 |regex| grep: vc-7_1 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |smart_ptr| shared_ptr_alloc2_test: msvc |spirit| multi_pass_compile_tests: intel-win32-8_1 traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: cw-9_4 gcc-3_4_3-sunos msvc run_random: msvc std_run_complex_overloads: cw-9_4 gcc-3_4_3-sunos msvc std_run_random: cw-9_4 msvc std_test_array: cw-9_4 msvc std_test_bind: cw-9_4 msvc std_test_boost: msvc std_test_complex: cw-9_4 msvc std_test_function: cw-9_4 msvc std_test_hash: cw-9_4 msvc std_test_mem_fn: cw-9_4 msvc std_test_random: cw-9_4 msvc std_test_reference_wrapper: msvc std_test_regex: cw-9_4 msvc std_test_result_of: cw-9_4 msvc std_test_shared_ptr: msvc std_test_tr1_include: cw-9_4 msvc std_test_tuple: cw-9_4 msvc std_test_type_traits: cw-9_4 msvc test_array: msvc test_bind: cw-9_4 msvc test_complex: cw-9_4 msvc test_function: cw-9_4 msvc test_functional: msvc test_hash: cw-9_4 msvc test_mem_fn: cw-9_4 msvc test_random: cw-9_4 msvc test_reference_wrapper: cw-9_4 msvc test_regex: msvc test_result_of: cw-9_4 msvc test_shared_ptr: cw-9_4 msvc test_tr1_include: cw-9_4 msvc test_tuple: cw-9_4 msvc test_type_traits: msvc test_utility: msvc tr1_add_const_test: cw-9_4 msvc tr1_add_cv_test: cw-9_4 msvc tr1_add_pointer_test: cw-9_4 msvc tr1_add_reference_test: cw-9_4 msvc tr1_add_volatile_test: cw-9_4 msvc tr1_aligned_storage_test: cw-9_4 msvc tr1_alignment_of_test: cw-9_4 msvc tr1_extent_test: cw-9_4 tr1_has_nothrow_assign_test: cw-9_4 msvc tr1_has_nothrow_constr_test: cw-9_4 msvc tr1_has_nothrow_copy_test: cw-9_4 msvc tr1_has_tr1_ref_wrap_fail: cw-9_4 tr1_has_tr1_shared_ptr_fail: cw-9_4 tr1_has_tr1_tuple_fail: cw-9_4 tr1_has_trivial_assign_test: cw-9_4 msvc tr1_has_trivial_constr_test: cw-9_4 msvc tr1_has_trivial_copy_test: cw-9_4 msvc tr1_has_trivial_destructor_test: cw-9_4 msvc tr1_has_virtual_destructor_test: cw-9_4 msvc tr1_is_arithmetic_test: cw-9_4 msvc tr1_is_array_test: cw-9_4 msvc tr1_is_base_of_test: cw-9_4 msvc tr1_is_class_test: cw-9_4 msvc tr1_is_compound_test: cw-9_4 msvc tr1_is_const_test: cw-9_4 msvc tr1_is_convertible_test: cw-9_4 msvc tr1_is_empty_test: cw-9_4 msvc tr1_is_enum_test: cw-9_4 msvc tr1_is_floating_point_test: cw-9_4 msvc tr1_is_function_test: cw-9_4 msvc tr1_is_fundamental_test: cw-9_4 msvc tr1_is_integral_test: cw-9_4 msvc tr1_is_member_func_test: cw-9_4 msvc tr1_is_member_obj_test: cw-9_4 msvc tr1_is_member_pointer_test: cw-9_4 msvc tr1_is_object_test: cw-9_4 msvc tr1_is_pod_test: cw-9_4 msvc tr1_is_pointer_test: cw-9_4 msvc tr1_is_polymorphic_test: cw-9_4 msvc tr1_is_reference_test: cw-9_4 msvc tr1_is_same_test: cw-9_4 msvc tr1_is_scalar_test: cw-9_4 msvc tr1_is_signed_test: cw-9_4 msvc tr1_is_union_test: cw-9_4 msvc tr1_is_unsigned_test: cw-9_4 tr1_is_void_test: cw-9_4 msvc tr1_is_volatile_test: cw-9_4 msvc tr1_rank_test: cw-9_4 tr1_remove_all_extents_test: cw-9_4 tr1_remove_const_test: cw-9_4 tr1_remove_cv_test: cw-9_4 tr1_remove_extent_test: cw-9_4 tr1_remove_pointer_test: cw-9_4 tr1_remove_reference_test: cw-9_4 tr1_remove_volatile_test: cw-9_4 tr1_tricky_abstract_type_test: cw-9_4 msvc tr1_tricky_add_pointer_test: cw-9_4 msvc tr1_tricky_function_type_test: cw-9_4 msvc tr1_tricky_incomplete_type_test: cw-9_4 msvc tr1_tricky_is_enum_test: cw-9_4 tr1_tricky_partial_spec_test: cw-9_4 msvc |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 cw-9_4 modifiers_native: cw-9_4 cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |wave| testwave: cw-9_4 vc-7_1 testwave_dll: cw-9_4 vc-7_1 |xpressive| misc1: cw-9_4 test1: cw-9_4 test1u: cw-9_4 test2: cw-9_4 test2u: cw-9_4 test3: cw-9_4 test3u: cw-9_4 test4: cw-9_4 test4u: cw-9_4 test5: cw-9_4 test5u: cw-9_4 test6: cw-9_4 test6u: cw-9_4 test7: cw-9_4 test7u: cw-9_4 test8: cw-9_4 test8u: cw-9_4 test9: cw-9_4 test9u: cw-9_4 test_cycles: cw-9_4 test_dynamic: cw-9_4 test_non_char: cw-9_4 test_regex_primitives: cw-9_4 test_static: cw-9_4
Does cw-9_4 really support partial specialization of class templates? According to boost.config it does. xpressive's tests are failing on this compiler, with heaps of errors like: ### mwcc Compiler: # In: ..\boost\xpressive\detail\static\productions\independent_compiler.hpp # From: ..\libs\xpressive\test\misc1.cpp # ----------------------------------------- # 128: : transform_compiler<arg_transform, xpressive::detail::seq_tag> # Error: ^ # illegal partial specialization The code it's complaining about looks like: template<typename OpTag> struct compiler<OpTag, xpressive::detail::ind_tag> : transform_compiler<arg_transform, xpressive::detail::seq_tag> { }; This looks unremarkable to me. What is CodeWarrior complaining about? Any and all insights are most welcome. -- Eric Niebler Boost Consulting www.boost-consulting.com
Resending ... I figured I'd give this one last try before marking xpressive unusable on MetroWerks. Any clues? Eric Niebler wrote:
Does cw-9_4 really support partial specialization of class templates? According to boost.config it does. xpressive's tests are failing on this compiler, with heaps of errors like:
### mwcc Compiler: # In: ..\boost\xpressive\detail\static\productions\independent_compiler.hpp # From: ..\libs\xpressive\test\misc1.cpp # ----------------------------------------- # 128: : transform_compiler<arg_transform, xpressive::detail::seq_tag> # Error: ^ # illegal partial specialization
The code it's complaining about looks like:
template<typename OpTag> struct compiler<OpTag, xpressive::detail::ind_tag> : transform_compiler<arg_transform, xpressive::detail::seq_tag> { };
This looks unremarkable to me. What is CodeWarrior complaining about?
-- Eric Niebler Boost Consulting www.boost-consulting.com
On Dec 7, 2005, at 12:02 PM, Eric Niebler wrote:
Resending ... I figured I'd give this one last try before marking xpressive unusable on MetroWerks. Any clues?
Eric Niebler wrote:
Does cw-9_4 really support partial specialization of class templates? According to boost.config it does. xpressive's tests are failing on this compiler, with heaps of errors like:
### mwcc Compiler: # In: ..\boost\xpressive\detail\static\productions\independent_compiler.hpp # From: ..\libs\xpressive\test\misc1.cpp # ----------------------------------------- # 128: : transform_compiler<arg_transform, xpressive::detail::seq_tag> # Error: ^ # illegal partial specialization
I get similar problems from CW 9.6 just syntax checking independent_compiler.hpp. I see two ways around it, both less than desirable. 1) add the missing default template argument to the compiler specialization template<bool PositiveT> struct compiler<xpressive::detail::lookahead_tag<PositiveT>, xpressive::detail::seq_tag, void> : branch_compiler<xpressive::detail::lookahead_branch<PositiveT>, xpressive::detail::ind_tag> { }; 2) fully specialize for the bool argument template<> struct compiler<xpressive::detail::lookahead_tag<true>, xpressive::detail::seq_tag, void> : branch_compiler<xpressive::detail::lookahead_branch<true>, xpressive::detail::ind_tag> { }; template<> struct compiler<xpressive::detail::lookahead_tag<false>, xpressive::detail::seq_tag, void> : branch_compiler<xpressive::detail::lookahead_branch<false>, xpressive::detail::ind_tag> { }; I know there are several outstanding template specialization bugs in 9.6. Metrowerks suggested I upgrade to the last Mac release 10.0. Not sure if these problems would be fixed though. -- Noel
Noel Belcourt wrote:
Eric Niebler wrote:
Does cw-9_4 really support partial specialization of class templates? According to boost.config it does. xpressive's tests are failing on this compiler, with heaps of errors like:
### mwcc Compiler: # In: ..\boost\xpressive\detail\static\productions\independent_compiler.hpp # From: ..\libs\xpressive\test\misc1.cpp # ----------------------------------------- # 128: : transform_compiler<arg_transform, xpressive::detail::seq_tag> # Error: ^ # illegal partial specialization
1) add the missing default template argument to the compiler specialization
template<bool PositiveT> struct compiler<xpressive::detail::lookahead_tag<PositiveT>, xpressive::detail::seq_tag, void> : branch_compiler<xpressive::detail::lookahead_branch<PositiveT>, xpressive::detail::ind_tag> { };
Ah, interesting. Thanks for the suggestion -- I've committed the fix. Let's see what the next round of regression tests reveal. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Noel Belcourt wrote:
1) add the missing default template argument to the compiler specialization
template<bool PositiveT> struct compiler<xpressive::detail::lookahead_tag<PositiveT>, xpressive::detail::seq_tag, void> : branch_compiler<xpressive::detail::lookahead_branch<PositiveT>, xpressive::detail::ind_tag> { };
Ah, interesting. Thanks for the suggestion -- I've committed the fix. Let's see what the next round of regression tests reveal.
Thanks for your suggestion, Noel. Now, all of xpressive tests are compiling successfully on cw-9_4. That's the good news. The bad news is they all crash at runtime. :-P This is the (unhelpful) error: minimal.hpp(122): exception "memory access violation" caught in function: 'main(int, char **)' If someone with cw-9_4 felt like being charitable this holiday season, they could run xpressive's "test_static" and/or "test_dynamic" tests under a debugger and send me the stack trace. Or grant me ssh access to a machine with this toolset so I can debug it myself. -- Eric Niebler Boost Consulting www.boost-consulting.com
On Dec 12, 2005, at 3:43 PM, Eric Niebler wrote:
Eric Niebler wrote:
Noel Belcourt wrote:
1) add the missing default template argument to the compiler specialization
template<bool PositiveT> struct compiler<xpressive::detail::lookahead_tag<PositiveT>, xpressive::detail::seq_tag, void> : branch_compiler<xpressive::detail::lookahead_branch<PositiveT>, xpressive::detail::ind_tag> { };
Ah, interesting. Thanks for the suggestion -- I've committed the fix. Let's see what the next round of regression tests reveal.
Thanks for your suggestion, Noel. Now, all of xpressive tests are compiling successfully on cw-9_4. That's the good news. The bad news is they all crash at runtime. :-P This is the (unhelpful) error:
minimal.hpp(122): exception "memory access violation" caught in function: 'main(int, char **)'
If someone with cw-9_4 felt like being charitable this holiday season, they could run xpressive's "test_static" and/or "test_dynamic" tests under a debugger and send me the stack trace. Or grant me ssh access to a machine with this toolset so I can debug it myself.
I can assist if it's okay to use CW 9.6? -- Noel
Noel Belcourt wrote:
If someone with cw-9_4 felt like being charitable this holiday season, they could run xpressive's "test_static" and/or "test_dynamic" tests under a debugger and send me the stack trace. Or grant me ssh access to a machine with this toolset so I can debug it myself.
I can assist if it's okay to use CW 9.6?
That's a generous offer, and the results will be interesting, but I suspect the problem won't expose itself with 9.6, since the test_static test passed with cw-9_5 even before my fixes. I'm guessing this is a cw-9_4-specific problem, but I can't say for sure at this point. -- Eric Niebler Boost Consulting www.boost-consulting.com
On Dec 12, 2005, at 5:53 PM, Eric Niebler wrote:
Noel Belcourt wrote:
If someone with cw-9_4 felt like being charitable this holiday season, they could run xpressive's "test_static" and/or "test_dynamic" tests under a debugger and send me the stack trace. Or grant me ssh access to a machine with this toolset so I can debug it myself.
I can assist if it's okay to use CW 9.6?
That's a generous offer, and the results will be interesting, but I suspect the problem won't expose itself with 9.6, since the test_static test passed with cw-9_5 even before my fixes. I'm guessing this is a cw-9_4-specific problem, but I can't say for sure at this point.
There is a problem compiling Xpressive's test_static and test_dynamic with CW 9.6. The error is in test/impl/execution_monitor.ipp, lines 86-88. # include <unistd.h> # include <signal.h> # include <setjmp.h> These include files are defined in CW's standard library (MSL) and they hide the ones in /usr/include. The MSL doesn't seem to define the full (or maybe the correct) set of signal handling functions and structures. Xpressive's test_static and test_dynamic compile and run without error if I change the includes to # include </usr/include/unistd.h> # include </usr/include/signal.h> # include </usr/include/setjmp.h> Can anyone suggest a workaround for this? -- Noel
Resending with a more appropriate subject .... Noel Belcourt wrote:
There is a problem compiling Xpressive's test_static and test_dynamic with CW 9.6. The error is in test/impl/execution_monitor.ipp, lines 86-88.
# include <unistd.h> # include <signal.h> # include <setjmp.h>
These include files are defined in CW's standard library (MSL) and they hide the ones in /usr/include. The MSL doesn't seem to define the full (or maybe the correct) set of signal handling functions and structures.
Xpressive's test_static and test_dynamic compile and run without error if I change the includes to
# include </usr/include/unistd.h> # include </usr/include/signal.h> # include </usr/include/setjmp.h>
Can anyone suggest a workaround for this?
-- Noel
There is a problem compiling Xpressive's test_static and test_dynamic with CW 9.6. The error is in test/impl/execution_monitor.ipp, lines 86-88.
# include <unistd.h> # include <signal.h> # include <setjmp.h>
These include files are defined in CW's standard library (MSL) and they hide the ones in /usr/include. The MSL doesn't seem to define the full (or maybe the correct) set of signal handling functions and structures.
Xpressive's test_static and test_dynamic compile and run without error if I change the includes to
# include </usr/include/unistd.h> # include </usr/include/signal.h> # include </usr/include/setjmp.h>
Can anyone suggest a workaround for this?
I don't think it's really Boost.Test problem. But if you have any specific patch I may consider it. Gennadiy
Gennadiy Rozental wrote:
The error is in test/impl/execution_monitor.ipp, lines 86-88.
# include <unistd.h> # include <signal.h> # include <setjmp.h>
These include files are defined in CW's standard library (MSL) and they hide the ones in /usr/include. The MSL doesn't seem to define the full (or maybe the correct) set of signal handling functions and structures.
Xpressive's test_static and test_dynamic compile and run without error if I change the includes to
# include </usr/include/unistd.h> # include </usr/include/signal.h> # include </usr/include/setjmp.h>
Can anyone suggest a workaround for this?
I don't think it's really Boost.Test problem. But if you have any specific patch I may consider it.
Clearly, the problem here is in Metrowerks' standard library, but Boost.Test needs a work-around. The fact that changing a Boost.Test header file makes xpressive's tests pass seems to prove it. I don't know what the work-around is, and I don't have the platform, so I can't submit a patch. Sorry. But it might be as simple as something like: #if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3206)) # include </usr/include/unistd.h> # include </usr/include/signal.h> # include </usr/include/setjmp.h> #else # include <unistd.h> # include <signal.h> # include <setjmp.h> #endif HTH, -- Eric Niebler Boost Consulting www.boost-consulting.com
Clearly, the problem here is in Metrowerks' standard library, but Boost.Test needs a work-around. The fact that changing a Boost.Test header file makes xpressive's tests pass seems to prove it. I don't know what the work-around is, and I don't have the platform, so I can't submit a patch. Sorry. But it might be as simple as something like:
#if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3206)) # include </usr/include/unistd.h> # include </usr/include/signal.h> # include </usr/include/setjmp.h> #else # include <unistd.h> # include <signal.h> # include <setjmp.h> #endif
Which platforms Metrowerks supply it's compiler for? Does it work on NT or Mac? Gennadiy
On Dec 15, 2005, at 4:54 PM, Gennadiy Rozental wrote:
Clearly, the problem here is in Metrowerks' standard library, but Boost.Test needs a work-around. The fact that changing a Boost.Test header file makes xpressive's tests pass seems to prove it. I don't know what the work-around is, and I don't have the platform, so I can't submit a patch. Sorry. But it might be as simple as something like:
#if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3206))
CW 9.6 defines __MWERKS__ as 0x3207.
Which platforms Metrowerks supply it's compiler for? Does it work on NT or Mac?
Mac certainly, not sure about NT. -- Noel
Gennadiy Rozental wrote:
Clearly, the problem here is in Metrowerks' standard library, but Boost.Test needs a work-around. The fact that changing a Boost.Test header file makes xpressive's tests pass seems to prove it. I don't know what the work-around is, and I don't have the platform, so I can't submit a patch. Sorry. But it might be as simple as something like:
#if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3206)) # include </usr/include/unistd.h> # include </usr/include/signal.h> # include </usr/include/setjmp.h> #else # include <unistd.h> # include <signal.h> # include <setjmp.h> #endif
Which platforms Metrowerks supply it's compiler for? Does it work on NT or Mac?
Good question. I was under the impression it was an Mac thing, but a closer look at the regression results shows that's not the case. I guess my suggested work-around is not general enough. Ben Artin suggested earlier in the thread that the general work-around is: "Copy and paste the relevant bits of /usr/include headers into your own source code and curse CW. That is what everyone I know does upon encountering some variant of this problem." -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Resending with a more appropriate subject ....
Noel Belcourt wrote:
There is a problem compiling Xpressive's test_static and test_dynamic with CW 9.6. The error is in test/impl/execution_monitor.ipp, lines 86-88.
# include <unistd.h> # include <signal.h> # include <setjmp.h>
These include files are defined in CW's standard library (MSL) and they hide the ones in /usr/include. The MSL doesn't seem to define the full (or maybe the correct) set of signal handling functions and structures.
Xpressive's test_static and test_dynamic compile and run without error if I change the includes to
# include </usr/include/unistd.h> # include </usr/include/signal.h> # include </usr/include/setjmp.h>
Can anyone suggest a workaround for this?
-- Noel
As an experiment, I have changed xpressive's regression test to not use Boost.Test. The results are perplexing. The runtime crash went away on cw-9_4 but remains on cw-9_5-darwin. I don't know about cw-9_6. It's possible that it has something to do with the fact that the 9.4 test is run on Win32 and the 9.5 test on Darwin. Is there is another header pulling in CW's buggy versions of unistd.h/signal.h/setjmp.h on this platform? Can someone with CodeWarrior/Mac (any version) sync boost/xpressive and libs/xpressive and try running xpressive's "test1"? A stack backtrace would shed some light. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (3)
-
Douglas Gregor -
Eric Niebler -
Gennadiy Rozental -
Noel Belcourt