On Sat, 2 Nov 2013, Richard Sandiford wrote: > Jakub Jelinek <ja...@redhat.com> writes: > > On Sat, Nov 02, 2013 at 03:15:44PM +0000, Richard Sandiford wrote: > >> What should integer_onep mean if we have a signed 1-bit bitfield in > >> which the bit is set? Seen as a 1-bit value it's "obviously" 1, > >> but seen as a value extended to infinite precision it's -1. > >> > >> Current mainline returns false while wide-int returns true. > > > > Then current mainline is correct. signed 1-bit bitfield has values > > 0 and -1, not 0 and 1. And, signed 1-bit -1 should be just > > integer_minus_onep and integer_all_onesp. > > OK, thanks. I should have realised this earlier, but we have: > > /* Return 1 if EXPR is the integer constant one or the corresponding > complex constant. */ > > int > integer_onep (const_tree expr) > ... > /* Return 1 if EXPR is the integer constant minus one. */ > > int > integer_minus_onep (const_tree expr) > > which makes them sound like a pair. But integer_minus_onep returns > true for any all-ones INTEGER_CST (regardless of sign): > > if (TREE_CODE (expr) == COMPLEX_CST) > return (integer_all_onesp (TREE_REALPART (expr)) > && integer_zerop (TREE_IMAGPART (expr))); > else > return integer_all_onesp (expr); > > So a nonzero 1-bit unsigned bitfield is both integer_onep and > integer_minus_onep, but a 1-bit signed bitfield is only > integer_minus_onep. Should integer_minus_onep be changed so > that it always returns false for unsigned types?
I think so (but it was only introduced very recently, exactly because integer_minus_onep is not equal to integer_all_onesp in all cases). Richard.
