pathscale 3.1 reporting problems?

[Steven Watanabe-4]

AMDG

According to http://tinyurl.com/nunary, the test library fail to build,
but following the
link, it appears that the test library did build correctly.  Any ideas?

In Christ,
Steven Watanabe

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Belcourt, Kenneth]

Hi Steven,

On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:

> According to http://tinyurl.com/nunary, the test library fail to  
> build,
> but following the
> link, it appears that the test library did build correctly.  Any  
> ideas?

I've rearranged the nightly trunk test order so pathscale-3.1 will  
build last, and hence I'll be able to look through the derived  
products and hopefully be able to tell what happened.

I'll try to get back to you tomorrow.

-- Noel


_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Belcourt, Kenneth]

Hi Steven,

On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:

> According to http://tinyurl.com/nunary, the test library fail to  
> build,
> but following the
> link, it appears that the test library did build correctly.  Any  
> ideas?

Well that's a strange problem.  This executable:

        bin.v2/libs/test/test/prg_exec_fail2.test/pathscale-3.1/debug/
prg_exec_fail2

is built and runs to completion, apparently without error.  But, as  
Steven points out, the test results reported in the trunk tests  
reports a failure.

I'm just guessing that this program somehow corrupts memory.  Does  
anyone know if this program manipulates the stack frame or expects a  
very large stack?  The reason I ask is this error message from  
valgrind, when running prg_exec_fail2, seems to show something funky  
with the stack (120 Mb stack change is pretty huge by most measures).

==31979== Warning: client switching stacks?  SP change: 0x623C430 -->  
0xFEFFC480
==31979==          to suppress, use: --max-stackframe=119799728 or  
greater

So doing as valgrind suggests and rerunning with --max-stackframe  
leads to an internal corruption in valgrind, as you can see here:

$ valgrind --max-stackframe=119799728 bin.v2/libs/test/test/
prg_exec_fail2.test/pathscale-3.1/debug/prg_exec_fail2

....

Memcheck: the 'impossible' happened:
    create_MAC_Chunk: shadow area is accessible
==32038==    at 0x700112DF: report_and_quit (m_libcassert.c:122)
==32038==    by 0x7001156D: panic (m_libcassert.c:195)
==32038==    by 0x7001161E: vgPlain_tool_panic (m_libcassert.c:210)
==32038==    by 0x70001380: create_MAC_Chunk (mac_malloc_wrappers.c:146)
==32038==    by 0x70001582: vgMAC_malloc (mac_malloc_wrappers.c:203)
==32038==    by 0x700376F0: do_client_request (scheduler.c:987)
==32038==    by 0x70037050: vgPlain_scheduler (scheduler.c:721)
==32038==    by 0x7004C9C9: thread_wrapper (syswrap-linux.c:86)
==32038==    by 0x7004CAF4: run_a_thread_NORETURN (syswrap-linux.c:119)

So it seems that either the pathscale compiler is generating bad  
code, or that this test is doing something funky that corrupts memory  
in the parent process (which, in our case, is either the build system  
that is running this test (prg_exec_fail2) or, as in this email,  
valgrind that is running this test). Either way, it seems that the  
parent process is getting hosed when running this program.  I'll need  
a little help (Gennadiy??) to understand what this is doing (I've  
copied Gennadiy on this reply).

-- Noel


_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Belcourt, Kenneth]

Hi Steven,

On Jun 16, 2009, at 2:40 PM, K. Noel Belcourt wrote:

> On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:
>
>> According to http://tinyurl.com/nunary, the test library fail to  
>> build,
>> but following the
>> link, it appears that the test library did build correctly.  Any  
>> ideas?
>
> Well that's a strange problem.  This executable:
>
> bin.v2/libs/test/test/prg_exec_fail2.test/pathscale-3.1/debug/
> prg_exec_fail2
>
> is built and runs to completion, apparently without error.  But, as  
> Steven points out, the test results reported in the trunk tests  
> reports a failure.
>
> I'm just guessing that this program somehow corrupts memory.  Does  
> anyone know if this program manipulates the stack frame or expects  
> a very large stack?  The reason I ask is this error message from  
> valgrind, when running prg_exec_fail2, seems to show something  
> funky with the stack (120 Mb stack change is pretty huge by most  
> measures).

Alright, I've learned a few things about Boost.test.

