Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh

Question

I have found a way to get an assertion failure from the ccfe program that comes with the Solaris Studio 12.4 beta July refresh.  The error that gets printed is:
>> Assertion:   (../lnk/funcsym.cc, line 1679)
    while processing text_woarchive.pre.cpp at line 0.
The problem occurs whilst compiling Boost 1.54.  The original file in the distribution that causes it is libs/serialization/src/text_woarchive.cpp.
This problem can be reproduced by getting the pre-processed code I've put on http://pastebin.com/E9vxi2z7 and pasting it into a file called text_woarchive.pre.cpp.  Then run:
CC -std=c++11 -mt -m64 -c -o text_woarchive.o text_woarchive.pre.cpp
and you get the assertion failure.
Running:
CC '-#' -std=c++11 -mt -m64 -c -o text_woarchive.o text_woarchive.pre.cpp
shows that the assertion is coming from ccfe.
In case you go back to the original Boost source code I should tell you that prior to generating the pre-processed source I changed:
#ifdef __SUNPRO_CC
to:
#if 0
in boost/archive/detail/register_archive.hpp.  I did this because there was an error in the __SUNPRO_CC section and I wondered if that workaround code was no longer required with the more modern C++ compiler.  Therefore, I cannot guarantee that the pre-processed source is 100% valid C++ code.  However, even if it's not it would be nice to get a clear error message out of ccfe rather than an assertion failure.
In case it's relevant, I'm working on Oracle Solaris 10 1/13 s10x_u11wos_24a X86.

Answer 1

You mentioned in the other answer that you are testing with Boost 1.55.  Are you testing this in C++11 mode?
Today I downloaded Boost 1.55 and did the following:
In both tools/build/v2/engine/build.sh and tools/build/v2/tools/sun.jam globally replace SUNWspro with SolarisStudio12.4-beta_jul14-solaris-x86
In tools/build/v2/tools/sun.jam replace:
feature.extend stdlib : sun-stlport ;
feature.compose <stdlib>sun-stlport
    : <cxxflags>-library=stlport4 <linkflags>-library=stlport4
with:
feature.extend stdlib : sun-stlport ;
feature.compose <stdlib>sun-stlport
    : <cxxflags>-std=c++11 <linkflags>-std=c++11
Note: This is just the quick way I found to con the Boost build system into using C++11 instead of STLport.  The feature in the jam file still has stlport in its name, but that's only a name and the code is being built in C++11 mode.
In boost/math/special_functions/detail/lanczos_sse2.hpp change line 15 from:
#if defined(__GNUC__) || defined(__PGI)
to:
#if defined(__GNUC__) || defined(__PGI) || defined(__SUNPRO_CC)
Run:
./bootstrap.sh --without-libraries=context --without-libraries=coroutine --without-libraries=graph_parallel --without-libraries=log --without-libraries=mpi --without-libraries=python --without-libraries=test --without-icu
Run:
./b2 -j4 --layout=versioned --disable-icu address-model=64 threading=multi optimization=speed inlining=full
At this point the vast majority of the code builds, but does not link.
There are 3 problems:
The compilation problem with tuple that you've already fixed
A linker problem with finding std::string related symbols - maybe also related to the gcc header upgrade and now fixed?
Numerous compilation problems caused by boost/archive/detail/register_archive.hpp
For this last one the code in the #ifdef __SUNPRO_CC section of boost/archive/detail/register_archive.hpp does appear to be invalid, and leads to the errors:
"./boost/archive/detail/register_archive.hpp", line 45: Error: The function "adjust_counter" must have a prototype.
"./boost/archive/detail/register_archive.hpp", line 46: Error: Expression must have a constant value.
"./boost/archive/detail/register_archive.hpp", line 47: Error: Expression must have a constant value.
"./boost/archive/detail/register_archive.hpp", line 48: Error: An integer constant expression is required within the array subscript operator.
Even with Boost 1.55, attempts to fix this lead to the same ccfe assertion.  Trying to use the #else part of the code as I described in the original post does, as does moving the line:
char adjust_counter(counter<0>);
so that it comes before the place where adjust_counter is used also then leads to the same assertion:
>> Assertion:   (../lnk/funcsym.cc, line 1679)
It's as though any change to boost/archive/detail/register_archive.hpp that fixes the basic code ordering issue lets ccfe get far enough to cause the assertion.
If there is somebody in your team looking at whether Boost 1.55 compiles with Solaris Studio 12.4 in C++11 mode then hopefully they can relate to what I'm seeing here.  One key point is that they'll have had to edit the jam files to use C++11 mode.
The other thing is that any insights the person who has been trying to build Boost 1.55 has would be very useful.  I know you don't want to get into officially supporting it, but maybe a blog post with any unofficial hints and tips on getting Boost to build in C++11 mode could be a way to share knowledge.