Assertion:   (../lnk/tmplmatchargs.cc, line 178)

I am using studio 11 for v8 on solaris 9, with the following patches installed:
120760-02 121015-01 121017-01 121019-01 121021-01
When I compile the following code with "CC -c file.cpp", I get:
>> Assertion:   (../lnk/tmplmatchargs.cc, line 178)
    while processing file.cpp at line 19.The code is:
struct K {};
template < class T1 , class T2 , class T3 > class A { } ;
template < class T ,
template < class U , class V , class W >
class X = A >
class B { } ;
template < class T ,
template < class U , class V , class W >
class X >
K & operator >> ( K & in , B < T , X > & P ) {
return in ;
typedef B < float > Z ;
void f ( K & in , Z f ) {
    in >> f;
}I guess it just means that it cannot deal with default values for template template arguments, but it is a violent way to say so.
(I also got an assertion failure this morning in ../lnk/initializer.cc with an other piece of code, I will try to get my hands on it again)

An assertion from the compiler is always a compiler bug. In this case, it looks like an internal failure in dealing with template template parameters.
I have filed bug 6396915 for you.
If you have a contract with Sun Service, you can track progress on fixing this bug, and get a pre-release version of the patch that fixes it.
Otherwise, you can check the Sun Studio patch page from time to time to see whether a patch has been released that fixes the bug. A fix for this problem will not appear for at least two months.

Similar Messages

  • Assertion failed: 0, file ../lnk/exthrow.cc, line 425 Abort (core dumped)

    Hi,
    I have a JNI native library that calls a custom C++ shared library with a number of number of dependencies. At runtime, in the process of loading the custom C++ library, I got the folloing message.
    Assertion failed: 0, file ../lnk/exthrow.cc, line 425
    Abort (core dumped)
    If I did mdb on core dump, the following is the result.
    mdb java.29922
    mdb: core file data for mapping at ffb7a000 not saved: Bad address
    Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
    $Cffbf7c90 libc.so.1`_lwp_kill+8(6, 0, ff2f2e10, ff2a8bd0, ffffffff, 6)
    ffbf7cf0 libc.so.1`abort+0x110(ffbf7de0, 1, 0, ad314, ff2f12d8, 0)
    ffbf7d80 libc.so.1`_assert+0x64(ff1d9358, ff1d935a, 1a9, ff1ea810, ad030, ff1d418c)
    ffbf7fe0 libCrun.so.1`__1cG__CrunMex_rethrow_q6F_v_+0xf0(0, fffb, 0, 14c14, 2, 0)
    ffbf8040 libtssclt.so.3`__1cDstdNbasic_istream4Ccn0ALchar_traits4Cc___2t6Mn0AIios_baseJEmptyCtor__v_+0xb8(eef09710, 0,
    eef0df94, eef0a088, eef09730, eef09748)
    ffbf80a0 libtssclt.so.3`__SLIP.INIT_A+0x20(0, ff2f3700, acb18, ff2bb774, f0bd4840, f0bd4880)
    ffbf8100 libtssclt.so.3`__1cU__STATIC_CONSTRUCTOR6F_v_+4(ee774a48, ff2f3700, acb18, ff1d6e50, f0bd3b40, f0bd3b80)
    ffbf8160 libtssclt.so.3`_init+0x110(ff3f40fc, ff3f5a50, 2b414, 0, ff3f4910, 821)
    ffbf81c0 ld.so.1`call_init+0x16c(c10081, 1, fe9d0f60, ee7c5eb4, ff3f4910, ffdfffff)
    ffbf8228 ld.so.1`dlmopen_intn+0x164(ff3f40fc, 10000, c01, 24, 3b, ff161f30)
    ffbf8288 ld.so.1`dlmopen_check+0x160(ff3f40fc, 10c5c8, c01, ff3914f8, ffbf834c, 0)
    ffbf82e8 ld.so.1`dlopen+0x30(10c5c8, 1, 1, ff185fac, 57c0, ff185fa8)
    ffbf8350 libjvm.so`__1cCosIdll_load6Fpkcpci_pv_+0x20(10c5c8, ffbf8858, 400, 0, 12eed4, 5400)
    ffbf83f0 libjvm.so`JVM_LoadLibrary+0x15c(10c5c8, 64fc, 38810, ff18696c, ff185fac, 2)
    ffbf8c58 libjava.so`Java_java_lang_ClassLoader_00024NativeLibrary_load+0xe8(388cc, ffbf8f2c, ffbf8f28, 0, 10c5c8, 0)
    ffbf8dc0 0xf900bc20(11, ffbf8f2c, ffbf8ea8, ffffff80, 64fc, 0)
    ffbf8e40 0xf900bbc4(f0c303c0, b6, 0, 8, 1ffc, ffbf8ec0)
    ffbf8ec0 0xf9005764(f0c30080, b8, f0c09478, f9014760, f0c374a8, ffbf8f90)
    ffbf8f58 0xf90057a8(0, b8, ffbf911c, f9014a20, 110, ffbf9028)
    ffbf9018 0xf9005764(f0c08de8, b6, ffbf919c, f9014a68, 57c0, ffbf90c0)
    ffbf90b8 0xf9005764(339b8, 0, 64fc, f9014760, ff185fac, ffbf9140)
    ffbf9140 0xf9005764(c000, 2, 4c00, f9014a70, ff17fca0, ffbf91b8)
    ffbf91b8 0xf9000218(ffbf92a0, ffbf9380, a, f4d5f2f8, f900a7e0, ffbf9390)
    ffbf9218 libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x5b8(
    ffbf9378, 38810, ffbf938c, ffbf92b0, 38eb8, 0)
    ffbf92e0 libjvm.so`__1cNinstanceKlassPinitialize_impl6FnTinstanceKlassHandle_pnGThread__v_+0x68c(ffbf9524, 38810, f4d5f330,
    391cc, 38eb8, 38eb4)
    ffbf94c0 libjvm.so`__1cNinstanceKlassKinitialize6MpnGThread__v_+0x80(38e20, 38810, fecd7a8c, f4d5f330, 38810, ff181fbc)
    ffbf9540 libjvm.so`__1cbCfind_class_from_class_loader6FpnHJNIEnv__nMsymbolHandle_CnGHandle_3CpnGThread__pnH_jclass__+0xd8(
    388cc, 1, 1, 38e18, f4d5f330, 1)
    ffbf95b0 libjvm.so`jni_FindClass+0x720(388cc, 0, 0, ff18696c, 391cc, 0)
    ffbf9640 main+0xe3c(6, 388cc, ff182ba0, 39348, 0, 1)
    ffbf9ed0 _start+0x108(0, 0, 0, 0, 0, 0)
    Any help/assistance on this issue would be highly appriciated.
    Thanks and Regards
    Somesh

    I ran into this exact same problem (on Solaris, JVM 1.4.1). Although I don't know the exact cause, I can tell you what I did to fix it..
    Of course, this happens when you try to load a native library (a .so in this case). I ldd'd that .so, and found that it in turn was linked to two other libraries in my control, and some other OS libraries.
    When I statically linked either one of my libraries, such that only one of the libraries under my control was still linked dynamically, leaving the OS libaries untouched, then the problem went away. Note that it didn't matter which one I linked statically- as long as one (or both) were static there was no problem.
    My guess was that there were some sort of cyclic dependencies with these libraries, but right now I'm happy enough that it works, so I'm not going to try and pursue this further..

  • Internal compiler error: Assertion: (../lnk/v2mangler.cc, line 136)

    I am working in C++ in this environment:
    $ which CC
    /hep1/lang/sunstudio11/SUNWspro/prod/bin/CC
    $ CC -V
    CC: Sun C++ 5.8 Patch 121017-10 2007/02/21
    $ uname -a
    SunOS hep 5.9 Generic_118558-37 sun4u sparc SUNW,A70
    I have run into the following internal compiler error more than once:
    >> Assertion: (../lnk/v2mangler.cc, line 136)
    while processing ./tempdir/xxx.c at line 0.
    ... where xxx.c is the preprocessed file. The error message is always the same (i.e. generated from line 136 of v2mangler.cc and complaining about line 0 of the preprocessed file). I have tried without success to isolate line(s) in my C++ source causing the error. It might help to know what the compiler is trying to do near line 136 of v2mangler.cc which triggers this error.

    This assertion prevents to mangle negative number. The source of this negative number is not clear without test case.

  • Assertion:   (../lnk/classutils.cc, line 299) - CC: Sun C++ 5.13 Beta2 2014/06/17

    The test code is
    class X
      int z : 3;
      X() : z(-1) {}
    The result is:
    vkni@solaris:~/c++$ CC -c main.cpp
    >> Assertion:   (../lnk/classutils.cc, line 299)
        while processing main.cpp at line 0.
    If I rewrite the constructor like
      X()  { z =-1; }
    it compiles without any problem.
    P.S.
    The bug is probably in the parser code, because if I forget the last ";" the first variant will fail with assertion, while the second will tell me about missing ";" like
    "main.cpp", line 7: Error: Use ";" to terminate declarations.

    Dear Fedor and Steve, thank you very much for replies. I found this problem when compiling QT4. It can be build using your compiler almost completely. Another problem, that I found, is an assertion
    >> Assertion:   (../lnk/tempparse.cc, line 3505)
        while processing ../3rdparty/javascriptcore/JavaScriptCore/API/JSCallbackObject.cpp at line 0.
    The code, that raises assertion to a very high probability is
    template <> const ClassInfo JSCallbackObject<JSObject>::info = { "CallbackObject", 0, 0, 0 };        
    template <> const ClassInfo JSCallbackObject<JSGlobalObject>::info = { "CallbackGlobalObject", 0, 0, 0     };
    (commenting both of these lines I eliminate assertion, if I leave anyone - the assertion will be raised)
    Do you know already what is that? Or I need to give you purified example?

  • Assertion:   (../lnk/ir_util.cc, line 339

    Hi ,
    Iam getting following errors
    Assertion: (../lnk/ir_util.cc, line 339)while processing myfile.cpp at line 5075.
    *** Error code 1
    The line where error is arised returned constant string which is agian
    typedef with template.
    I am using Sunstudio 8(C++ 5.5) compiler without patch.
    Also I am getting this error during release build and this file "myfile.cpp"
    compiled fine in debug mode.
    Is this compiler need any patch?
    Also this C++(5.5) that I have didn't contain any patch.
    Thanks in advance.
    -Riaj

    Please do not post the same question twice. See my answer in your original posting.

  • Assertion:   (../lnk/exprparse.cc, line 1454) - compiler bug??

    Hi,
    I get the following error message:
    CC -DLT_OBJDIR=\".libs/\" -I. -I. -I./include -DSOLARIS2 -DSTHREAD_CORE_PTHREAD -DARCH_LP64 -DNO_FASTNEW -DW_LARGEFILE -I/usr/local/include -xtarget=ultraT1 -m64 -features=extensions,zla -xthreadvar=no%dynamic -xdebugformat=stabs -xs -g0 -xO4 -mt -lpthread -library=stlport4 -c -o tests_simple-simple_test.o `test -f './src/tests/simple_test.cpp' || echo './'`./src/tests/simple_test.cpp
    >> Assertion: (../lnk/exprparse.cc, line 1454)
    while processing ./src/tests/simple_test.cpp at line 28.
    The source code looks like this (tried to make a simple a possible):
    ---- shell.h:
    class shell_t
    shell_t() {}
    ~shell_t() {}
    int start();
    virtual int process()=0;
    virtual int usage()=0;
    --- shell.cpp:
    int shell_t::start() {
    ...code
    --- simple_test.cpp
    class test_shell : public shell_t
    public:
    test_shell()
    : shell_t()
    ~test_shell() {}
    int process() { ...code... }
    int usage() { ...code...}
    int main(int argc, char* argv[])
    test_sell as;
    as.start();
    return (0);
    Has anyone seen this already?
    Does somebody know, what it means, and how to fix my code?
    Many thanks for all comments.
    -Ippokratis.
    Edited by: Ippokratis on Jun 5, 2008 11:37 PM

    Any compiler assertion is a compiler bug.
    If you want us to address this given issue, please, provide reproducable testcase
    (e.g. exact program that fails to compile together with a command line for compilation that fails).
    regards,
    __Fedor.

  • Assertion:   (../lnk/storage.cc, line 99)

    Hi
    I am using the latest SunStudio11 C++ compiler
    CC: Sun C++ 5.8 Patch 121017-03 2006/07/19
    During compilation of some source files I have message:
    ">> Assertion: (../lnk/storage.cc, line 99)
    while processing ... at line 0."
    What does this message mean?
    Thanks

    It looks like you hit the compiler bug. Would you please submit it using the web interface at http://bugs.sun.com/services/bugreport/index.jsp ?
    Thanks,
    Boris

  • Compiler Error: Assertion:   (../lnk/ir_util.cc, line 344)

    Hello,
    I am getting the error : Assertion: (../lnk/ir_util.cc, line 344) when compiling with Sun C++ 5.6. Does anyone know under which circumstances this error might occur ?
    Unfortunately the sun system is not my main development environment and is only used for occasional test builds. The code that causes the error does compile under MS Windows (gcc and Visual C++)
    Therefore i can only tell that compilation was successful a while ago. I do not know if there where changes to the system nor am I able to pin the error down to a single change to my code.
    Even hints on what might cause this problem will be much appreciated.
    Thanks,
    Fr�d�ric

    All compiler assertions are due to internal consistency checks failing, meaning that something "impossible" happened from which the compiler cannot recover.
    There is no a priori way to determine what in the source code triggered the assertion. A compiler engineer needs to work with example code that results in the assertion.
    All reported assertions from ir_util.cc (one of the files that make up the C++ compiler) have been fixed in C++ 5.6 or earlier. Evidently you have found something new.
    This particular assertion means the compiler was missing internal data needed to generate debug information. Compiling without -g should eliminate the assertion. Unfortunately, your ability to debug this part of your source code would be reduced.
    If you have a support contract, you should use your support channel to report the problem. The support engineer will need sample source code that demonstrates the problem, in order to file a bug report.
    If you don't have a support contract but can narrow down a test case to something small enough to post here, I'll see what I can do. Otherwise, if you post your email address or put it in your profile, I'll let you know where you can send a larger test case.

  • SQL Server Assertion: File: "logmgr.cpp" , line=5512

    Hi All,
    We are using Sql Server 2005 Express , 
    we got the below exception of Sql Server Assertion
    2014-11-17 00:26:12.59 spid51      Error: 17066, Severity: 16, State: 1.
    2014-11-17 00:26:12.59 spid51      SQL Server Assertion: File: <"logmgr.cpp">, line=5512 Failed Assertion = '!(minLSN.m_fSeqNo < lfcb->lfcb_fSeqNo)'. This error may be timing-related. If the error persists after rerunning
    the statement, use DBCC CHECKDB to check the database for structural integrity, or restart the server to ensure in-memory data structures are not corrupted.
    2014-11-17 00:26:12.61 spid51      Error: 3624, Severity: 20, State: 1.
    2014-11-17 00:26:12.61 spid51      A system assertion check has failed. Check the SQL Server error log for details. Typically, an assertion failure is caused by a software bug or data corruption. To check for database corruption, consider running
    DBCC CHECKDB. If you agreed to send dumps to Microsoft during setup, a mini dump will be sent to Microsoft. An update might be available from Microsoft in the latest Service Pack or in a QFE from Technical Support. 
    2014-11-17 00:27:34.81 Server      Using 'dbghelp.dll' version '4.0.5'
    2014-11-17 00:27:34.81 Server      ***Unable to get thread context - no pss
    2014-11-17 00:27:34.81 Server      * *******************************************************************************
    2014-11-17 00:27:34.81 Server      *
    2014-11-17 00:27:34.81 Server      * BEGIN STACK DUMP:
    2014-11-17 00:27:34.81 Server      *   11/17/14 00:27:34 spid 0
    2014-11-17 00:27:34.81 Server      *
    2014-11-17 00:27:34.81 Server      * Non-yielding Scheduler
    2014-11-17 00:27:34.81 Server      *
    2014-11-17 00:27:34.81 Server      * *******************************************************************************
    2014-11-17 00:27:34.81 Server      Stack Signature for the dump is 0x000003E6
    2014-11-17 00:27:35.75 Server      External dump process return code 0x20000001.
    External dump process returned no errors.
    2014-11-17 00:27:35.75 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    99%. Interval: 75000 ms.
    2014-11-17 00:28:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 135953 ms.
    2014-11-17 00:29:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 195953 ms.
    2014-11-17 00:30:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 255953 ms.
    2014-11-17 00:31:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 315953 ms.
    2014-11-17 00:32:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 375953 ms.
    2014-11-17 00:33:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 435953 ms.
    2014-11-17 00:34:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 495953 ms.
    2014-11-17 00:35:05.77 Server      The time stamp counter of CPU on scheduler id 1 is not synchronized with other CPUs.
    2014-11-17 00:35:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 555953 ms.
    2014-11-17 00:36:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    97%. Interval: 615953 ms.
    2014-11-17 00:37:35.77 Server      Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
    98%. Interval: 675953 ms.

    Assertion error are usually some corruption in SQL Server database. And non yielding scheduler seems like bug what is output of
    select @@Version
    Did you tried running dbcc checkdb on SQL Server 2005 database
    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
    My Technet Wiki Article
    MVP

  • Assertion failure: pRoot at line 107

    I guys, I'm having problems.. Someone can help me please?!
    This error appeared 2 weeks ago, before this I had changed some security privilegies on catalog manager. Then, I thought that error was becouse of the changes that I made for. But it was not. Why was not? Cause I deleted the catalog(metadata folder) and I created another start. Why I did that? Cause I thought that error was cause for some changes that I did. Then I started another catalog, with new reports, new security roles and the error persist.
    PS.: The RPD is the same.
    Error:
    Type: Error
    Severity: 30
    Time: Tue Nov 30 18:48:39 2010
    File: project/webxml/xmldocument.cpp Line: 107
    Properties: ThreadID-5832;HttpCommand-ReloadDashboard;Proxy-750129;RemoteIP-172.20.0.2;User-750129;HttpArgs-InFrameset='false',Caller='Dashboard',Embed='true',icharset='utf-8',ViewState='p4ebtdld98ugskl9i4kleog9fi',saveLangPref='true',reloadTargets='d:dashboard~p:ck7j8ndot74tso41~r:3vsqlcks5vv851l0',PortalPath='/shared/ATLASBIEE/_portal/Indicador de Informa��',Page='R01',ajaxType='iframe',_scid='mykNLlsZhtg';Impersonator-
    Location:
    saw.httpserver.request
    saw.rpc.server.responder
    saw.rpc.server
    saw.rpc.server.handleConnection
    saw.rpc.server.dispatch
    saw.threadPool
    saw.threads
    Assertion failure: pRoot at line 107 of ./project/webxml/xmldocument.cpp

    Where are the GURUS ?!?!?!?!?
    Regards,
    Guilherme.

  • MDIS assertion log: A2iMultiThread.cpp" line="254" !m_hasLock

    Hi MDM Gurus,
    Issue: MDIS services need to be restarted once a week for the automatic import to occur
    The assrtion log on our MDIS server keeps logging this message:
    <Open ts-long="14:39:46 GMT, Tuesday, April 12, 2011" ts="2011/04/12 14:39:46.703 GMT" pid="***" host="*****" compile-type="WIN32_RELEASE">
              <Assert ts="2011/04/12 14:39:46.703 GMT" tid="3084" entry-no="127015" file="..\..\..\GenericLibs\Base\*A2iMultiThread.cpp" line="254">!m_hasLock*</Assert>
    has anyone come across this? we applied Note 1321795 - MDM 5.5 SP06 Patch05 Release Note after we were advised by a previouss OSS note raised, but now its still occurring albeit less frequently of restarting the services every day as it would not import the data automatically

    this surely seems to a bug !
    if this is happening in the Production server - plz raise a high prio OSS with SAP
    btw : is the MDM server / MDIS running in a cluster ?? or single SID ?
    thanks
    -Adrivit

  • SunStudio 12. 2 throws assertion failed: 0, file ../lnk/exrttiutils.cc

    When compiling with SunStudio12 update 2 we get the following:
    Assertion failed: 0, file ../lnk/exrttiutils.cc line 215
    Since this is not part of our code base, we assume its part of the compiler support stuff. As you can see the error message does not provide us much help in finding where in our code this is occurring, any ideas? We'd love to produce a testcase but don't have clue where to begin...

    The assertion is actually coming from the runtime library libCrun.so.1, and it fires when an "impossible" situation (like a corrupted virtual table or exception record) occurs during exception handling. If this assertion happens at compile time, and not run time, some compiler component is at fault.
    Please add the following two options to the command line that resulted in the assertion:
    -filt=%none -V
    The -filt=%none prevents the verbose output (-V) from being scrambled, and the last component listed before the assertion is the one that failed. Please post your results here.
    We will then need a test case, but let's be sure what is happening first.

  • Assertion failed: 0, file ../lnk/exthrow.cc

    Hello,
    one of my programs aborts sometimes with a coredump and the following
    message "Assertion failed: 0, file ../lnk/exthrow.cc, line 338"
    I don't understand the message. Can anybody help me.
    thanks
    OS: SunOS xyz 5.8 Generic_108528-14 sun4u sparc SUNW,Sun-Fire-15000
    Forte: CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-09 2002/07/17

    Any compiler assertion is a compiler bug. To find the bug, or to determine whether it has already been fixed, we need a reproducible test case. Without a test case, there is no way other than random experimentation to find a workaround.
    - Rose

  • CC 5.9 and ../lnk/bind.cc Problem

    Hi,
    we have migrated from SunStudio11 to SunStudio12 in which CC compiler has upgraded to 5.9. After recompiling source codes with new compiler, we got the following error:
    Assertion: (../lnk/bind.cc, line 268) while processing .......
    We have encountered this problem reported in the past. But there exists a patch for this problem for CC 5.8 compiler.PATCH_ID: 121017-08 which is last updated on Feb 26, 2007.
    We assume that this patch is already included in SunStudio12 release.How can we overcome this problem? Is this a bug that still exits in CC 5.9? If so, shall we download patch for CC 5.8 on our CC 5.9? We are blocked with this problem.
    Thanx in advance
    PS:
    CC: Sun C++ 5.9 SunOS_sparcSun 2007/05/03
    OS: Solaris 10
    Message was edited by:
    sunriseloverr
    Message was edited by:
    sunriseloverr
    Message was edited by:
    sunriseloverr

    Most compiler assertions (including this one) can have different causes. The assertion is a failed consistency check, and the compiler cannot proceed. A particular assertion can be "fixed", and yet show up again when the compiler sees different source code. (I hate it when that happens.)
    You might be running into bug 6549618, present in the initial release of Studio 12. It has been fixed, and the fix will appear in the first released patch. The patch is undergoing testing now, and should be available in a few weeks.
    Here is a test case for that bug:
    class Comparator {
    template< typename Value , int Count = sizeof ( Value) > class Tree {} ;
    template< typename KeyPair > class Map {
    typedef Tree < KeyPair * > a;
    The problem was caused by sizeof in the non-type template default parameter value.
    You cannot patch Studio 12 with a patch for Studio 11.

  • Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh

    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.

    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.

Maybe you are looking for

  • Itunes 6.0.4 (3) update - wont play music + no sound on other applications

    I have auto-update on and normally all the updates seem to be good... however I cant play any songs and therefore no sound from my speakers at all. All the music etc is there, press play and nothing... I had a look at Quicktime too and again no sound

  • Vat report for Poland

    HI! I´m using the report S_ALR_87012385 - VAT Register (Poland), and it seems it work correctly, but how can i prevent the documents from being caught twice in both report's executions to the same date? there is same way for the knows that the docume

  • ANN: Next series of free FM-to-Acrobat TimeSavers 1-hour webinars

    You are invited to attend webinars in the next series of free FrameMaker-to-Acrobat TimeSavers 1-hour webinars (starting 10am PST/PDT): Better PDFs with FrameMaker-to-Acrobat TimeSavers, January 14 Effective PDF Bookmarks with FM-to-Acrobat TimeSaver

  • Error in oracle with delphi

    Does anyone have a solution for this error? Access violation at address 61CD0C28 in module 'OraClient10.Dll'. Read of address 00000084.

  • 10.4.10 crash - no recovery

    I have 10.4.10 up and running for some time. Three days ago I wanted to statup an application and my system suddenly hung. A cold reboot was the only way. Since then I cannot startup my computer anymore - it won´t pass the white screen. I went to my