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). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
