• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 767 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler Error: "no match for ICALL" when switching from 'Debug' configuration to 'Release' configuration

dewilso4
Expert 1215 points

Other Parts Discussed in Thread: TMS320C6455

Windows 7 64-bit

CCS Version 4.1.3.00038

TMS320C6455+ on a DSK6455 (Spectrum Digital)

 

I'm trying to build a C6455 project (which references a RTSC project) in 'Release' mode, and I'm getting (what seems to be) a compiler error: "no match for ICALL".  It seems to be due to the "Optimization level -opt_level" compiler option (regardless of whether I choose level 1, 2, or 3), as I can get rid of the error if I remove this optimization entirely.  However, compiling with this optimization level would be best for my specific application.

Compiler Options which DON'T reproduce the error: -mv64+ --symdebug:none -O0 -ms3 --program_level_compile --gcc --diag_warning=225 --opt_for_speed=5

Compiler Options which DO reproduce the error: -mv64+ --symdebug:none -O3 -ms3 --program_level_compile --gcc --diag_warning=225 --opt_for_speed=5

 

Thanks in advance for any help in resolving this issue.

  • 0
    TI__Guru**** 173310 points

    Derek,

    Can you attach the source file that generates this error so we can duplicate this issue? You can preprocess the source file which will automatically bring in the necessary header file information, and you will only need to send us the one preprocessed file. http://processors.wiki.ti.com/index.php/Preprocess_Complex_Source_Code_for_Bug_Submissions

     

  • 0 in reply to AartiG
    Expert 1215 points

    I am unable to upload the preprocessed source file which causes the error, but I can attempt to email it to TI support staff if an email is given.  Thanks for the help!

  • 0 in reply to dewilso4
    TI__Guru**** 173310 points

    I will send you a friend request and start a private conversation and tell you where to email the file.

  • 0 in reply to AartiG
    TI__Guru**** 173310 points

    Derek,

    Thank you for providing the test case. This has been submitted as defect # SDSCM00038073. You may track the status of this defect by entering the bug # in the SDOWP link in my signature below.

    The only workaround I am currently aware of is removing optimization or lowering to -o0. After the compiler team analyzes the issue further, they may be able to provide additional workarounds. If so, I expect they will update the defect record in the SDOWP database.

  • 0 in reply to AartiG
    Expert 1215 points

    Thanks for the help.  I'll keep an eye on the SDOWP link.

  • 0 in reply to dewilso4
    TI__Expert 6550 points

    The internal error is due to the dereferencing the local unsigned short pointer 'tail'.  Optimization shortens the code such that the final generated expression has the return value of the _packlh2 intrinsic being converted to a unsigned short pointer that is then dereferenced.  This places the _packlh2 intrinsic in an unexpected expression thus causing the internal error.  Since a fix for this issue is most likely not going to be available until the beginning of next year, there are some workarounds.

    1. Make the local unsigned short pointer 'tail' volatile.

    2. If there are several equivalent uses of this intrinsic you could create a routine, making sure it does not inline, such as:

    #pragma FUNC_CANNOT_INLINE(tmp_func)
    unsigned short *tmp_func(UINT32 t)
    {
        return (unsigned short *)_packlh2(t, t);
    }

  • 0 in reply to ThomasS
    Expert 1215 points

    I suppose my use of _packlh2 was somewhat non-standard, but some endianness issues arising from the multi-processor architecture as well as pointer variables being different bit lengths on the different processors required some quirky workarounds.  I appreciate your looking into it and providing some workarounds.  I'll see how they work out for me.

  • 0 in reply to dewilso4
    Expert 1215 points

    Setting 'tail' to be volatile caused the compiler to throw the same error (no match for ICALL).  However, using the non-inlined function approach did work, and now I can compile, without error, at optimization level -o3.  Thanks!