First, it doesn't recognize the Etnus' Totalview debugger so inside  
debug.ipp in the BOOST_UNIX_BASED_DEBUG macro block, only gdb is in  
the dbg_list, so this code can't be effectively debugged under  
Totalview (the Totalview program name is version specific, tv8main in  
our case).

Second, in execution_monitor.ipp, catch_signals(), it appears that we  
must disable macro BOOST_TEST_USE_ALT_STACK.  Can someone (Gennadiy?)  
please disable this macro (and all this alternate stack code) in the  
trunk when building for pathscale-3.1 to see if this fixes the problem?

And just a general question, is all this complexity (recognizing  
debuggers, managing alternate stacks, etc...) really necessary for a  
testing library?

-- Noel


_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Gennadiy Rozental-2]

K. Noel Belcourt <kbelco <at> sandia.gov> writes:

>
> Hi Steven,
>
> On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:
>
> > According to http://tinyurl.com/nunary, the test library fail to  
> > build,
> > but following the
> > link, it appears that the test library did build correctly.  Any  
> > ideas?
>
> Well that's a strange problem.  This executable:
>
> bin.v2/libs/test/test/prg_exec_fail2.test/pathscale-3.1/debug/
> prg_exec_fail2
>
> is built and runs to completion, apparently without error.  But, as  
> Steven points out, the test results reported in the trunk tests  
> reports a failure.

This test is expected to fail (it tests how Boost.Test handles division by zero)
and if it's not this is an error. That's all.

> So it seems that either the pathscale compiler is generating bad  
> code, or that this test is doing something funky that corrupts memory  

Where do you get indication that process corrupts memory?

HTH,

Gennadiy



_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Christopher Cambly]

>
> This test is expected to fail (it tests how Boost.Test handles
> division by zero)
> and if it's not this is an error. That's all.

FWIW I'm not a fan of this test.  xlC/PPC hardware does not trap on div.  We can fix it easy by adding an option to generate a trap and did so in Boost 1.34.1 but never bothered for the Boost development line.

Chris Cambly
XL C++ Compiler Development
>

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Gennadiy Rozental-2]

K.Noel Belcourt <kbelco <at> sandia.gov> writes:

> Alright, I've learned a few things about Boost.test.
>
> First, it doesn't recognize the Etnus' Totalview debugger so inside  
> debug.ipp in the BOOST_UNIX_BASED_DEBUG macro block, only gdb is in  
> the dbg_list, so this code can't be effectively debugged under  
> Totalview (the Totalview program name is version specific, tv8main in  
> our case).

How is it relevant to the problem at hand? Boost.Test debugger support is not
entered by this test.

> Second, in execution_monitor.ipp, catch_signals(), it appears that we  
> must disable macro BOOST_TEST_USE_ALT_STACK.  Can someone (Gennadiy?)  

Why?

> please disable this macro (and all this alternate stack code) in the  
> trunk when building for pathscale-3.1 to see if this fixes the problem?
>
> And just a general question, is all this complexity (recognizing  
> debuggers, managing alternate stacks, etc...) really necessary for a  
> testing library?

1. Boost.Test allows to automatically attach debuggers (trying to at least) at
the point of failure like memory access violation.

2. It's better to catch signals using altstack.

Gennadiy




_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Gennadiy Rozental-2]

Christopher Cambly <ccambly <at> ca.ibm.com> writes:

>
>
> >
> > This test is expected to fail (it tests how Boost.Test handles
> > division by zero)
> > and if it's not this is an error. That's all.FWIW I'm not a fan of this
test. >  xlC/PPC hardware does not trap on div.  We can fix it easy by adding an
option > to generate a trap and did so in Boost 1.34.1 but never bothered for
the Boost > development line.

Not sure I follow this comment. You changed compiler only for boost 1.34.1? Or
you changed toolset? Why not generate this trap always?

That said, division by zero is just another error condition Boost.Test is trying
to catch and properly report. If you opt not to generate it, you can always mark
this test as intentionally failing.

Gennadiy



_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Christopher Cambly]

