HP-UX aCC or boost problem?
While trying to port Boost.Python to HP-UX using the native "aCC" compiler I ran into this issue: void foo() { enum udt_builtin_mixture_enum { builtin_to_builtin ,builtin_to_udt ,udt_to_builtin ,udt_to_udt } ; udt_builtin_mixture_enum value1 = builtin_to_builtin; // this works udt_builtin_mixture_enum value2 = 0; // this doesn't } % aCC -AA -c enum_init.cpp "enum_init.cpp", line 11: error #2144: a value of type "int" cannot be used to initialize an entity of type "udt_builtin_mixture_enum" udt_builtin_mixture_enum value2 = 0; ^ 1 error detected in the compilation of "enum_init.cpp". Is the compiler correct in rejecting the initialization with 0? Thanks! Cheers, Ralf P.S.: aCC: HP aC++/ANSI C B3910B A.06.01 [Jan 05 2005] __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
The compiler is correct. Instead of quoting C++ Standard, I'll quote Lippman C++ Primer, 3rd edition, p.113: An object of an enumeration type can be be initialized and assigned only with another object of the same enumeration type or with one of its set of enumerators. For example, although 3 is a legal value associated with Points, it cannot be explicitly assigned to a Points object: [...] enum Points { point2d = 2, point2w, point3d = 3, point3w }; // error: pt2w initialized with int Points pt2w = 3; Btw, you'd get the same compilation error with any EDG-based compiler. On Tru64, for example: $ cxx -V Compaq C++ V6.5-042 for Compaq Tru64 UNIX V5.0A (Rev. 1094) Compiler Driver V6.5-042 (cxx) cxx Driver $ cxx -c enum_init.cpp cxx: Error: enum_init.cpp, line 11: a value of type "int" cannot be used to initialize an entity of type "udt_builtin_mixture_enum" udt_builtin_mixture_enum value2 = 0; // this doesn't ------------------------------------^ cxx: Info: 1 error detected in the compilation of "enum_init.cpp". $ Or on VMS: $ cxx/ver Compaq C++ V6.5-004 for OpenVMS Alpha V7.3-2 $ cxx/noobj enum_init.cpp udt_builtin_mixture_enum value2 = 0; // this doesn't ....................................^ %CXX-E-BADINITTYP, a value of type "int" cannot be used to initialize an entity of type "udt_builtin_mixture_enum" at line number 11 in file WORK5:[BORIS]ENUM_INIT.CPP;1 Boris ----- Original Message ----- From: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> To: <boost@lists.boost.org> Sent: Monday, March 13, 2006 2:11 PM Subject: [boost] HP-UX aCC or boost problem?
While trying to port Boost.Python to HP-UX using the native "aCC" compiler I ran into this issue:
void foo() { enum udt_builtin_mixture_enum { builtin_to_builtin ,builtin_to_udt ,udt_to_builtin ,udt_to_udt } ; udt_builtin_mixture_enum value1 = builtin_to_builtin; // this works udt_builtin_mixture_enum value2 = 0; // this doesn't }
% aCC -AA -c enum_init.cpp "enum_init.cpp", line 11: error #2144: a value of type "int" cannot be used to initialize an entity of type "udt_builtin_mixture_enum" udt_builtin_mixture_enum value2 = 0; ^
1 error detected in the compilation of "enum_init.cpp".
Is the compiler correct in rejecting the initialization with 0?
Thanks!
Cheers, Ralf
P.S.: aCC: HP aC++/ANSI C B3910B A.06.01 [Jan 05 2005]
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- Boris Gubenko <Boris.Gubenko@hp.com> wrote:
The compiler is correct. Instead of quoting C++ Standard, I'll quote Lippman C++ Primer, 3rd edition, p.113:
An object of an enumeration type can be be initialized and assigned only with another object of the same enumeration type or with one of its set of enumerators. For example, although 3 is a legal value associated with Points, it cannot be explicitly assigned to a Points object: [...] enum Points { point2d = 2, point2w, point3d = 3, point3w }; // error: pt2w initialized with int Points pt2w = 3;
Thanks!
Btw, you'd get the same compilation error with any EDG-based compiler. On Tru64, for example:
Indeed. I have the same compiler. I should have checked before. Obviously I've reduced the problem a bit too much. Boost.Python (with the very same boost version from CVS) compiles fine with the Tru64 cxx compiler, but aCC gives this error (fragment of output): aCC -o boost/libs/python/src/converter/builtin_converters.o -c -AA +W2837 -DBOOST_DISABLE_THREADS -DNDEBUG -O -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/home1/tmaier/dist/boost -Ipython/include/python2.4 -I/home1/tmaier/dist/python/include/python2.4 boost/libs/python/src/converter/builtin_converters.cpp ... "boost/boost/mpl/aux_/integral_wrapper.hpp", line 45: error #2144: a value of type "long" cannot be used to initialize an entity of type "const boost::numeric::udt_builtin_mixture_enum" BOOST_STATIC_CONSTANT(AUX_WRAPPER_VALUE_TYPE, value = N); ^ detected during: instantiation of class "mpl_::integral_c<T, N> [with T=boost::numeric::udt_builtin_mixture_enum, N=0L]" at line 30 of "boost/boost/numeric/conversion/detail/meta.hpp" The full output is here: http://cci.lbl.gov/~rwgk/tmp/hp_ux_aCC_error_2006_03_13_1225 The problem can be reduced like this: #include <boost/numeric/conversion/cast.hpp> unsigned long long foo() { return boost::numeric_cast<unsigned long long, long>(0L); } This compiles with Tru64 cxx: % cxx -std strict_ansi -c -I$dist/boost numeric_cast.cpp cxx: Warning: numeric_cast.cpp, line 3: the type "long long" is nonstandard unsigned long long --------------^ cxx: Warning: numeric_cast.cpp, line 6: the type "long long" is nonstandard return boost::numeric_cast<unsigned long long, long>(0L); -------------------------------------------^ But not with aCC: http://cci.lbl.gov/~rwgk/tmp/hp_ux_aCC_error_2006_03_13_1248 Could this be fixed with a few extra #ifdefs? Cheers, Ralf BTW: Is the aCC compiler somehow related to the Tru64 compiler? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Ralf, I can reproduce the problem compiling your program example against boost CVS HEAD. I also confirmed, that the program compiles cleanly with cxx V6.5-042 on Tru64 and with Intel's ICC 9.0 on Linux.
Could this be fixed with a few extra #ifdefs?
I'll take a look tomorrow.
BTW: Is the aCC compiler somehow related to the Tru64 compiler?
They both use the EDG front end. Thanks, Boris ----- Original Message ----- From: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> To: <boost@lists.boost.org> Sent: Monday, March 13, 2006 3:51 PM Subject: Re: [boost] HP-UX aCC or boost problem?
--- Boris Gubenko <Boris.Gubenko@hp.com> wrote:
The compiler is correct. Instead of quoting C++ Standard, I'll quote Lippman C++ Primer, 3rd edition, p.113:
An object of an enumeration type can be be initialized and assigned only with another object of the same enumeration type or with one of its set of enumerators. For example, although 3 is a legal value associated with Points, it cannot be explicitly assigned to a Points object: [...] enum Points { point2d = 2, point2w, point3d = 3, point3w }; // error: pt2w initialized with int Points pt2w = 3;
Thanks!
Btw, you'd get the same compilation error with any EDG-based compiler. On Tru64, for example:
Indeed. I have the same compiler. I should have checked before.
Obviously I've reduced the problem a bit too much.
Boost.Python (with the very same boost version from CVS) compiles fine with the Tru64 cxx compiler, but aCC gives this error (fragment of output):
aCC -o boost/libs/python/src/converter/builtin_converters.o -c -AA +W2837 -DBOOST_DISABLE_THREADS -DNDEBUG -O -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/home1/tmaier/dist/boost -Ipython/include/python2.4 -I/home1/tmaier/dist/python/include/python2.4 boost/libs/python/src/converter/builtin_converters.cpp ... "boost/boost/mpl/aux_/integral_wrapper.hpp", line 45: error #2144: a value of type "long" cannot be used to initialize an entity of type "const boost::numeric::udt_builtin_mixture_enum" BOOST_STATIC_CONSTANT(AUX_WRAPPER_VALUE_TYPE, value = N); ^ detected during: instantiation of class "mpl_::integral_c<T, N> [with T=boost::numeric::udt_builtin_mixture_enum, N=0L]" at line 30 of "boost/boost/numeric/conversion/detail/meta.hpp" The full output is here:
http://cci.lbl.gov/~rwgk/tmp/hp_ux_aCC_error_2006_03_13_1225
The problem can be reduced like this:
#include <boost/numeric/conversion/cast.hpp>
unsigned long long foo() { return boost::numeric_cast<unsigned long long, long>(0L); }
This compiles with Tru64 cxx:
% cxx -std strict_ansi -c -I$dist/boost numeric_cast.cpp cxx: Warning: numeric_cast.cpp, line 3: the type "long long" is nonstandard unsigned long long --------------^ cxx: Warning: numeric_cast.cpp, line 6: the type "long long" is nonstandard return boost::numeric_cast<unsigned long long, long>(0L); -------------------------------------------^
But not with aCC:
http://cci.lbl.gov/~rwgk/tmp/hp_ux_aCC_error_2006_03_13_1248
Could this be fixed with a few extra #ifdefs?
Cheers, Ralf
BTW: Is the aCC compiler somehow related to the Tru64 compiler?
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- Boris Gubenko <Boris.Gubenko@hp.com> wrote:
I can reproduce the problem compiling your program example against boost CVS HEAD. I also confirmed, that the program compiles cleanly with cxx V6.5-042 on Tru64 and with Intel's ICC 9.0 on Linux.
Yes, we have been using Boost.Python with Tru64 cxx for many years now.
Could this be fixed with a few extra #ifdefs?
I'll take a look tomorrow.
That would be fantastic.
BTW: Is the aCC compiler somehow related to the Tru64 compiler?
They both use the EDG front end.
We are successfully working with EDG 238, 245, 304. This makes me hopeful that it is "just" a matter of finding the right switches. I spent the better part of today beating on this. Unfortunately I did't get too far, but at least I have this: #include <boost/numeric/conversion/cast.hpp> void foo() { #ifdef ALL_FAIL boost::mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, 0L> bar; #else boost::numeric::convdetail::get_subranged< boost::numeric::convdetail::get_conversion_traits< unsigned long, long>::target_type, boost::numeric::convdetail::get_conversion_traits< unsigned long, long>::source_type
::udt_builtin_mixture bar; #endif }
The code in the ALL_FAIL fails both with cxx and aCC, as expected. I got the code from the aCC error message produced by compiling the pre-processed code in the #else branch, i.e.: aCC -AA -I../boost -E numeric_cast.cpp | & sed 's/^#/\/\//' > numeric_cast_pp.cpp aCC -AA numeric_cast_pp.cpp -c The full output from the last command is here: http://cci.lbl.gov/~rwgk/tmp/hp_ux_aCC_error_2006_03_13_1922 The code in the #else branch above compiles cleanly with cxx. I.e. somehow aCC arrives at 0L for the second integral_c<> template parameter, but cxx does not. My primary goal was to hunt down where the #ifdefs where the two platforms differ. I noticed that the two compilers use different branches in /boost/mpl/aux_/lambda_support.hpp cxx uses to shortcut near the top, aCC uses the longer code after the #else. I changed the #ifdef around so that both compilers use the shortcut near the top, but that didn't make a difference, at least not for compiling the small fragment above. This is all I know so far. I hope Aleksey and Dave will take a look, in case it is something obvious to them. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On 3/13/06, Boris Gubenko <Boris.Gubenko@hp.com> wrote:
BTW: Is the aCC compiler somehow related to the Tru64 compiler?
They both use the EDG front end.
Really? When did they switch? When aCC began development, it was done by Daveed Vandevoorde who later joined EDG (IIRC), but I can't find anywhere that shows aCC uses EDG. I don't have an up to date version anymore as we long ago had to move to gcc because of aCC's woeful advanced C++/Boost support, so I can't check. If they were using it, it might be worthwhile to switch back for HP's better optimizing.
Really? When did they switch?
In aCC6.
I don't have an up to date version anymore as we long ago had to move to gcc because of aCC's woeful advanced C++/Boost support [...]
With aCC6, it is a totally different story. Boris ----- Original Message ----- From: "Thomas Matelich" <matelich@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, March 14, 2006 1:21 PM Subject: Re: [boost] HP-UX aCC or boost problem?
On 3/13/06, Boris Gubenko <Boris.Gubenko@hp.com> wrote:
BTW: Is the aCC compiler somehow related to the Tru64 compiler?
They both use the EDG front end.
Really? When did they switch? When aCC began development, it was done by Daveed Vandevoorde who later joined EDG (IIRC), but I can't find anywhere that shows aCC uses EDG.
I don't have an up to date version anymore as we long ago had to move to gcc because of aCC's woeful advanced C++/Boost support, so I can't check.
If they were using it, it might be worthwhile to switch back for HP's better optimizing. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Really? When did they switch? When aCC began development, it was done by Daveed Vandevoorde who later joined EDG (IIRC), but I can't find anywhere that shows aCC uses EDG.
Running config_info after building with aCC shows it defines __EDG_RUNTIME_USES_NAMESPACES which is an EDG front end define. No other EDG compiler macros appear to be defined however, so it does appear to be EDG based, it's just pretending not to be :-)
I don't have an up to date version anymore as we long ago had to move to gcc because of aCC's woeful advanced C++/Boost support, so I can't check.
If they were using it, it might be worthwhile to switch back for HP's better optimizing.
They're latest Itanium compiler is actually pretty good at compiling Boost code IMO, although I've only used parts of Boost with that compiler (it did handle Boost.Lambda perfectly though which is a good sign). John.
--- John Maddock <john@johnmaddock.co.uk> wrote:
They're latest Itanium compiler is actually pretty good at compiling Boost code IMO, although I've only used parts of Boost with that compiler (it did handle Boost.Lambda perfectly though which is a good sign).
Which version of aCC do you have exactly? (aCC -V) Are you using Boost.Build V1 or V2? With the standard toolset? Thanks! Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Which version of aCC do you have exactly? (aCC -V)
aCC: HP aC++/ANSI C B3910B A.06.06 [Nov 7 2005]
Are you using Boost.Build V1 or V2? With the standard toolset?
Neither, I haven't tried Boost.Build with it. You can try out the compiler for yourself if you sign up for a free HP Testdrive account at http://www.testdrive.hp.com/current.shtml and then log into the td176 machine. HTH, John.
--- John Maddock <john@johnmaddock.co.uk> wrote:
Which version of aCC do you have exactly? (aCC -V)
aCC: HP aC++/ANSI C B3910B A.06.06 [Nov 7 2005]
Thanks John! I was working with A.06.01.
Are you using Boost.Build V1 or V2? With the standard toolset?
Neither, I haven't tried Boost.Build with it.
I am very interested in reproducing your success with boost lambda. Could you please post the compilation commands you used? E.g. simply a log showing all the compile and link commands?
You can try out the compiler for yourself if you sign up for a free HP Testdrive account at http://www.testdrive.hp.com/current.shtml and then log into the td176 machine.
Thanks for the pointer! I'll definitely try this out. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I am very interested in reproducing your success with boost lambda. Could you please post the compilation commands you used? E.g. simply a log showing all the compile and link commands?
It was literally just a: aCC -I path-to-boost myfile.cpp Oh, sometimes I might have thrown in an -O3, but that's it :-) John.
Ralh, when running boost regression with aCC6, I suppress the following warnings: acc0606-tools.jam ----------------- { extends-toolset acc ; flags acc0606 CFLAGS : +W2001,2021,2047,2061,2063,2068,2111,2161,2167,2177,2185,2186,2191,2236,2334,2340,2414,2461,2549,2550,276 1,2811,2837,2940,2997,4067,4189,4257 ; } You might want to add at least some of the +Wnnnn above to your aCC command. I did not get any chance to look at your boost.python issue yet - we are completely swamped by the 64-bit compiler/library work for iVMS. Sorry about that. And, yes, sign up for an account on td176.testdrive.hp.com machine. It has A.06.06 installed. Boris ----- Original Message ----- From: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> To: <boost@lists.boost.org> Sent: Thursday, March 16, 2006 10:20 AM Subject: Re: [boost] HP-UX aCC or boost problem?
--- John Maddock <john@johnmaddock.co.uk> wrote:
Which version of aCC do you have exactly? (aCC -V)
aCC: HP aC++/ANSI C B3910B A.06.06 [Nov 7 2005]
Thanks John! I was working with A.06.01.
Are you using Boost.Build V1 or V2? With the standard toolset?
Neither, I haven't tried Boost.Build with it.
I am very interested in reproducing your success with boost lambda. Could you please post the compilation commands you used? E.g. simply a log showing all the compile and link commands?
You can try out the compiler for yourself if you sign up for a free HP Testdrive account at http://www.testdrive.hp.com/current.shtml and then log into the td176 machine.
Thanks for the pointer! I'll definitely try this out.
Cheers, Ralf
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Boris Gubenko -
John Maddock -
Ralf W. Grosse-Kunstleve -
Thomas Matelich