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

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2006-10-11 16:08:52

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