C++20 commands in libc++ from IAR Build not recognized

SonarQube Server / Community Build
, , ,
1

Hello everyone,

the IAR compiler added support for some c++20 symbols in libc++ (We upgraded from 9.50.1 to 9.70.2), but they aren’t recognized by SonarQube yet. A specific example is the use of std::bit_cast:

  • no member named ‘bit_cast’ in namespace ‘std’

We have included libcpp in our project using std::bit_cast and IAR is able to compile without any error.

Is it possible to configure SonarScanner to enable support for these new symbols? Or do you potentially have a clue how else this problem could be fixed?

Thanks in advance!

Version Information:

  • SonarQube server 2025.4.3.113915
  • SonarScanner 5.0.1.3006
  • IAR EWARM 9.70.2
3

Hi @maufri ,

would you be able to share the analysis log and the build-wrapper-output/compile_commands files? I am sending you a private message where you can share.

5

Hi @mpaladin

I have shared some log files in the DM channel as you mentioned. The log output of sonar-scanner revealed a general issue with analysis of the libc++ dependency since we updated from EWARM 9.50.1 to 9.70.2. Are you planning to continue looking into this issue?

Thank you and kind regards.

6

Hi @maufri ,

sorry about the delay, I am going to have a look at it in the next days. Thank you for your patience.

7

Hi @mpaladin

before continuing this thread I’ll place your response from the DM here for context:

The issue comes from the fact that the compiler claims to be on C++17, see #define __cplusplus 201703L in the probe in the scanner log, and at the same time the libcpp that is embedded is using c++20 features and that is the reason why you are seeing the parsing errors.
From the official documentation:

Note that __cplusplus is still defined to 201703L (but individual feature testing macros are updated
according to their respective supported level. For example, __cpp_constexpr is defined to 202002L).

This is not a standard practice, they should bump __cplusplus to c++20 version.

Also, I don’t see an option to force the c++ standard. You may want to open a ticket to IAR.

8

I have raised the issue at IAR support, where they claim conformity to C++ with their approach:

The C++ standard defines __cplusplus as a conformance indicator, not a feature-by-feature capability flag. Its value simply shows the highest C++ standard revision the compiler claims to fully support. It is common for compilers to report different values for __cplusplus and for feature-specific macros. This is why preprocessor macros tied to specific C++ language and library features are used.

The supported c++20 features are configured in arm/inc/libcpp/version. E.g. bit_cast is configured in this section with the __cpp_lib_bit_cast macro:

// IAR
#if __cpp_concepts >= 202002L
# define __cpp_lib_concepts                             202002L
#endif
#if __cpp_constexpr_dynamic_alloc >= 201907L
# define __cpp_lib_constexpr_dynamic_alloc              201907L
#endif

#if defined(__IAR_SYSTEMS_ICC__)
# define __cpp_lib_type_identity                        201806L
# define __cpp_lib_bit_cast                             201806L
# define __cpp_lib_is_constant_evaluated                201811L
# define __cpp_lib_remove_cvref                         201711L
#endif

I already experimented with different configurations in sonar-project.properties by either setting

sonar.cfamily.customPreprocessor=#define __cpp_lib_type_identity 201806L\n#define __cpp_lib_bit_cast 201806L\n#define __cpp_lib_is_constant_evaluated 201811L\n#define __cpp_lib_remove_cvref 201711L

and

sonar.cfamily.reportingCppStandardOverride=c++20

but with no improvement. Also when using Compile-Commands, Sonar-Scanner doesn’t allow adding custom PreProcessor Defines: java.lang.IllegalArgumentException: The property sonar.cfamily.customPreprocessor (...) is not supported in Compile-Commands mode. Another test I did was to define the symbols in IAR’s Preprocessor settings, which added the feature test macros to compile_commands.json, but still with no improvement.

My question now is, can we inform Sonar-Scanner in some other way on what additional feature test macros are enabled in order to have c++20 features correctly analyzed in libcpp?

9

Hi @mpaladin,

unfortunately, I am still without solution regarding the analysis of c++20 features. IAR support stated that you could help by pin-pointing a specific feature that might not align with the integration in IAR ewarm:

In this case, SonarQube should be able to explain how they handle these macros. If they can point to a specific feature that does not align with the macros or with the documented supported C++20 features in the IAR development guide, we can take a closer look.

Please see “Overview-Standard C++” and “Supported C++20 features” in “Help > C/C++ Development Guide" for more information.

Is this potentially something, that you could help with, so I can have IAR further investigate this issue?

Thanks and kind Regards

Maurus

12

Hi @maufri, and thank you for sharing the feedback with us, this is really helpful.

We have discussed this in the team, and we created an internal ticket to improve our support in this case.

Given that IAR doesn’t provide a flag to set the c++ version, I can only suggest the following workarounds (if they are possible) for the time being:

  • Use the older version of IAR
  • Analyze by building the code using a different toolchain (if the codebase supports that)
  • Use AutoConfig mode

Best regards,
Michael

15

Hi @michael.jabbour,

thank you for continuing to look into this. I will try to find a suitable workaround, though the proposed options are currently not viable to apply in our CI pipeline. More likely we will isolate the issues to a single file location for now, where we can accept a single instance of the issue.

I’d be happy to hear when there is an update which allows full compatibility again with newer IAR releases :slight_smile:

Thanks again and kind regards.

Maurus