[ptr_container] request to make ptr_map expected failure on HP-UX/aCC
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? For now, because of this test, on metacomm test site, the ptr_container library appears as broken on HP-UX/aCC. 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. If nobody knows or remembers what the bug is, we'll investigate. Thanks, Boris Gubenko HP C++ team
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
Thorsten Ottosen wrote:
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.
Such code is ill-formed. No compiler is required to accept it.
Thorsten Ottosen wrote:
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.
Such code is ill-formed. No compiler is required to accept it. There are often area's where the standard says it is not required or undefined yet a majority of vendors DO allow it as is the case here I believe. In effect it becomes a de-facto but unofficial standard. Remember we as
Peter Dimov wrote: programmers tend to be lazy, if it works on most compilers we tend to expect it to work on all of them.
Peter Dimov wrote:
Thorsten Ottosen wrote:
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.
Such code is ill-formed. No compiler is required to accept it.
Ok. I guess I can add operator&() for the proxy returned by *iter; Or is that ill-formed too? -Thorsten
Thorsten Ottosen wrote:
Peter Dimov wrote:
Thorsten Ottosen wrote:
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.
Such code is ill-formed. No compiler is required to accept it.
Ok.
I guess I can add operator&() for the proxy returned by *iter;
Since your iterator doesn't return a true reference, I don't see what is gained by allowing & on it. Most people that use &*i do that to obtain a real pointer to the element (Container::value_type*), not a Container::pointer. Nobody is quite sure what Container::pointer is supposed to represent; the standard containers use it as an alias for Allocator::pointer.
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@dezide.com> To: <boost@lists.boost.org> 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
Boris Gubenko wrote:
Thorsten Ottosen wrote:
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.
Ok, then I should probably not change the markup for the cvs head. Since Peter pointed out the code is illegal, I have simply removed it from the test. -Thorsten
Thorsten Ottosen wrote:
Since Peter pointed out the code is illegal, I have simply removed it from the test.
Thanks! -boris ----- Original Message ----- From: "Thorsten Ottosen" <thorsten.ottosen@dezide.com> To: <boost@lists.boost.org> Sent: Thursday, October 12, 2006 12:59 PM Subject: Re: [boost] [ptr_container] request to make ptr_map expected failure on HP-UX/aCC
Boris Gubenko wrote:
Thorsten Ottosen wrote:
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.
Ok, then I should probably not change the markup for the cvs head.
Since Peter pointed out the code is illegal, I have simply removed it from the test.
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Boris Gubenko -
Peter Dimov -
Richard Day -
Thorsten Ottosen