> > >
> > > This test is expected to fail (it tests how Boost.Test handles
> > > division by zero)
> > > and if it's not this is an error. That's all.FWIW I'm not a fan of this
> test. >  xlC/PPC hardware does not trap on div.  We can fix it easy
> by adding an
> option > to generate a trap and did so in Boost 1.34.1 but never bothered for
> the Boost > development line.
>
> Not sure I follow this comment. You changed compiler only for boost 1.34.1? Or
> you changed toolset? Why not generate this trap always?
>
> That said, division by zero is just another error condition
> Boost.Test is trying
> to catch and properly report. If you opt not to generate it, you can
> always mark
> this test as intentionally failing.
>
This testcase appears to assume that all hardware will generate an exception on a divide by zero.  I believe that the PPC hardware itself does not raise an exception on a divide by zero.  The compiler can insert special code around the divide by zero to cause an exception similar to what is expected by this testcase but that is not the default of the hardware or the compiler.

In a patch that we provided for Boost 1.34.1 we added an option (-qflttrap=zerodivide) to the Jamfile that would generate the behaviour expected by this testcase.  However, the change was never propagated to the Boost development line which is why the test still fails for us.  Certainly, the test could be marked as a known failure but the underlying assumption of the test that all hardware/software will fail on a divide by zero is false.

The comment was nothing more than a comment about the test itself which has underlying assumptions that are invalid on certain platforms.

Chris Cambly
XL C++ Compiler Development



_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Gennadiy Rozental-2]

Christopher Cambly <ccambly <at> ca.ibm.com> writes:

> This testcase appears to assume that all hardware will
> generate an exception on a divide by zero.  I believe
> that the PPC hardware itself does not raise an exception
> on a divide by zero.

What does it do in case of integer being divided by zero?

> The compiler can insert special code around the divide by
> zero to cause an exception similar to what is expected by
> this testcase but that is not the default of the hardware
> or the compiler.In a patch that we provided for Boost
> 1.34.1 we added an option (-qflttrap=zerodivide) to the
> Jamfile that would generate the behaviour expected by this
> testcase.  

Note that the test case has nothing to do with floating points.

> However, the change was never propagated to the Boost
> development line which is why the test still fails for us.

Would you like me to add this to Jamfile? can you post patch again?

>  Certainly, the test could be marked as a known failure
> but the underlying assumption of the test that all
> hardware/software will fail on a divide by zero is false.

This is incorrect statement. Test does not have these underlying
assumptions. The module just tests that Boost.Test is able to catch and properly
report an exception in case it's actually being generated.
Overall the test is expected to fail in this case. We can mark the test as
expected to pass in particular configuration.

Gennadiy

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Christopher Cambly]

>
> Note that the test case has nothing to do with floating points.
>
My bad.  The option for integers is -qcheck=divzero.

>
> Would you like me to add this to Jamfile? can you post patch again?
>

We were going to submit batch new patches soon so it will included as part of those.

>
> This is incorrect statement. Test does not have these underlying
> assumptions. The module just tests that Boost.Test is able to catch
> and properly
> report an exception in case it's actually being generated.
> Overall the test is expected to fail in this case. We can mark the test as
> expected to pass in particular configuration.
>
I understand but the test implies that a divide by zero will generate a system exception for Boost.Test. The conditional code in the cpp_main for Apple PPC just returns 1 instead of doing the actual divide by zero.  The patch we supply can either do the same or we can add the option (-qcheck=divzero) for this particular test so that we will generate the system exception.  The latter seems best since it actually tests the ability of Boost.Test to catch system exceptions on PPC platforms.  

Either one is a fairly simple change.

Chris Cambly
XL C++ Compiler Development

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Belcourt, Kenneth]

Hi,

Another try at diagnosing this problem (please disregard my previous  
postings on this subject).

On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:

> According to http://tinyurl.com/nunary, the test library fail to  
> build,
> but following the
> link, it appears that the test library did build correctly.

It seems that the pathscale-3.1 tuple another_tuple_test_bench test  
failed to link for a lack of libboost_test_exec_monitor-31-d-1_40.a,  
which itself failed to build because unit_test_main.o failed to compile.

So there's two issues here.  First, I could use a little help  
figuring out why unit_test_main.o fails to compile for  
pathscale-3.1.  The second issue is parsing the nightly bjam.log  
output from the pathscale-3.1 toolset seems to be rather messed up,  
though not sure why at the moment (the parsing seems to work better  
with pathscale-3.2).

Here's the compilation failure of unit_test_main.o.

     "/usr/local/pathscale-3.1/bin/pathCC" -noinline -g -Wall -
DBOOST_ALL_NO_LIB=1 -I".." -c -o "/var/scratch/boost/results/boost/
bin.v2/libs/test/build/pathscale-3.1/debug/link-static/
unit_test_main.o" "../libs/test/src/unit_test_main.cpp"

