Potential problem with -Wunreachable-code

Project Infrastructure LLVM Dev List Archives
#1

Hello, hopefully this is the correct place to ask this...

We use distcc with clang++ and I have recently added -Wunreachable-code to our set of warnings. The problem I am seeing is the compile fails with (valid) unreachable code warnings on the slave, but passes (no warning) locally. All machines have the same compiler version

clang version 8.0.1-svn369350-1~exp1~20190820121219.79 (branches/release_80)

Distcc takes the compile line, removes -o <output> and replaces it with -E and sends the preprocessed result to the slave where it is compiled without any -I, -isystem or -D options. Generating the preprocessed output and compiling it locally finds the warnings. I'm concerned that we are seeing a different result for the output of -E and the standard compile.

The compiler options are:
-g
-Wall
-Werror
-Wno-strict-aliasing
-Wno-missing-braces
-m64
-Wno-switch
-fno-diagnostics-fixit-info
-fshow-overloads=best
-Wno-unknown-warning-option
-Wno-unknown-pragmas
-Wno-logical-op-parentheses
-Wno-tautological-undefined-compare
-Wno-tautological-unsigned-zero-compare
-Wno-tautological-unsigned-enum-zero-compare
-Wno-expansion-to-defined
-Wno-format-security
-Wnarrowing
-Warray-bounds-pointer-arithmetic
-Wduplicate-method-match
-Wmove
-Wunreachable-code
-Wno-return-std-move
-ftemplate-depth=512
-Wpessimizing-move
-gline-tables-only
-fprofile-instr-generate
-fcoverage-mapping
-Og
-std=c++14
-Wno-reorder
-Wno-literal-suffix
-Wcomma
-fPIC

Thanks,

Ian.

#2

Not a bug - intended behavior & not the only diagnostic with this property (that the behavior is different between preprocessed and unpreprocessed source). Clang uses macro spelling as a means to reduce false positives in diagnostics - without them, there are more false positives.

Clang does have the -frewrite-includes flag that should preserve more of the macro content while still making a standalone file that could be compiled without searching for includes.

#3

Interesting, thanks.

It does make using clang with distcc somewhat problematic, especially given the errors aren't spotted in the "normal" build. This ends up causing users to think there's an issue with the distcc slaves (there are may instances in our code where the bugs are only spotted in the preprocessed output).

Cheers,

Ian.