[RFC/PATCH 00/11] Fix up some unexpected empty split conditions

Kewen.Lin linkw@linux.ibm.com
Tue Jun 8 02:09:21 GMT 2021


Hi Segher,

on 2021/6/8 上午7:50, Segher Boessenkool wrote:
> 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.
> 
Thanks very much for doing this!

I guess we are not going to backport this?  If we won't, it seems to need
some way to ensure the implied "&&" will show up explicitly when backporting
some define_insn_and_split.

BR,
Kewen


More information about the Gcc-patches mailing list