CGT6000 - 6.1.22 Internal Error and Abort

OK. The work-around I have is to call _mem4(addr)>>16 instead of the _mem2(addr) call. Two separate single-byte accesses work as well.

I suppose if someone were to look at this issue, they would request sample code from me. That may be difficult to provide since I use the _mem2() intrinsic hundreds of places in the project, but just this one instance gives me trouble. It must have something to do with pipelining previous/future instructions. Would be willing to provide the entire project, but it would be a pain for someone to compile since I don't build under CCS (external makefile).

SteveM said:

That may be difficult to provide since I use the _mem2() intrinsic hundreds of places in the project

I don't think it would be that bad.  Isolate the function with problem mem2 into a file. Then preprocess that file as described here.  That, plus the compiler command line, should be enough for us to reproduce it.

Thanks and regards,

-George

Matching occurs long before attempting to pipeline, so we probably won't need much of the surrounding code to reproduce this.

Does this fail even if you don't use optimization?

What does the code on line 65 of sourcefile.c look like?  Be sure to provide the type of each variable involved.

You should try one of the later versions of the C6000 compiler; the 6.1.x series is quite old.

As stated above, the compiler crashes while processing a header file. More specifically, on a structure defined in a header file. Is this code inlined? Here is the code with no external references:

#define UNALIGNED_ACCESS2(ptr)   (_mem2((void *)(ptr)))

#define UNALIGNED_ACCESS4(ptr) (_mem4((void *)(ptr)))
#define UNALIGNED_ACCESS8(ptr)   (_mem8((void *)(ptr)))

typedef unsigned char         byte;

typedef enum
{   tlsVer_SSH30,      // SSH version 3.0 {3, 0}
    tlsVer_TLS10,      // TLS version 1.0 {3, 1}
    tlsVer_TLS11,      // TLS version 1.1 {3, 2}
    tlsVer_TLS12,      // TLS version 1.2 {3, 3}
    tlsVer_Last        // Terminal value.
} tlsVer_e;

struct TlsPrmSecret_s
{
    // Definitions.
#define  CLIVER_OFFSET    0x00
#define  RANDOM_OFFSET    (CLIVER_OFFSET + 0x02)
#define  HEADER_SIZE      (RANDOM_OFFSET + 0x2E)

    // Data members.
    byte      byteArray[HEADER_SIZE];

    // Access functions.
    // NOTE: Data movement must be performed using unaligned
    // stores/loads to/from memory.
    tlsVer_e         ClientVersion     (void)               {   // The original line was commented/replaced due to compiler internal error.
                                                                switch (UNALIGNED_ACCESS2(&byteArray[CLIVER_OFFSET]))
                                                                //switch (UNALIGNED_ACCESS4(&byteArray[CLIVER_OFFSET]) >> 16)
                                                                {   case 0x0300: return tlsVer_SSH30;
                                                                    case 0x0301: return tlsVer_TLS10;
                                                                    case 0x0302: return tlsVer_TLS11;
                                                                    case 0x0303: return tlsVer_TLS12;
                                                                    default:     return tlsVer_Last;
                                                                }
                                                            }
    void             ClientVersion     (tlsVer_e val)       {   switch (val)
                                                                {   case tlsVer_SSH30: UNALIGNED_ACCESS2(&byteArray[CLIVER_OFFSET]) = 0x0300; break;
                                                                    case tlsVer_TLS10: UNALIGNED_ACCESS2(&byteArray[CLIVER_OFFSET]) = 0x0301; break;
                                                                    case tlsVer_TLS11: UNALIGNED_ACCESS2(&byteArray[CLIVER_OFFSET]) = 0x0302; break;
                                                                    case tlsVer_TLS12: UNALIGNED_ACCESS2(&byteArray[CLIVER_OFFSET]) = 0x0303; break;
                                                                    default:           UNALIGNED_ACCESS2(&byteArray[CLIVER_OFFSET]) = 0x0000; break;
                                                                }
                                                            }
    byte *           RandomPtr         (void)               {return &byteArray[RANDOM_OFFSET];}

    // Undefinitions.
#undef  CLIVER_OFFSET
#undef  RANDOM_OFFSET
#undef  HEADER_SIZE
};

"Does this fail even if you don't use optimization?"

Good question. No.

"What does the code on line 65 of sourcefile.c look like?"

See above.

 "You should try one of the later versions of the C6000 compiler; the 6.1.x series is quite old."

As I said, the old 6.1.x compiler was working perfect for us until this. It looks as though this series is still supported as the latest release occurred July of this year. I'm not sure if switching to 7.x.x is right for us. Would it be seamless? Our project is based on DSP/BIOS (old API) and .out is COFF to hex6x to binary output file directly loaded into memory.

I can't reproduce the problem; I still need the command line options.

The functions might or might not be inlined.  If you're not using the optimizer, they will not be inlined.  There won't even be any code at all in the output assembly file unless there is some call to one of these member functions.  I stuck this at the bottom:

