Hi! On Fri, Jun 04, 2021 at 10:57:51AM +0800, Kewen.Lin via Gcc-patches wrote: > To find out those need fixing seems to be the critical part. It's > not hard to add one explicit "&&" to those that don't have it now, but > even with further bootstrapped and regression tested I'm still not > confident the adjustments are safe enough, since the testing coverage > could be limited. It may need more efforts to revisit, or/and test > with more coverages, and port maintainers' reviews.
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572120.html This adds an "&&" everywhere (or in fact, it just skips any existing one, it just has the same effect of adding it everywhere). I tested it with building gcc and Linux for all supported targets (31 of them; I do some with multiple configs, mostly 32-bit and 64-bit). None had any difference before and after the change. So I am no longer worried that there will be any fallout from doing this. There are many things that *could* go wrong, but I don't think there will be enough at all to be an impediment to just throwing the switch. If we go this way no target will need any significant fixing, maybe none at all will be needed across all targets. And no changes will be needed anywhere immediately. We could make leading "&&" deprecated, and the same for split condition "1" (which was "&& 1"). This is easy to change automatically as well. Segher
