llvm dev - Nov 2019 - Potential problem with -Wunreachable-code

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.

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.

On Thu, Nov 21, 2019 at 7:29 PM Ian Collins via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191121/3cb4c2d0/attachment.html>

On 22/11/2019 16:40, David Blaikie wrote:
> 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.

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.