[mpl][tru64cxx] set still failing
Hello again, Despite recent changes by Dave Abrahams, mpl::set is still failing in tru64cxx as shown in the last regression cycle: http://tinyurl.com/9qzuh (Dave's works weren't intended to tackle this issue anyway, so this comes as no surprise.) The reason for the regression lies in recent changes to the associated toolset jam setting strict_ansi mode compilation. The offending code is: BOOST_STATIC_CONSTANT(bool, value = ( sizeof( BOOST_MPL_AUX_OVERLOAD_CALL_IS_MASKED( Set , BOOST_MPL_AUX_STATIC_CAST(aux::type_wrapper<T>*, 0) ) ) == sizeof(aux::no_tag) ) ); and the error message goes like "NULL reference is not allowed". Digging deeper, I'm pretty sure the problem has to do with tru64cxx not accepting selected implementation of BOOST_MPL_AUX_PTR_TO_REF in boost/mpl/aux_/ptr_to_ref.hpp when the pointer passed is null. There are two alternative implementations of this macro: 1. (MSVC, EDG) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ *BOOST_MPL_AUX_STATIC_CAST(X*, 0) \ /**/ 2. (remaining compilers) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ aux::ptr_to_ref(BOOST_MPL_AUX_STATIC_CAST(X*, 0)) \ /**/ tru64cxx, which is EDG-based, uses #1; it used to work OK, but when strict_ansi mode was selected, the compiler didn't like #1 anymore. So my questions are: A. Is there any reason why EDG is forced to use implementation #1? The CVS history doesn't shed much light about this. B. If A is unavoidable, can we macro-detect strict ansi mode so as to divert EDG+strict_ansi to implementation #2? C. If B has negative answer, could we at least eliminate the null pointer in boost/mpl/aux_/ptr_to_ref.hpp (by using a dummy make_ptr function, perhaps)? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Despite recent changes by Dave Abrahams, mpl::set is still failing in tru64cxx as shown in the last regression cycle:
(Dave's works weren't intended to tackle this issue anyway, so this comes as no surprise.) The reason for the regression lies in recent changes to the associated toolset jam setting strict_ansi mode compilation.
Thanks for your help on the issue, Joaquin! [snip]
A. Is there any reason why EDG is forced to use implementation #1? The CVS history doesn't shed much light about this.
I'll try and switch the implementation and see what happens.
B. If A is unavoidable, can we macro-detect strict ansi mode so as to divert EDG+strict_ansi to implementation #2?
Yes, we can. In strict ansi mode, __STD_STRICT_ANSI or __STD_STRICT_ANSI_ERRORS is defined. In relaxed ansi mode, __STD_ANSI is defined.
C. If B has negative answer, could we at least eliminate the null pointer in boost/mpl/aux_/ptr_to_ref.hpp (by using a dummy make_ptr function, perhaps)?
Not needed if A works out well, I think.
Thank you,
Thank YOU! Markus
So my questions are:
[...] B. If A is unavoidable, can we macro-detect strict ansi mode so as to divert EDG+strict_ansi to implementation #2?
Yes, in strict_ansi mode, the compiler predefines __STD_STRICT_ANSI macro. Boris ----- Original Message ----- From: "Joaquín Mª López Muñoz" <joaquin@tid.es> To: <boost@lists.boost.org> Sent: Wednesday, June 22, 2005 6:30 AM Subject: [boost] [mpl][tru64cxx] set still failing Hello again, Despite recent changes by Dave Abrahams, mpl::set is still failing in tru64cxx as shown in the last regression cycle: http://tinyurl.com/9qzuh (Dave's works weren't intended to tackle this issue anyway, so this comes as no surprise.) The reason for the regression lies in recent changes to the associated toolset jam setting strict_ansi mode compilation. The offending code is: BOOST_STATIC_CONSTANT(bool, value = ( sizeof( BOOST_MPL_AUX_OVERLOAD_CALL_IS_MASKED( Set , BOOST_MPL_AUX_STATIC_CAST(aux::type_wrapper<T>*, 0) ) ) == sizeof(aux::no_tag) ) ); and the error message goes like "NULL reference is not allowed". Digging deeper, I'm pretty sure the problem has to do with tru64cxx not accepting selected implementation of BOOST_MPL_AUX_PTR_TO_REF in boost/mpl/aux_/ptr_to_ref.hpp when the pointer passed is null. There are two alternative implementations of this macro: 1. (MSVC, EDG) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ *BOOST_MPL_AUX_STATIC_CAST(X*, 0) \ /**/ 2. (remaining compilers) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ aux::ptr_to_ref(BOOST_MPL_AUX_STATIC_CAST(X*, 0)) \ /**/ tru64cxx, which is EDG-based, uses #1; it used to work OK, but when strict_ansi mode was selected, the compiler didn't like #1 anymore. So my questions are: A. Is there any reason why EDG is forced to use implementation #1? The CVS history doesn't shed much light about this. B. If A is unavoidable, can we macro-detect strict ansi mode so as to divert EDG+strict_ansi to implementation #2? C. If B has negative answer, could we at least eliminate the null pointer in boost/mpl/aux_/ptr_to_ref.hpp (by using a dummy make_ptr function, perhaps)? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Joaquín Mª López Muñoz wrote:
Despite recent changes by Dave Abrahams, mpl::set is still failing in tru64cxx as shown in the last regression cycle:
[snip problem analysis] I took the liberty to commit attached patch and the regression test for set now passes on Tru64/CXX. Thanks again for the help! Markus Index: ptr_to_ref.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/aux_/ptr_to_ref.hpp,v retrieving revision 1.4 diff -u -r1.4 ptr_to_ref.hpp --- ptr_to_ref.hpp 13 Oct 2004 18:23:20 -0000 1.4 +++ ptr_to_ref.hpp 22 Jun 2005 15:18:34 -0000 @@ -20,7 +20,9 @@ #if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1400)) \ - || BOOST_WORKAROUND(__EDG_VERSION__, <= 245) + || ( BOOST_WORKAROUND(__EDG_VERSION__, <= 245) \ + && !(defined(__STD_STRICT_ANSI) \ + || defined(__STD_STRICT_ANSI_ERRORS)) ) # define BOOST_MPL_AUX_PTR_TO_REF(X) \ *BOOST_MPL_AUX_STATIC_CAST(X*, 0) \
participants (3)
-
Boris Gubenko -
Joaquín Mª López Muñoz -
Markus Schöpflin