We are seeing an inconsistent number of reported warnings from warnings-ng plugin. Building the very same commit multiple times gives different results:

• First build: GNU C Compiler (gcc): 106 warnings
• Second build: GNU C Compiler (gcc): 105 warnings
  11 new warnings
  12 fixed warnings
• Third build: GNU C Compiler (gcc): 107 warnings
  6 new warnings
  4 fixed warnings

This behavior makes warnings unreliable, and we cannot detect real new warnings. We couldn't find a workaround for that. This is why I prioritized this bug as "major": loss of function without workaround.

The console log contains the same 500 warnings. Because of the random order of compilation I couldn't compare them side-by-side, but I sorted both console logs, and then do a diff on the sorted logs. The diff only showed line where the build number or the number of warnings reported by the plugin was present.

The warnings in question come from a single header file that is included from multiple translation units. The compilation of each translation unit will output the (almost) same warning. These warnings will differ in the context they were included from (the include trace that says: "In file included from: ..."). My guess is that the deduplication fails to find all of them as duplicates. Depending the build order of the compilation units, it will treat different warnings as duplicates, thus giving the above mentioned "11 new, 12 fixed". This theory is also supported by the fact that when the build only uses a single thread (make -j1), the reported warnings are stable. Please note, that I don't consider building on a single thread as a workaround, that would just take too long.

I created a Git repository with a simple project that can be used to reproduce the above mentioned issue. The repository can be found at: https://github.com/tbilles/warningtest.git

Please let me know if you need any more information.