TlsPrmSecret_s thing;
tlsVer_e member1(void) { return thing.ClientVersion(); }
void member2(tlsVer_e val) { thing.ClientVersion(val); }
byte *member3(void) { return thing.RandomPtr(); }

Here is the output text during compilation:

/opt/TI/TI_CGT_C6000_6.1.22/bin/cl6x -q -o3 -fr"./Release" -i"/opt/TI/csl_c6455/inc" -i"/opt/TI/c64plus/dsplib_be/include" -d"_RELEASE_" -me -mv6400+ "tls.cpp"

 >> tls.h, line 945: INTERNAL ERROR: no match for ASG

This may be a serious problem.  Please contact customer support with a description of this problem and a sample of the source files that caused this INTERNAL ERROR message to appear.

Cannot continue compilation - ABORTING!

OK. I think I have what you need to cause this. It requires another structure and the correct access steps. Remove the lines that you stuck at the end and replace with the following, then compile according to the options provided earlier (I don't believe you need the include paths).

struct TlsPrmSecretPkcs1_s
{
    // Definitions.
#define  LENGTH_OFFSET    0x00
#define  PKCS1_OFFSET     (LENGTH_OFFSET + 0x02)
#define  CONST_OFFSET     PKCS1_OFFSET
#define  PS_OFFSET        (CONST_OFFSET + 0x02)
#define  HEADER_SIZE      (PS_OFFSET + 0x08)

    // Data members.
    byte      byteArray[HEADER_SIZE];

    // Access functions.
    // NOTE: Data movement must be performed using unaligned
    // stores/loads to/from memory.
    ul                Length     (void)        {return UNALIGNED_ACCESS2(&byteArray[LENGTH_OFFSET]);}
    void              Length     (word val)    {UNALIGNED_ACCESS2(&byteArray[LENGTH_OFFSET]) = val;}
    byte *            Pkcs1Ptr   (void)        {return &byteArray[PKCS1_OFFSET];}
    bool              TestPkcs1  (void)        {return ( (256 >= Length())                                       &&
                                                         ((sizeof(TlsPrmSecret_s)+11) <= Length())               &&
                                                         (0x0002 == UNALIGNED_ACCESS2(&byteArray[CONST_OFFSET])) &&
                                                         (0x00 == *((byte *)DataPtr() - 1)) );}
    TlsPrmSecret_s *  DataPtr    (void)        {return (TlsPrmSecret_s *)(Pkcs1Ptr() + Length() - sizeof(TlsPrmSecret_s));}

    // Undefinitions.
#undef  CLIVER_OFFSET
#undef  RANDOM_OFFSET
#undef  HEADER_SIZE
};


int                 junk;
TlsPrmSecret_s *      pmsPtr;
TlsPrmSecretPkcs1_s thing;
pmsPtr = thing.DataPtr();
if (pmsPtr->ClientVersion() == tlsVer_TLS10)
{   junk = 0;
}

I see, now, the #undef statements at the end of the second structure are incorrect. Fixing them, however, does not solve the issue.

I still can't reproduce it.  What are the types of ul and word?  I presume "ul" is "unsigned long", but I'm not sure about "word."  The code at the bottom won't compile because it's not in a function.  I made some adjustments to get it to compile; I have attached the code I'm using.

6661.xx.cpp

Sorry, I missed those odd types and meant to scrub them. I changed them to our definition (they are legacy definitions from a different processor).

Also, I changed the object declarations to be local since that is how they are in my project. If this doesn't cause the error, then I don't know, there must be object-file or global optimizations coming into play and I would need to provide a much wider sampling of the project.

I still can't reproduce it.  Does the cutdown crash when you compile it with either 6.1.12 or 6.1.22?

Because you are using -o3, the function could be inlined, and unfortunately there's no way to know which call site is involved.  Try compiling your larger program with -o1 to see if the problem still occurs.  While you're at it, try -o2.

OK. This should definitely do it. func() was being completely optimized away (at -o3) because there were no side effects. I added this exact file to my project and compiled it alone. The error occurs and should for you, as well.

Yes, I can reproduce it.  Thank you for the test case.

The good news is that this is fixed in 7.4.0.  The bad news is that it's not fixed in the latest release from the 6.1.x branch, which is 6.1.22.  Let me try to find an existing defect report for this bug.

I would like to revisit a question I asked earlier. Would it be seamless to switch compiler versions from 6.1.x to 7.x.x? I believe I investigated this a while ago and hesitated to do it but I don't remember why.

SteveM said:

Would it be seamless to switch compiler versions from 6.1.x to 7.x.x?

Your chances are very good.  Some insight into this can be found in this wiki article.

Thanks and regards,

-George

"Your chances are very good.  Some insight into this can be found in this wiki article."

Translation: I don't know and here is a link confirming it. ;-)