Unsupported Compiler: run SonarQube on GCC based compilation database instead


I have a couple of questions regarding sonarQube ( sonar-scanner) on jenkins.
We’re operating a jenkins server to build different embedded C firmwares using different compilers. One of the stages invokes sonarQube and in most cases this works.
Now we have tried runnning a firmware that relies on the unsupported Compiler “Renesas RXCC” (not the IAR one) and issues showed up.
As far as we understand sonar-scanner is not understanding the compiler syntax. Thus both approaches using the build-wrapper and a compilation command JSON file fail.
Now we’re looking for a solution.
We believe we could invoke CMAKE to create a compilation database JSON file based on GCC-compiler instead of the Renesas CCRX compiler. The resulting make build would not work, as there would be errors during build due to the renesas compiler specific syntax in some c/h-files.
2a: Would sonarQube then be able to use this and analyse the code on GCC based compilation database JSON, even if some modules might not build due to compiler specifics (pragmas, key words etc…)?
2b: Would sonarQube be able to use this and analyse the code on GCC base, if we mock and/or remove Renesas compiler specific things with an automated script and/or additional c/h-files upfront (makeing the make-file-build build, but probably not link)?

Best Regards

SonarQube Version 9.9 (build 65466)

hi @JohannesH,

The analysis will succeed, but the quality of the analysis won’t be reliable. We won’t understand the compiler-specific extensions, which might lead to false-positive/false-negative in the code related to those extensions. It is not only a problem of extensions. Usually, the bigger problem is that each compiler has specific built-in macros, compiler flags, and system header search directories. It will be hard to get reliable analysis using this method.

Compilation is enough. If your file can be compiled with GCC, It means that we will be able to understand the code and the compilation flags. We will be analyzing the code as seen by GCC. Keep in mind that we will end up analyzing different code than the one that will end up in production using “Renesas RXCC”. Still, it is better than the first option.

If you decide to go this way, I recommend enabling S2260. It will help you understand which part of the code the analyzer doesn’t understand. It can be a good debugging tool, especially in your case.


Hi Abbas

Thanks for the helpful response. We’ll discuss which way to go.

Best regards

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.