On 12/03/2019 16:40, Vincent Lefevre wrote:
On 2019-03-11 13:51:21 +0100, David Brown wrote:
On 11/03/2019 12:24, Vincent Lefevre wrote:
It already does by default:
-Wshift-count-negative
Warn if shift count is negative. This warning is enabled
by default.
-Wshift-count-overflow
Warn if shift count >= width of type. This warning is
enabled by default.
Of course, if the compiler cannot guess that there will be such
an issue, it will not emit the warning. You certainly don't want
a warning for each non-trivial shift just because the compiler
cannot know whether the constraint on the shift count will be
satisfied.
While the compiler clearly can't give a warning on calculated shifts
without massive amounts of false positives, it is able to give warnings
when there is a shift by a compile-time known constant value that is
invalid. In the case of the OP's test function, inlining and constant
propagation means that the shift value /is/ known to the compiler - it
uses it for optimisation (in this case, it uses the undefined behaviour
to "simplify" the calculations).
Am I right in thinking that this is because the pass that checks the
shift sizes for warnings here comes before the relevant inlining or
constant propagation passes? And if so, would it be possible to change
the ordering here?
To generate a warning, the compiler would also have to make sure
that the inlined code with an out-of-range shift is actually not
dead code. In practice, it may happen that constraints are not
satisfied on some platforms, but the reason is that on such
platforms the code will never be executed (this is code written
to take care of other platforms).
I disagree. To generate an unconditional error (rejecting the program),
the compiler would need such proof - such as by tracing execution from
main(). But to generate a warning activated specifically by the user,
there is no such requirement. It's fine to give a warning based on the
code written, rather than on code that the compiler knows without doubt
will be executed.
(The warning here would be on the function "test" which calls the
function with the shift, not on that function itself - since it is only
when used in "test" that the compiler can see that there is undefined
behaviour.)