In file included from ../boost/test/utils/iterator/token_iterator.hpp:
27,
                  from ../boost/test/impl/unit_test_main.ipp:27,
                  from ../libs/test/src/unit_test_main.cpp:16:
../boost/test/utils/named_params.hpp: In member function `ReferenceType
    boost::nfp::named_parameter<T, unique_id,
    RefType>::operator[](boost::nfp::keyword<unique_id, true>) const':
../boost/test/utils/named_params.hpp:190: error: syntax error before  
`;' token

-- Noel


_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Steven Watanabe-4]

AMDG

K. Noel Belcourt wrote:

> Another try at diagnosing this problem (please disregard my previous
> postings on this subject).
>
> On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:
>
>> According to http://tinyurl.com/nunary, the test library fail to build,
>> but following the
>> link, it appears that the test library did build correctly.
>
> It seems that the pathscale-3.1 tuple another_tuple_test_bench test
> failed to link for a lack of libboost_test_exec_monitor-31-d-1_40.a,
> which itself failed to build because unit_test_main.o failed to compile.
>
> So there's two issues here.  First, I could use a little help figuring
> out why unit_test_main.o fails to compile for pathscale-3.1.  The
> second issue is parsing the nightly bjam.log output from the
> pathscale-3.1 toolset seems to be rather messed up, though not sure
> why at the moment (the parsing seems to work better with pathscale-3.2).
>
> Here's the compilation failure of unit_test_main.o.
>
>     "/usr/local/pathscale-3.1/bin/pathCC" -noinline -g -Wall
> -DBOOST_ALL_NO_LIB=1 -I".." -c -o
> "/var/scratch/boost/results/boost/bin.v2/libs/test/build/pathscale-3.1/debug/link-static/unit_test_main.o"
> "../libs/test/src/unit_test_main.cpp"
>
> In file included from ../boost/test/utils/iterator/token_iterator.hpp:27,
>                  from ../boost/test/impl/unit_test_main.ipp:27,
>                  from ../libs/test/src/unit_test_main.cpp:16:
> ../boost/test/utils/named_params.hpp: In member function `ReferenceType
>    boost::nfp::named_parameter<T, unique_id,
>    RefType>::operator[](boost::nfp::keyword<unique_id, true>) const':
> ../boost/test/utils/named_params.hpp:190: error: syntax error before
> `;' token

gcc-open64 seems to be having exactly the same problem.

The offending line is
    ref_type        operator[]( keyword<unique_id,true> ) const     {
return m_erased ? nil_t::inst().any_cast<ref_type>() :  m_value; }

What happens if you change it to
ref_type        operator[]( keyword<unique_id,true> ) const     {
    if(m_erased) {
        return nil_t::inst().any_cast<ref_type>();
    } else {
        return m_value;
    }
}

In Christ,
Steven Watanabe

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Belcourt, Kenneth]

On Jun 23, 2009, at 2:43 PM, Steven Watanabe wrote:

> AMDG
>
> K. Noel Belcourt wrote:
>> Another try at diagnosing this problem (please disregard my previous
>> postings on this subject).
>>
>> On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:
>>
>>> According to http://tinyurl.com/nunary, the test library fail to  
>>> build,
>>> but following the
>>> link, it appears that the test library did build correctly.
>>
>> It seems that the pathscale-3.1 tuple another_tuple_test_bench test
>> failed to link for a lack of libboost_test_exec_monitor-31-d-1_40.a,
>> which itself failed to build because unit_test_main.o failed to  
>> compile.
>>
>> So there's two issues here.  First, I could use a little help  
>> figuring
>> out why unit_test_main.o fails to compile for pathscale-3.1.  The
>> second issue is parsing the nightly bjam.log output from the
>> pathscale-3.1 toolset seems to be rather messed up, though not sure
>> why at the moment (the parsing seems to work better with  
>> pathscale-3.2).
>>
>> Here's the compilation failure of unit_test_main.o.
>>
>>     "/usr/local/pathscale-3.1/bin/pathCC" -noinline -g -Wall
>> -DBOOST_ALL_NO_LIB=1 -I".." -c -o
>> "/var/scratch/boost/results/boost/bin.v2/libs/test/build/
>> pathscale-3.1/debug/link-static/unit_test_main.o"
>> "../libs/test/src/unit_test_main.cpp"
>>
>> In file included from ../boost/test/utils/iterator/
>> token_iterator.hpp:27,
>>                  from ../boost/test/impl/unit_test_main.ipp:27,
>>                  from ../libs/test/src/unit_test_main.cpp:16:
>> ../boost/test/utils/named_params.hpp: In member function  
>> `ReferenceType
>>    boost::nfp::named_parameter<T, unique_id,
>>    RefType>::operator[](boost::nfp::keyword<unique_id, true>) const':
>> ../boost/test/utils/named_params.hpp:190: error: syntax error before
>> `;' token
>
> gcc-open64 seems to be having exactly the same problem.
>
> The offending line is
>     ref_type        operator[]( keyword<unique_id,true> ) const     {
> return m_erased ? nil_t::inst().any_cast<ref_type>() :  m_value; }
>
> What happens if you change it to
> ref_type        operator[]( keyword<unique_id,true> ) const     {
>     if(m_erased) {
>         return nil_t::inst().any_cast<ref_type>();
>     } else {
>         return m_value;
>     }
> }

