Building the kernel with gcc-7.0.1 (r245831 at the time of testing), we ran into a warning from objtool about a function ending in an undefined instruction: drivers/pwm/pwm-hibvt.o: warning: objtool: hibvt_pwm_get_state() falls through to next function hibvt_pwm_apply() I reduced the test case to a trivial division by zero: static inline int return0(void) { return 0; } int provoke_div0_warning(void) { return 1 / return0(); } which gets turned into a single trapping instruction (aarch64) 0000000000000018 <provoke_div0_warning>: 18: d4207d00 brk #0x3e8 (x86-64) 0000000000000010 <provoke_div0_warning>: 10: 0f 0b ud2 This seems to be a result of r242636, and in the discussion on that patch, I found a remark from Jeff Law that there should be a warning for it: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00508.html I think that having this gcc warning would have been rather useful in debugging the kernel build warning. Any chance this could be added?
The warning exists in the frontends only at the moment. Note such warning in the middle-end has the chance of false positives from (for example) path isolation.
(In reply to Richard Biener from comment #1) > Note such warning in the middle-end has the chance of false > positives from (for example) path isolation. Would it be possible to warn if a function always traps? The kernel function that found this does not get inlined and has only one return statement, which never gets reached.
I'm afraid the warning would be huge amounts of false positives due to path isolation/jump threading and similar optimization.
s/would be/would have/
If we only warn when the trap is always executed as Arnd suggests (determined in a similar way as uninitialized vs maybe-uninitialized), I guess there should be fewer false positive (only cloning seems likely to produce them). On the other hand, it would likely miss most interesting warnings (although it would have helped the kernel this once, apparently).
If the warning has false positives, then I'm sure the kernel will turn it off anyway like it does with tons of other warnings.
The thing is, if we could prove the trap is always executed, then we'd just zap everything prior to the trap without visible side effects and everything after the trap. It's actually not an interesting case. It's critical to remember that a trap introduced by the compiler is on a *path* through the CFG and a series of conditionals has to be met for the trap to be executed. The compiler has already tried to prove the path is infeasible and failed. In fact, that pass was originally introduced specifically because there are cases where the compiler will never be able to prove a particular problem path can't execute and as a result it must keep the path in the CFG, which in turn leads to false positives from -Wuninitialized later. By isolating the path and introducing a trap on that path, the CFG simplifies in useful ways *and* if the program were to erroneously get on the path, it gets halted prior to execution of undefined behavior which is desirable from a security standpoint. There is some code in tree-ssa-uninit.c which does predicate analysis to further reduce the set of false positives for -Wuninitialized. However, that code won't solve the problems that folks are looking at here (if it did, we wouldn't have erroneous path isolation to begin with).
(In reply to Jakub Jelinek from comment #6) > If the warning has false positives, then I'm sure the kernel will turn it > off anyway like it does with tons of other warnings. That is well possible. I try to catch new warnings early by building lots of kernels with random configurations and sending kernel fixes, but if there are more than a few dozen instances and none of them are interesting kernel bugs, I'd also turn off that warning. I have started going through all available warnings to see how much output they generate (97GB on an allmodconfig kernel build when turning them all on with gcc, more with clang), with the intention of re-enabling the more useful ones, but will take a while to get there as I can only enable them after having fixed all the warnings we get.