On Tue, 15 Dec 2020, Jeff Law wrote: > > @@ -1942,7 +1942,7 @@ gen_divdf3_cc (rtx operand0 ATTRIBUTE_UN > > gen_rtx_DIV (DFmode, > > operand1, > > operand2), > > - const0_rtx)), > > + CONST_DOUBLE_ATOF ("0", VOIDmode))), > > gen_rtx_SET (operand0, > > gen_rtx_DIV (DFmode, > > copy_rtx (operand1), > > > > gcc/ > > * genemit.c (gen_exp) <CONST_DOUBLE>: Handle `const_double_zero' > > rtx. > > --- > > Hi, > > > > I have verified this with a bootstrap of a `powerpc64le-linux-gnu' native > > compiler, and that it builds a `pdp11-aout' cross-compiler up to the point > > of failing to find target headers. I have no means to verify it further, > > the target configuration is too exotic to me, so I will appreciate help. > > > > NB this only triggers with insn-emit.c code produced from named RTL insns > > for the purpose of calling them directly, which does not apply for the VAX > > backend, as it does not give names to any insns using `const_double_zero'. > > Which is why I didn't spot this issue with all my VAX verification. > > > > Thanks to Martin for bringing my attention to this regression, and sorry > > to miss this in testing. > > > > OK to apply? > Presumably you can't use CONST0_RTX (mode) here? Assuming that's the > case, then this is fine.
Well, `mode' is VOID for simplicity and to match what the middle end presents as an operand to the COMPARE operation, as also shown with the diff above, so with CONST0_RTX (mode) we'd be back to what amounts to `const0_rtx' aka `const_int 0', which is exactly what we want to get away from. Alternatively we could possibly give `const_double_zero' a proper FP mode, but it seems to me like an unnecessary complication, as it would then have to be individually requested and iterated over all the relevant modes. Have I missed anything here? NB the PDP-11 pieces affected here and tripping this assertion are I believe dead code, as these insns are only ever produced by splitters and do not appear to be referred by their names. We need this change however for completeness so that `const_double_zero' can be used in contexts where an insn actually will be referred by its name. However the PDP-11 code being dead makes it a bit more difficult to examine actual consequences of such a change like I have proposed than it would otherwise be. In these circumstances I think my proposal is safe if a bit overly cautious. Maciej