Same error on the any_cast line.

In file included from ../boost/test/utils/iterator/token_iterator.hpp:
27,
                  from ../boost/test/impl/unit_test_main.ipp:27,
                  from ../libs/test/src/unit_test_main.cpp:16:
../boost/test/utils/named_params.hpp: In member function `ReferenceType
    boost::nfp::named_parameter<T, unique_id,
    RefType>::operator[](boost::nfp::keyword<unique_id, true>) const':
../boost/test/utils/named_params.hpp:192: error: syntax error before  
`;' token

[ named_params.hpp ]

     ref_type        operator[]( keyword<unique_id,true> ) const     {
       if(m_erased) {
         return nil_t::inst().any_cast<ref_type>();    // line 192
       } else {
         return m_value;
       }
     }

-- Noel


_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Belcourt, Kenneth]

On Jun 23, 2009, at 2:49 PM, K. Noel Belcourt wrote:

> On Jun 23, 2009, at 2:43 PM, Steven Watanabe wrote:
>
>> K. Noel Belcourt wrote:
>>> Another try at diagnosing this problem (please disregard my previous
>>> postings on this subject).
>>>
>>> On Jun 13, 2009, at 12:02 PM, Steven Watanabe wrote:
>>>
>>>> According to http://tinyurl.com/nunary, the test library fail to
>>>> build,
>>>> but following the
>>>> link, it appears that the test library did build correctly.
>>>
>>> It seems that the pathscale-3.1 tuple another_tuple_test_bench test
>>> failed to link for a lack of libboost_test_exec_monitor-31-d-1_40.a,
>>> which itself failed to build because unit_test_main.o failed to
>>> compile.
>>>
>>> So there's two issues here.  First, I could use a little help
>>> figuring
>>> out why unit_test_main.o fails to compile for pathscale-3.1.  The
>>> second issue is parsing the nightly bjam.log output from the
>>> pathscale-3.1 toolset seems to be rather messed up, though not sure
>>> why at the moment (the parsing seems to work better with
>>> pathscale-3.2).
>>>
>>> Here's the compilation failure of unit_test_main.o.
>>>
>>>     "/usr/local/pathscale-3.1/bin/pathCC" -noinline -g -Wall
>>> -DBOOST_ALL_NO_LIB=1 -I".." -c -o
>>> "/var/scratch/boost/results/boost/bin.v2/libs/test/build/
>>> pathscale-3.1/debug/link-static/unit_test_main.o"
>>> "../libs/test/src/unit_test_main.cpp"
>>>
>>> In file included from ../boost/test/utils/iterator/
>>> token_iterator.hpp:27,
>>>                  from ../boost/test/impl/unit_test_main.ipp:27,
>>>                  from ../libs/test/src/unit_test_main.cpp:16:
>>> ../boost/test/utils/named_params.hpp: In member function
>>> `ReferenceType
>>>    boost::nfp::named_parameter<T, unique_id,
>>>    RefType>::operator[](boost::nfp::keyword<unique_id, true>)  
>>> const':
>>> ../boost/test/utils/named_params.hpp:190: error: syntax error before
>>> `;' token
>>
>> gcc-open64 seems to be having exactly the same problem.
>>
>> The offending line is
>>     ref_type        operator[]( keyword<unique_id,true> ) const     {
>> return m_erased ? nil_t::inst().any_cast<ref_type>() :  m_value; }
>>
>> What happens if you change it to
>> ref_type        operator[]( keyword<unique_id,true> ) const     {
>>     if(m_erased) {
>>         return nil_t::inst().any_cast<ref_type>();
>>     } else {
>>         return m_value;
>>     }
>> }
>
> Same error on the any_cast line.
>
> In file included from ../boost/test/utils/iterator/token_iterator.hpp:
> 27,
>                   from ../boost/test/impl/unit_test_main.ipp:27,
>                   from ../libs/test/src/unit_test_main.cpp:16:
> ../boost/test/utils/named_params.hpp: In member function  
> `ReferenceType
>     boost::nfp::named_parameter<T, unique_id,
>     RefType>::operator[](boost::nfp::keyword<unique_id, true>) const':
> ../boost/test/utils/named_params.hpp:192: error: syntax error before
> `;' token
>
> [ named_params.hpp ]
>
>      ref_type        operator[]( keyword<unique_id,true> ) const     {
>        if(m_erased) {
>          return nil_t::inst().any_cast<ref_type>();    // line 192
>        } else {
>          return m_value;
>        }
>      }

