From: Ralf W. Grosse-Kunstleve (rwgk_at_[hidden])
Date: 2006-03-13 22:31:02
--- Boris Gubenko <Boris.Gubenko_at_[hidden]> 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
> > 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:
boost::mpl_::integral_c<boost::numeric::udt_builtin_mixture_enum, 0L> bar;
unsigned long, long>::target_type,
unsigned long, long>::source_type
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/^#/\/\//' >
aCC -AA numeric_cast_pp.cpp -c
The full output from the last command is here:
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
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.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk