https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 20 Jul 2023, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 > > rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rsandifo at gcc dot gnu.org > > --- Comment #13 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot > gnu.org> --- > I understand the concern with undefined values, since it then becomes less > obvious whether e.g.: > > a = undef > b = a == a > > is guaranteed to be true, or whether it reduces to: > > b = undef == undef > > which is presumably undef. > > But I don't think a null operand really helps. The same question would apply > to: > > x = COND_LEN_ADD (a, b, null, len, bias) > y = x == x > > vs. > > x1 = COND_LEN_ADD (a, b, null, len, bias) > x2 = COND_LEN_ADD (a, b, null, len, bias) > y = x1 == x2 > > Do both of these ys evaluate to true, or is one or both be undefined? > > So if we're prepared to accept undefinedness, I'd prefer to have a ?proper? > representation of it. We could probably adopt LLVM's semantics for undef. > > (SVE might have some uses for this too.) Note I simply proposed 'NULL' as the "proper" representation of it. That doesn't fix any of the semantic issues but I think neither does any other representation ...