So this seems to fix the problem (and the same patch is needed for  
the operator[] (keyword<unique_id,false>) const overload right below  
this.

     ref_type        operator[]( keyword<unique_id,true> ) {
       if(m_erased) {
         return nil_t::inst().template any_cast<ref_type>();
       } else {
         return m_value;
       }
     }

Is this enough information for someone to code up and submit a patch  
for trunk?

-- Noel


_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Gennadiy Rozental-2]

K. Noel Belcourt wrote:

> So this seems to fix the problem (and the same patch is needed for the
> operator[] (keyword<unique_id,false>) const overload right below this.
>
>     ref_type        operator[]( keyword<unique_id,true> ) {
>       if(m_erased) {
>         return nil_t::inst().template any_cast<ref_type>();
>       } else {
>         return m_value;
>       }
>     }
>
> Is this enough information for someone to code up and submit a patch for
> trunk?

Why does the template is required here? nil is non-template structure.
Many other compilers do not have a problems with this.

How can I test with this compiler?

Gennadiy
_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Steven Watanabe-4]

AMDG

Gennadiy Rozental wrote:

> K. Noel Belcourt wrote:
>> So this seems to fix the problem (and the same patch is needed for
>> the operator[] (keyword<unique_id,false>) const overload right below
>> this.
>>
>>     ref_type        operator[]( keyword<unique_id,true> ) {
>>       if(m_erased) {
>>         return nil_t::inst().template any_cast<ref_type>();
>>       } else {
>>         return m_value;
>>       }
>>     }
>>
>> Is this enough information for someone to code up and submit a patch
>> for trunk?
>
> Why does the template is required here? nil is non-template structure.
> Many other compilers do not have a problems with this.
>
> How can I test with this compiler?

It appears to be a gcc 3.3 specific problem.

In Christ,
Steven Watanabe

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Gennadiy Rozental-2]

Steven Watanabe <watanabesj <at> gmail.com> writes:

> It appears to be a gcc 3.3 specific problem.

What is pathscale then? Any chance to upgrade to later version of gcc?

How ifdef check should look like?

Gennadiy

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Steven Watanabe-4]

AMDG

Gennadiy Rozental wrote:
> Steven Watanabe <watanabesj <at> gmail.com> writes:
>
>  
>> It appears to be a gcc 3.3 specific problem.
>>    
>
> What is pathscale then? Any chance to upgrade to later version of gcc?
>  

I'm going by the info provided.
QLogic PathScale(TM) Compiler Suite: Version 3.1 PathScale(TM) Compiler
Suite: Version 3.1
Built on: 2007-10-31 19:11:13 -0700 Thread model: posix GNU gcc version
3.3.1 (PathScale 3.1 driver)

Pathscale 3.2 seems to be okay, since it's using gcc 4.2.

> How ifdef check should look like?
>  

According to 14.2, using ::template is legal but not
required for non-dependent names, so you shouldn't
need a #ifdef.

In Christ,
Steven Watanabe

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Gennadiy Rozental-2]

Steven Watanabe <watanabesj <at> gmail.com> writes:

> According to 14.2, using ::template is legal but not
> required for non-dependent names, so you shouldn't
> need a #ifdef.

can you check in a fix then?

Gennadiy

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing