[cfe-dev] Clang warnings and what to do about them

[David Barto via cfe-dev]

GCC (5.1) doesn’t generate any warnings, and this code when compiled with GCC and executed under Valgrind doesn’t have any complaint from Valgrind. We have not upgraded to GCC 7.1 yet and are planning to do so later this summer.

warning: unsequenced modification and access to 'tmp0' [-Wunsequenced]
        if ( ((tmp0=f1 == -2143289343,false)) || !(tmp0) )
                   ^                              ~
warning: unsequenced modification and access to 'tmp0' [-Wunsequenced]
      if ( (!((tmp0=f1 == f3_1,false)) && tmp0) ) {
                   ^                      ~~~~
2 warnings generated.

In each case the operand on the left is setting the value of tmp0 which is then tested on the right side of the operand. In either case I don’t see how the ‘As If’ rule from the standard applies. Shouldn’t execution order left to right take precedence in this situation?

1- Is it actually possible at some optimization level that the compiler may generate code where the right side of the expression is executed before the left side?
2 - If (1) then is there some switch I can use to disable this specific optimization level?
3 - Is there some way to disable the warning if there actually exists no way that (1) may happen?

	David


> 1.9  Program execution  [intro.execution]
> 
> The semantic descriptions in this International Standard define a
> parameterized nondeterministic abstract machine. This International
> Standard places no requirement on the structure of conforming
> implementations.  In particular, they need not copy or emulate the
> structure of the abstract machine. Rather, conforming implementations
> are required to emulate (only) the observable behavior of the abstract
> machine as explained below.5
> 
> 5) This provision is sometimes called the “as-if” rule, because an
> implementation is free to disregard any requirement of this
> International Standard as long as the result is as if the requirement
> had been obeyed, as far as can be determined from the observable
> behavior of the program. For instance, an actual implementation need
> not evaluate part of an expression if it can deduce that its value is
> not used and that no side effects affecting the observable behavior of
> the program are produced.



David Barto
barto at cambridgesemantics.com

Sometimes, my best code does nothing. Most of the rest of it has bugs.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170623/d589d88c/attachment.html>