Microsoft extension activated by "/openmp" compiler option is not supported - DE Upgrade

SonarQube
1

Hi,

we are using SonarQube DE, and I have upgraded SQ (9.0.1 → 9.3.0) as well as sonar-scanner (4.6.2 → 4.7.0) and build-wrapper to the latest version.

The log file has messages: “WARN: Microsoft extension activated by “/openmp” compiler option is not supported, skip analysis of files:” and 99% of the issues are gone… ::confused:

We had openmp active before, so I assume that it is not supported anymore… What should I do?

Your help is greatly appreciated!
Kornelia

2

Hello @kornelia,

OpenMP was never supported. We didn’t use to exclude files using it explicitly and now we do.

  • If not all your files really use OpenMP consider setting the option /openmp only on the one that strictly needs it.

  • If the files that use openMP can be isolated and not leaked into header files that would also help reduce the number of files that need the flag.

Considering that the analyzer doesn’t understand OpenMP construct how was the quality of the analysis? was it useful?

Let me know if the above suggestion helps increases the coverage of the analysis.

Thanks,

1 Like
3

Hello @Abbas ,

thanks a lot for the clarification! I will have to look into it… we probably had some warnings before the upgrade too, but we didn’t have time to investigate them yet :frowning:

I will get back to you when we figure out what kind of workaround we could use. Just one more question: in the meantime could we maybe use the older build-wrapper & sonar-scanner (4.6.2) with SonarQube 9.3.0 ?

Thanks again for your help!

Cheers,
Kornelia

4

@kornelia,

No, It is not a change in the build-wrapper or sonar-scanner. It is the SonarQube 9.3.0 Cfamily analyzer.

We can try to find a workaround if my above suggestion doesn’t unblock you.

Also, feel free to create “suggest new features” post to see if there is any traction around OpenMP.

Thanks,

5

Hi,

We are having almost the same problem:

WARN: Microsoft extension activated by “/openmp-” compiler option is not supported, skip analysis of files:

Please note the MINUS SIGN on the openmp flag. OpenMP is turned off by this but we still get the same issue. This looks to me like a bug in SonarQube 9.3.

Best regards
Martin Tillmann

2 Likes
6

Hello @mpt,

Yes, this is a bug. We missed it because it is not documented in MSVC that you can use /openmp-.

We will fix it soon. until then you can remove /openmp- and /openmp from your build command to unblock.
Ticket: [CPP-3633] /openmp- should be supported - SonarSource
Thanks,

2 Likes
7

Hello,
I have the same issue in a build environment. We need to have OpenMP active because we use it in an Azure build pipeline where we do the build, sonar qube analysis and the testing. Without OpenMP things run good enough, we get the build and analysis done. The downside is that the test cases run now as slow as they can do… running them with sources that have OpenMP support is what we are supposed to do.
In conclusion, supporting OpenMP is a needed feature in multiple use case scenarios.
Thank,

2 Likes
8

Hi Abbas,
I just found out that for our project where we set /openmp globally all our files would get excluded from the analysis once we upgrade from sonarqube 8 to latest 9.

If I want to use sonarqube 9, I see these options now:

  1. Dont’ set /openmp flag globally, but only on the targets that use it, following modern cmake guidelines ( OpenMP · Modern CMake ). Then I would still exclude a whole library from the analysis if just one component uses it. And especially these libraries are the ones where I really don’t want to miss sonarqube analysis.
  2. I could also follow your suggestion and set the flag on a per file level. Then still important code is left out from analysis, but it would be a smaller amount. On the other hand, the cmake files become larger and harder to maintain.
  3. I can also add a configuration option to compile the project without openmp support just for the build on which I run the sonar analysis. (It needs it separate build with the build-wrapper anyway). The source code wouldn’t really change as OpenMP seems to be designed in a way that you can still compile openmp-enabled code without it and then I end up with a version of the program running things in serial. Then I get the largest sonarqube coverage.

I’m clearly tending to option 3, basically undermining your decision to exclude files that use openmp. So far I didn’t encounter any false positive issues in sonarqube analysis related to code that uses openmp. I have to admit though that we are only considering issues in new code.

Would it make a difference to the scanner whether the /openmp flag is enabled or not when it analysis code with openmp directives?
Assuming it doesn’t make a difference, could you reconsider the choice of excluding whole files?
Maybe a warning that is shown inside sonarqube on top of the anaylzed file would suffice?

For context, a few details about the project

  • actively developed software with lots of legacy code (~10 years old)
  • 80k LOC in ~ 1600 files
  • 9 files that use omp directives, usually “#pragma omp parallel for”, sometimes with some additional parameters
2 Likes
9

I browsed those 9 files again for false positive sonarqube issues related to openmp, but couldn’t find anything. They were analysed using Sonarqube 7.9.5.

1 Like
10

Hi @jsinge, @Ionut_Verzea,

Context:
We never intentionally supported OpenMP. We just didn’t handle the /openmp flag before. Our analyzer doesn’t understand its construct. This can lead to some false-positive reports around it. Since it was never the intention to support it, we decided to exclude it.

Unfortunate side effects:
If you have a header file that uses OpenMP and it is included everywhere your entire project is excluded. even if your source file doesn’t use these constructs.
Note: we have the same approach for other Microsoft extensions like /clr and /ZW.

Current recommendation:

  • if your code compiles without /openmp, just don’t use it for the analysis build.
  • If you have one build for analysis and production then you can consider configuring the analysis with a compilation database without /openmp this way you don’t need to build twice to disable OpenMP :https://blog.sonarsource.com/alternative-way-to-configure-c-and-cpp-analysis/
  • Separate the code that relies heavily on OpenMP and don’t analyze that code.
  • If you want to analyze code that relies on openMP even though the experience might not be great(depending on your case, no validation is done on our side) and you cannot use the compilation database and you need OpenMP for your code to compile. You can just post-process the build-wrapper JSON to drop the /openmp flags from the commands in it and check if it impacts the analysis result for your project.

We are considering replacing exclusion with a warning this will require some validation and it will not be in SQ 9.4(should be available on Monday).

Let me know if you have further questions,

1 Like
11

Hi Abbas,
thanks for the quick reply! Your recommendations sound quite useful, I’ll take a further look.

12

@mpt, @Abbas,

Hello Everyone,

this helps us further, thanks a lot! We excluded the files and after that still got the warning messages, but I did not notice the MINUS SIGN :frowning: And since I moved to another team I had to hand it over to my colleagues to investigate the issue further (but I assume that they did not have enough time…)

So thank you!
Kornelia

13

Hi @Abbas,

I just confirmed that the workaround we use( added a configuration option to compile the project without openmp support just for the build on which we run the sonar analysis) would work if this bug ([CPP-3633] - Jira) would be fixed… (I needed to remove “/openmp-” flags manually…)

Could you tell me when it is expected to be fixed?

Could you give an update on this? Is it possible that you will have some change in SQ 9.5 regarding OpenMP?

Thanks!

Cheers,
Kornelia

14

Hi @kornelia,

  1. CPP-3633 will be part of SonarQube 9.5
  2. For supporting /openmp, this one is more complex and has proper workarounds. I don’t have ETA. Maybe if enough people are interested in OpenMP Support or better solution for OpenMP users - #2 by Geoffray we can consider implementing proper support for OpenMP

Thanks,

15

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