• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1380 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/TMS320C6670: No warning on using uninitialized variable

Victor Kazmirenko
Guru 13202 points
Part Number: TMS320C6670

Tool/software: TI C/C++ Compiler

Hello!

Cross-compiling piece of code with Visual Studio I have noticed a warning on use of uninitialized variable, which was not reported by C6000 compiler. I've noticed it in somewhat larger piece masking the bug, but it can be reduced to something like

float sample(short *x)
{
    float sum, a = 0.5, y, b;
    int i, cnt = 100;

    for ( i = 0; i < cnt; i++ )
    {
        if ( b < 5) a += x[i]+3.0/4;
        else        a -= x[i]+3.0/4;
        sum += a;
    }
    y = sum / (float) (cnt);
    return y;
}

Compiler does not notice the 'sum' was not initialised prior use.

Complete command line was

'Invoking: C6000 Compiler'
"D:/TI/ccsv7/tools/compiler/c6000_7.4.23/bin/cl6x" -mv6600 --abi=eabi -O3 -g --include_path="D:/TI/ccsv7/tools/compiler/c6000_7.4.23/include" --include_path="D:/TI/pdk_C6670_1_1_2_6/packages/ti/csl" --include_path="D:/TI/pdk_C6670_1_1_2_6/packages/ti/drv/pcie" --include_path="D:/TI/pdk_C6670_1_1_2_6/packages/ti/drv/cppi" --include_path="D:/TI/pdk_C6670_1_1_2_6/packages/ti/drv/qmss" --include_path="D:/TI/pdk_C6670_1_1_2_6/packages/ti/platform" --include_path="D:/TI/pdk_C6670_1_1_2_6/packages/ti/drv/fftc" --include_path="D:/TI/dsplib_c66x_3_4_0_0" --define=_L2SRAM2_4_ --define=_PCIE_MSI_ --define=_PCIE_BM_DMA_ --define=_FFT_WINDOW_COMPENSATION_ --define=_INTR_MASK_REG_NOT_IMPLEMENTED_ --define=_REBOOT_ENABLED_ --display_error_number --diag_warning=225 --debug_software_pipeline --optimizer_interlist --opt_for_speed=4 --gen_opt_info=1 -k --src_interlist --preproc_with_compile --preproc_dependency="frame.d_raw" --obj_directory="lte" --cmd_file="configPkg/compiler.opt" "frame.c"

Interestingly, if one comment out 'if' statement in the loop, compiler recognizes empty loop and removes it, but still does not see uninitialized 'sum'. Only when for loop removed compiler reports the problem with sum.

float sample(short *x)
{
    float sum, a = 0.5, y;
    int i, cnt = 100;

    for ( i = 0; i < cnt; i++ )
    {
        sum += a;
    }
    y = sum / (float) (cnt);
    return y;
}

I'd like to hear from compiler experts, isn't that a bug?

Thanks.

  • 0
    Guru 39210 points
    Yes, its a bug.
    No, the compiler is not obligated to catch it.
    Back in the dark ages, this was why Lint was required.
  • 0
    TI__Guru**** 239845 points

    rrlagic said:
    I'd like to hear from compiler experts, isn't that a bug?

    No, it is not a bug.  The C and C++ standards documents are almost completely silent about diagnostics.  Things like what diagnostics are required, and what they should say, are left to each compiler implementation.  

    The TI compiler lacks the ability to see this particular instance of a variable not being initialized before it is used.  

    There are many tools specifically dedicated to this purpose.  I recommend you perform a search on the term static analysis tools.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 39210 points
    I meant a bug in the user program, not the compiler!
  • 0 in reply to George Mock
    Guru 92251 points

    George Mock said:
    The TI compiler lacks the ability to see this particular instance of a variable not being initialized before it is used.  

    Given that the TI compiler supports MISRA-C:2004 checks I enabled checking of rule 9.1 "All automatic variables shall have been assigned a value before being used" and with the example code the TI C6000 v8.2.2 compiler didn't report a warning.

    Has this code shown a limitation in the MISRA-C:2004 rule 9.1 checks?

  • 0 in reply to Chester Gillon
    Guru 13202 points

    Keith, George,

    Thank you for clarification. Somehow I had a feeling that compiler tries to diagnose such a condition, and thus asked isn't the situation a defect of compiler. Now I know the compiler has no strict duty to do that, and even if someone seen such a warning one should not rely on it for the rest of the code. I am just fine with such an explanation and was going to close the thread as resolved. But Chester, you really made catch of the game :-) I tried myself and do confirm, that MISRA-C:2004 rule 9.1 does not catch the bug with 7.4.23 either.

    Instead, it produces ton of waning in situations like

    ...
ret_type ret_var;
...
some_function( arguments, ..., &ret_var);

    which is technically correct, but actually depends on function guts. May I ask to comment that against clarification of 9.1 in www.misra.org.uk/.../viewtopic.php ?

    Thank you.

  • 0 in reply to Victor Kazmirenko
    TI__Guru**** 239845 points

    The file misra.txt is part of the compiler install.  It appears in the root directory.  This file contains details regarding the checking of various MISRA rules.  It talks about one limitation of rule 9.1, but not this particular one.  I filed CODEGEN-4089 in the SDOWP system to have the misra.txt entry on rule 9.1 changed.  It will also discuss situations, like the ones in this thread, where violations of the rule cannot be detected.  You are welcome to track this defect with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 13202 points
    George,
    Thank you for your efforts. Though I could not track CODEGEN-4089 there, I believe required clarifications will be placed later. Perhaps we spent too much time discussing the job compiler not obligated to do.
    Thanks again.