• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1239 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/CCSTUDIO-MSP: TI-Compiler 18.1.1-18.1.3 - Incorrect definition for __cplusplus when compiling for C++14

Quinn Mikelson
Prodigy 190 points
Part Number: CCSTUDIO-MSP
Other Parts Discussed in Thread: MSP430FR5969

Tool/software: TI C/C++ Compiler

Using standard CCS project, project compiles and runs correctly, CCS version: Version: 8.1.0.00011

Target: MSP430FR5969

Compiler build flags:

-vmspx --data_model=large -O3 --opt_for_speed=0 --use_hw_mpy=F5  --define=__MSP430FR5969__ -g --c99 --c++14 --printf_support=full --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --verbose

Linker build flags:

-vmspx --data_model=large -O3 --opt_for_speed=0 --use_hw_mpy=F5 --define=__MSP430FR5969__ -g --c99 --c++14 --printf_support=full --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 -z -m"msp430_battery_controller.map" --heap_size=400 --stack_size=400 --cinit_hold_wdt=on --priority --reread_libs --diag_wrap=off --display_error_number --warn_sections --xml_link_info="msp430_battery_controller_linkInfo.xml" --use_hw_mpy=F5 --rom_model

Symptoms:

  • std::integer_sequence<> (C++14) is not listed in Content Assist, <utility> has been included
  • Navigating to integer_sequence definition in <utility> shows macro #if _LIBCPP_STD_VER > 11 evaluating to FALSE

_LIBCPP_STD_VER source declaration query brings me to __config (line 1075)

#ifndef _LIBCPP_STD_VER
# if __cplusplus <= 201103L
# define _LIBCPP_STD_VER 11
# elif __cplusplus <= 201402L

Here __cplusplus evaluates as  201103L and therefore defines parsing to follow C++11 definitions only.

The only workaround I have found is manually defining macro __cplusplus as 201402L in Project -> properties -> C/C++ General -> Preprocessor Includes -> GNUC++ -> CDT User Settings

Note: This is NOT an acceptable solution

  • 0
    TI__Guru**** 251620 points

    I am confident the compiler is processing your code correctly.  To see that, add the option --gen_preprocessor_listing, and build one of the source files which contains the problem code.  A file with the extension .rl is created.  To understand that file, please read the documentation on --gen_preprocessor_listing in the MSP430 compiler manual.  You will see that C++14 is in effect.

    That alone does not mean your problem is resolved.  But it does mean the compiler is not part of the problem.  Once we are sure of that, we can move on from there.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 190 points

    Let me reiterate:

    Using standard CCS project, project compiles and runs correctly, CCS version: Version: 8.1.0.00011

    The compiler was never the problem. The issue is with the preprocessor. 

    Here is the parser log for __config: __config_parser.log

    On line 3085, you can clearly see __cplusplus=201103L, but C++14 additional templated functions compile correctly

  • 0 in reply to Quinn Mikelson
    TI__Guru**** 251620 points

    Quinn Mikelson said:
    The compiler was never the problem.

    I'm sorry I overlooked that.

    Quinn Mikelson said:
    The issue is with the preprocessor. 

    That's a good guess. The problem is with the code indexing feature of CCS.  Because that component is not owned by the compiler development team, I am not as familiar with it.  I filed the entry CCSIDE-3394 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thank you for notifying us of this problem.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 190 points
    That's what I was looking for, Thank you George!
    I would suggest that your moderators not close this and other unresolved issue topics, regardless of inactivity. It makes searching your forums and finding answers repetitive and it makes troubleshooting feel futile.

    -Quinn
  • 0 in reply to Quinn Mikelson
    TI__Guru**** 251620 points

    Quinn Mikelson said:
    I would suggest that your moderators not close this and other unresolved issue topics, regardless of inactivity. It makes searching your forums and finding answers repetitive and it makes troubleshooting feel futile.

    Please elaborate.  For instance, what goes wrong when searching closed issues for information relevant to your situation?

    Thanks and regards,

    -George