This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [006/nnn] poly_int: tree constants
On 10/29/2017 09:14 PM, Trevor Saunders wrote:
On Sun, Oct 29, 2017 at 10:25:38AM -0600, Martin Sebor wrote:
On 10/27/2017 02:08 AM, Richard Sandiford wrote:
Martin Sebor <msebor@gmail.com> writes:
On 10/26/2017 11:52 AM, Richard Sandiford wrote:
Martin Sebor <msebor@gmail.com> writes:
For offset_int the default precision is 128-bits. Making that
the default also for wide_int should be unsurprising.
I think it'd be surprising. offset_int should always be used in
preference to wide_int if the precision is known to be 128 bits
in advance, and there doesn't seem any reason to prefer the
precision of offset_int over widest_int, HOST_WIDE_INT or int.
We would end up with:
wide_int
f (const wide_int &y)
{
wide_int x;
x += y;
return x;
}
being valid if y happens to have 128 bits as well, and a runtime error
otherwise.
Surely that would be far better than the undefined behavior we
have today.
I disagree. People shouldn't rely on the above behaviour because
it's never useful.
Well, yes, but the main point of my feedback on the poly_int default
ctor (and the ctor of the extended_tree class, and the existing wide
int classes) is that it makes them easy to misuse. That they're not
meant to be [mis]used like that isn't an answer.
I think Richard's point is different from saying don't misuse it. I
think its that 0 initializing is also always a bug, and the user needs
to choosesome initialization to follow the default ctor in either case.
Initializing offset_int to zero isn't a bug and there are examples
of it in GCC sources. Some of those are now being replaced with
those of poly_int xxx = 0. Here's one example from [015/nnn]
poly_int: ao_ref and vn_reference_op_t:
@@ -1365,8 +1369,8 @@ indirect_refs_may_alias_p (tree ref1 ATT
refs_may_alias_p_1 (ao_ref *ref1, ao_ref *ref2, bool tbaa_p)
{
tree base1, base2;
- HOST_WIDE_INT offset1 = 0, offset2 = 0;
- HOST_WIDE_INT max_size1 = -1, max_size2 = -1;
+ poly_int64 offset1 = 0, offset2 = 0;
+ poly_int64 max_size1 = -1, max_size2 = -1;
I'm not suggesting these be changed to avoid the explicit
initialization. But I show this to disprove the claim above.
Clearly, zero initialization is valid and useful.
Martin