Re: [boost] [ptr_container] request to make ptr_map expected failure on HP-UX/aCC

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2006-10-11 23:13:23

Thorsten Ottosen wrote:
> Boris Gubenko wrote:
>> Based on the above, can "acc" be added to the list of toolsets for
>> this test, in both CVS head and the RC branch?
>
> I can't see acc on the list. Neither do I know how to add it.
>

Here is the patch for explicit-failures-markup.xml for CVS HEAD:

Index: explicit-failures-markup.xml
===================================================================
RCS file: /cvsroot/boost/boost/status/explicit-failures-markup.xml,v
retrieving revision 1.496
diff -r1.496 explicit-failures-markup.xml
3218a3219
>             <toolset name="acc"/>

>
> Broken seems like a very severe word for a rather insignificant test
> that fails.

I don't know how "broken" is being determined by test results
processing tools. I guess, it depends on the percentage of failing
tests for a library. Just a guess.

> [...] if you
> send a patch with the macro that disable the line(s) in question, I
> can
> apply it and remove the expected failure.

Here's the patch for ptr_map.cpp for CVS HEAD:

Index: ptr_map.cpp
===================================================================
RCS file: /cvsroot/boost/boost/libs/ptr_container/test/ptr_map.cpp,v
retrieving revision 1.17
diff -r1.17 ptr_map.cpp
327a328
> #ifndef __EDG__
330a332
> #endif

You can either apply the patch for explicit-failures-markup.xml thus
making the test explicit failure on HP-UX, or you can apply the patch
for ptr_map.cpp thus fixing the test. Note, however, that while patched
ptr_map.cpp compiles on HP-UX with both CVS HEAD and the RC branch, on
Tru64, it compiles only with RC branch: with CVS HEAD, there are
additional compilation errors coming from
boost/detail/lcast_precision.hpp. The errors do not appear to be
specific to ptr_map.cpp test.

Whatever patch you choose to apply, please, do it for both CVS HEAD and
1.34 branch, if only possible.

Thanks,
  Boris

----- Original Message ----- 
From: "Thorsten Ottosen" <thorsten.ottosen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, October 11, 2006 4:08 PM
Subject: Re: [boost] [ptr_container] request to make ptr_map expected 
failure on HP-UX/aCC

> Hi Boris,
>
> Boris Gubenko wrote:
>> On both Tru64/cxx and HP-UX/aCC, the only failing ptr_container
>> library test is ptr_map. On both platforms, it fails to compile
>> with the same compilation errors:
>>
>> "../libs/ptr_container/test/ptr_map.cpp", line 328: error #2158:
>>  expression must be an lvalue or a function designator
>>       map_type::pointer          a_pointer    = &*m2.begin();
>>
>> "../libs/ptr_container/test/ptr_map.cpp", line 330: error #2158:
>>  expression must be an lvalue or a function designator
>>       map_type::const_pointer    a_cpointer   = &*const_begin(m2);
>>
>> In the explicit-failures-markup, ptr_map is marked as expected failure
>> for a number of toolsets including "hp_cxx-71_006_tru64". Based on the
>> above, can "acc" be added to the list of toolsets for this test, in
>> both CVS head and the RC branch?
>
> I can't see acc on the list. Neither do I know how to add it.
>
>> For now, because of this test, on
>> metacomm test site, the ptr_container library appears as broken on
>> HP-UX/aCC.
>
> I'm the one responsible for doing the markup. I'll be the first to
> admit that I could easily use more time on that, but time is
> not as plentyful as it used to be. So when a major number of test was
> failing for a particular compiler, I gave up trying to port the library.
>
> Broken seems like a very severe word for a rather insignificant test
> that fails. I don't know what our policy is regarding this, but if you
> send a patch with the macro that disable the line(s) in question, I can
> apply it and remove the expected failure.
>
>> The Note by Thorsten Ottosen associated with ptr_map states, that
>> "For hp, this compiler bug is insignificant.". What exactly the bug
>> is? We want to be sure, that EDG is aware of it.
>
> I wrote it was insignificant because it has very little relevance for
> most normal code.
>
>> If nobody knows or
>> remembers what the bug is, we'll investigate.
>
> I think the bug is that the compiler does not allow one to take the
> adress of a temporary object (an rvalue). Normal compilers usually give
> a warning about it, but compile it.
>
> -Thorsten
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>