Re: [Boost-testing] pathscale 3.1 reporting problems?

Subject: Re: [Boost-testing] pathscale 3.1 reporting problems?
From: K. Noel Belcourt (kbelco_at_[hidden])
Date: 2009-06-23 17:39:49

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