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/TMS320F2812: Local variable gets overwritten unintentionally (might be a compiler error)

Part Number: TMS320F2812

Tool/software: TI C/C++ Compiler

Support Path: /myTI & TI store/myTI account/

Hello,

when switching from the 16.9.6 LTS compiler to the new 18.1.1 LTS compiler one of my functions started to behave erroneously. Since I cannot show you the complete code I was able to strip the problem down to a minimum example which still shows the erroneous behavior.

Observation: The value of a local variable (v in the example below) of a function is modified unintentionally by the call to the va_start() macro. This leads to errors when v is used after the va_start() macro.

Here is the minimum example with comments which tell the unexpected / erroneous behaviour. Below the code you will find more remarks.



// should be compiled without any optimization to show erroneous behaviour

#include <stdarg.h>

int v1 = 0;                      // global vars to log the erroneous / unexpected behaviour
int v2 = 0;

void f( char const* fmt, ... )   // a function, originally intended for debug printing...
{
    va_list params;
    //register                     // If v is declared with the register keyword then v is still stored in the ACC.AL register only, 
                                   // but it is not overwritten by   va_start() below
    int v;                       // v is not allocated as a variable, at least it does not show up in the Debuggers Variables view


    {                            // Required to show erroneous behavior. Could be a loop or a condition or the like.

        v = 42;                  // This only affects the ACC.AL core register

        v1 = v;                  // Global v1 is set to 42 as expected
va_start( params, fmt ); // This overwrites the ACC core register THIS IS THE KILLER LINE!!!
v2 = v; // Unexpected: some arbitrary value is written to v2!!! int i; // Required to show erroneous behavior. If this is declared in the outer scope then the erroneous behaviour does not show up // code using the params and i would go here but is not required to show the erroneous behavior } } int main(void) { f( "test" ); // error happens within call to f()
// determine "result": both v1 and v2 should have been set to the same value 42 if ( v1 == 42 && v2 == 42 ) { // we should get here while (1) ; } else { // but we usually get here! while (1) ; } }

Remarks:

  • The code above does not make any sense, please ignore that. As said, it is the stripped down version of my original code which still shows the erroneous / unexpected behaviour
  • The error shows up when compiled without any optimization
  • The local vairable v is not allocated on the stack. Instead when initialized the value of the ACC.AL core register gets set to the initialization value.
    (This is not actually an error, but somewhat unexpected since compilation is without (register) optimization)
  • The value of the local variable v stored in ACC.AL gets overwritten by some arbitrary value by the call to the va_start() macro.
  • Not sure if the error has anything to do with the va_start() macro at all. Maybe any other construct, that has side effects to the ACC core register, could trigger the erroneous behaviour as well
  • The error shows up only if there is an inner block with the declaration of an inner only variable after the va_start() macro (i in the minimum example above)
  • The original problem (in my real code) shows up in the 18.1.1 compiler only. But the minimum example code above shows the error in 16.6.9 as well as in 18.1.1
  • When putting the little used "register" keyword ahead of the local variable v in the minimum example above (as shown in the code comments) then the function behaves as expected
  • When putting the "register" keyword ahead of the real local variable in my original (a little bit more complex) code, then the compiler 18.1.1 terminates with an internal error:
    >> Compilation failure
    
    subdir_rules.mk:9: recipe for target 'main.obj' failed
    
    	>> ../main.c, line 71: INTERNAL ERROR: >>>Register allocation failed:
    
    DebugPrintf
    
    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!
  • Develompent OS is windows 7 Enterprise 64 bit
  • CSS is version 7.3.0.00019
  • The complete console output for compilation is:

**** Build of configuration Debug for project bug_2314 ****

"C:\\ti\\ccsv7\\utils\\bin\\gmake" -k -j 8 all -O
'Building file: ../main.c'
'Invoking: C2000 Compiler'
"C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/bin/cl2000" -v28 -ml -mt --opt_for_speed=0 --include_path="C:/Users/xxx/Documents/workspace/bug_2314" --include_path="C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/include" --advice:performance=all -g --diag_warning=225 --diag_wrap=off --display_error_number --preproc_with_compile --preproc_dependency="main.d_raw"  "../main.c"
"../main.c", line 26: warning #179-D: variable "i" was declared but never referenced
"../main.c", line 10: warning #552-D: variable "params" was set but never used
'Finished building: ../main.c'
' '
'Building target: bug_2314.out'
'Invoking: C2000 Linker'
"C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/bin/cl2000" -v28 -ml -mt --opt_for_speed=0 --advice:performance=all -g --diag_warning=225 --diag_wrap=off --display_error_number -z -m"bug_2314.map" --heap_size=0 --stack_size=0x400 --warn_sections -i"C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/lib" -i"C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.1.LTS/include" --reread_libs --diag_wrap=off --display_error_number --xml_link_info="bug_2314_linkInfo.xml" --rom_model -o "bug_2314.out" "./main.obj" "../2812_RAM_lnk.cmd"  -llibc.a
<Linking>
'Finished building target: bug_2314.out'
' '

**** Build Finished ****




  • Thank you for letting us know about this problem, and submitting a concise test case.  I can reproduce the problem.  I filed CODEGEN-4634 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George