https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #35 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Niels Möller from comment #32) > 1. There's similar code in c_fully_fold_internal, in gcc/c/c-fold.c, close > to line 400. But that code does *not* emit any warning for the example > above, which surprised me a bit. Maybe that's only for the case that both > operands to the shift operator are constants? In general, front-ends should avoid emitting warnings while folding (simplifying) expressions. I think there is an open bug about this but I cannot find it now. Of course, if the code is doing the same, it should be factored out into a common function. A good first patch to submit: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps > 2. More importantly, if the warning is deleted from build_binary_op, we need > to add a check for this case, and an appropriate warning, somewhere later in > the compilation process. It has to be done after dead code is identified, > i.e., in a phase processing only non-dead code. And preferably as early as > possibly, when we're still working close to the parse-tree representation. > Is there such a place? Some other functions traversing the tree are > c_gimplify_expr (gcc/c-family/c-gimplify.c) and verify_tree > (gcc/c-family/c-common.c), are any of those called after elimination of dead > code? There is no such place. Dead code is identified in the middle-end and by then, there is no parse tree, only GIMPLE and SSA: https://gcc.gnu.org/onlinedocs/gccint/Passes.html#Passes Of course, you could add some kind of unreachable code pass to the FE, but that would require a lot of work from your side. Clang has something similar that you could use as an inspiration: https://github.com/llvm/llvm-project/blob/2946cd701067404b99c39fb29dc9c74bd7193eb3/clang/include/clang/Analysis/Analyses/ReachableCode.h > 3. Alternatively, if there's no place after dead code elimination where the > parse tree is still easily available, a different alternative could be to > leave the check for invalid shift counts in c-typeck.c, but instead of > emitting a warning, construct a special tree object representing an > expression with invalid/undefined behavior, and any meta data needed to emit > a warning or error to describe it? Then emission of the warning could be > postponed to later, say, close to the conversion to SSA form? That is still too early, since the dead code elimination happens after SSA.
