5 Replies Latest reply: Aug 28, 2014 4:41 PM by Steve.Clamage-Oracle Branched to a new discussion. RSS

    Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh

    1059891

      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.

        • 1. Re: Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh
          Steve.Clamage-Oracle

          As with your other example with preprocessed code,

          Error compiling certain uses of std::tuple in Solaris Studio 12.4 beta July refresh

          I can tell you more if you post a relatively small test case (not preprocessed).

          • 2. Re: Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh
            1059891

            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:

            1. 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
            2. 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.

            1. 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)

             

            1. 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
            1. 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:

            1. The compilation problem with tuple that you've already fixed
            2. A linker problem with finding std::string related symbols - maybe also related to the gcc header upgrade and now fixed?
            3. 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.

            • 3. Re: Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh
              Steve.Clamage-Oracle

              We do test Boost 1.55 in C++11 mode.

              The following are corrections to the Boost code that we have found so far, when compiling with Studio 12.4 in C++11 mode.

               

              1.boost/intrusive/detail/memory_util.hpp

              189:   #if !defined (__SUNPRO_CC)

              205:   #if !defined (__SUNPRO_CC)

               

              replace these two lines with

              #if !defined(__SUNPRO_CC) || (__SUNPRO_CC >= 0x5130)

               

              2.boost/predef/architecture/sparc.h

              40: #   if !defined(BOOST_ARCH_SPARC) &&

              replace this line with

              #if !defined(BOOST_ARCH_SPARC)

               

              3.boost/predef/other/endian.h

              144:        BOOST_ARCH_PARISK || \

              replace this line with

              BOOST_ARCH_PARISK || \

              BOOST_ARCH_SPARC || \

               

              4.boost/config/compiler/sunpro_cc.hpp

              #define BOOST_NO_CXX11_AUTO_DECLARATIONS

              #define BOOST_NO_CXX11_AUTO_MULTIDECLARATIONS

              #define BOOST_NO_CXX11_CHAR16_T

              #define BOOST_NO_CXX11_CHAR32_T

              #define BOOST_NO_CXX11_CONSTEXPR

              #define BOOST_NO_CXX11_DECLTYPE

              #define BOOST_NO_CXX11_DECLTYPE_N3276

              #define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS

              #define BOOST_NO_CXX11_DELETED_FUNCTIONS

              #define BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS

              #define BOOST_NO_CXX11_EXTERN_TEMPLATE

              #define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS

              #define BOOST_NO_CXX11_HDR_INITIALIZER_LIST

              #define BOOST_NO_CXX11_LAMBDAS

              #define BOOST_NO_CXX11_LOCAL_CLASS_TEMPLATE_PARAMETERS

              #define BOOST_NO_CXX11_NOEXCEPT

              #define BOOST_NO_CXX11_NULLPTR

              #define BOOST_NO_CXX11_RANGE_BASED_FOR

              #define BOOST_NO_CXX11_RAW_LITERALS

              #define BOOST_NO_CXX11_RVALUE_REFERENCES

              #define BOOST_NO_CXX11_SCOPED_ENUMS

              #define BOOST_NO_SFINAE_EXPR

              #define BOOST_NO_CXX11_STATIC_ASSERT

              #define BOOST_NO_CXX11_TEMPLATE_ALIASES

              #define BOOST_NO_CXX11_UNICODE_LITERALS

              #define BOOST_NO_CXX11_VARIADIC_TEMPLATES

              #define BOOST_NO_CXX11_VARIADIC_MACROS

              #define BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX

              #define BOOST_NO_CXX11_USER_DEFINED_LITERALS

              #define BOOST_NO_CXX11_ALIGNAS

              #define BOOST_NO_CXX11_TRAILING_RESULT_TYPES

              #define BOOST_NO_CXX11_INLINE_NAMESPACES

               

              comment out all of above lines.

               

              5.boost/archive/detail/register_archive.hpp

              31:#ifdef __SUNPRO_CC

              replace this line with

              #if defined(__SUNPRO_CC) && (__SUNPRO_CC < 0x5130)

              • 4. Re: Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh
                1059891

                Thanks for those edits Steve.  Information like that is very useful.

                 

                Your 5th edit basically has the same effect as the one in my original post (#if 0) in the case where the compiler is known to be version 12.4.  When I make your 5 edits and build using the July beta compiler I get the same assertion failure as in the original post:

                 

                >> Assertion:   (../lnk/funcsym.cc, line 1679)

                 

                If you don't get this now then I guess that suggests that the underlying bug has been fixed in your development codeline after the July refresh of the beta was built.

                • 5. Re: Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh
                  Steve.Clamage-Oracle

                  We do see exactly this failure, and it hasn't been fixed yet. (Probably not what you hoped to hear.)