On Tue, Nov 8, 2022 at 2:25 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Tue, Nov 08, 2022 at 02:06:58PM +0100, Aldy Hernandez wrote: > > + gcc_checking_assert (!r.nan_signbit_p (sign1)); > > + if (op1_nan && op2_nan) > > + { > > + // If boths signs agree, we could use that sign, but IEEE754 > > + // does not guarantee this for a binary operator. The x86_64 > > + // architure does keep the common known sign, but further tests > > + // are needed to see if other architectures do the same (i387 > > + // long double, ARM/aarch64, PowerPC, s390,{,x}, RSICV, etc). > > s/RSICV/RISCV/ > > > + // In the meantime, keep sign VARYING. > > + ; > > + } > > + else if (op1_nan) > > + { > > + if (op1.nan_signbit_p (sign1)) > > + r.update_nan (sign1); > > + } > > + else if (op2_nan) > > + { > > + if (op2.nan_signbit_p (sign2)) > > + r.update_nan (sign2); > > + } > > Well, these cases also aren't guaranteed for binary operator. > I think a conforming implementation can say copy the NaN operand > to result and toggle the sign. Or, if the operand would be a sNaN, > it must turn it into a qNaN (don't remember right now if there are > requirements on what it can do with the mantissa which needs to change > for the sNaN -> qNaN difference at least, but whether it can just > generate a canonical qNaN or needs to preserve at least some bits), > but could e.g. clear or toggle the sign of the NaN as well. > Whether there are any such implementations or not is a question. > For the single qNaN operand case, it would surprise me if anybody > bothered to tweak the sign bit in any way, just copying the input > seems simpler to me, but for the sNaN -> qNaN conversion it wouldn't > surprise me that much.
Well, perhaps we should just nuke update_nan_sign() altogether, and always keep the sign varying? inline bool propagate_nans (frange &r, const frange &op1, const frange &op2) { if (op1.known_isnan () || op2.known_isnan ()) { r.set_nan (op1.type ()); return true; } return false; } I'm fine either way. The less code the better :). Aldy