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 failure with O2 and on Windows 10 only

Part Number: TMS320F28377S

Tool/software: TI C/C++ Compiler

Hello,

here is my christmas compiler failure for you ;-)

Overview

We recently switched from Windows 7 to Windows 10 (finally). One file in our code base then refused to compile correctly in release builds.

Here are the conditions to reproduce the error:

  • C++
  • Compiler TI v18.12.4.LTS (other compilers not tested)
  • Windows 10 (the failure does not occur on Windows 7 under comparable conditions (!))
  • Optimizer on: O2 (With O1 or optimizer off the failure does not show up
  • CCS: 9.2.0.00013
  • The failure does not occur each time, only most of the time! (really, no kidding!)

Compiler command line and failure output

I stripped down the code to a (no longer usefull) minimum which still triggers the failure:

cl2000 -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -O2 --opt_for_speed=2 --fp_mode=relaxed -g --c99 --cpp_default --pending_instantiations=0 --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=coffabi --aliased_variables --remove_hooks_when_inlining --gen_cross_reference_listing --gen_func_info_listing --section_sizes=on "W:\\MotionControlLibrary\\components\\peripherals\\killer.cpp"
"W:\MotionControlLibrary\components\peripherals\killer.cpp", line 40: warning #552-D: variable "a" was set but never used

INTERNAL ERROR: C:\TI\ccs920\ccs\tools\compiler\ti-cgt-c2000_18.12.4.LTS\bin\opt2000.exe experienced a segmentation fault
                  while processing function _read_register__26ADT7320_Temperature_SensorFUi file C:\\cygwin64\\tmp\\{623ED5A4-2D7
E-461D-982E-91BFD00AFF0C}

This is caused by a defect in the TI C/C++ Optimizer.
TI Customer Support may be able to suggest a workaround to avoid this.

Upgrading to the newest version of the compiler may fix this problem.

Contact TI in the E2E support forums at http://e2e.ti.com under
"Development Tools", "TI C/C++ Compiler".  See the link titled
"Submitting an issue".

We need to see this ENTIRE error message and a complete, reproducible
test case including ALL of the command-line options.
Include the .pp file created by option --preproc_with_comment

Minimum Code example

The stripped down killer.cpp file is this:

struct CMD_byte
{
    CMD_byte(unsigned int address, bool read) :
        m_dummy_0(0),
        m_register_address(address & 0x07),
        m_rw(static_cast<unsigned int>(0)),
        m_dummy_1(0)//,
    {}

    inline   // killer!
    unsigned int to_uint16_t(void);

    unsigned int m_dummy_0             : 3,
    m_register_address             : 3,
    m_rw                           : 1,
    m_dummy_1                      : 9;
};

unsigned int CMD_byte::to_uint16_t(void)
{
    return (  m_dummy_0
                    | (m_register_address << 3)
                    | (m_dummy_1 << 7)
                    );
}


class ADT7320_Temperature_Sensor
{
private:
    void read_register(unsigned int ra);
};



void ADT7320_Temperature_Sensor::read_register(unsigned int ra)
{
    CMD_byte cmd(ra, true);

    unsigned int a[3];
    a[0] = cmd.to_uint16_t();
}

The --preproc_with_comment only version looks exactly the same since no includes or macros are used in the minimum example.

Workaround

Our workaround for now is to remove the "inline" line marked with "// killer!". But this is rather dissatisfying, we would like to know whats going on.

Further observations:

  • The code above triggers the failure approximately 9 times out of 10 runs with the exact same input
  • If the "& 0x07" from line 5 of the code is removed then the failure is not triggered
  • If the line 23 is removed completely then the failure happens less likely (approx 5 out of 10 times)
  • If the array a is replaced by a non array unsigned int then the failure is not triggered

This is very unexpected and seems rather arbitrary...

  • Thank you for reporting this problem.  You clearly put a lot of effort into cutting down the test case, so thank you again.  I can reproduce the same behavior.  Even the part where it fails intermittently.  I submitted the entry CODEGEN-7011 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