[001/nnn] poly_int: add poly-int.h

[Martin Sebor]

On 12/07/2017 03:48 PM, Jeff Law wrote:
> On 12/07/2017 03:38 PM, Richard Sandiford wrote:
>
>>> So I think that's the final ack on this series.
>>
>> Thanks to both of you, really appreciate it!
> Sorry it took so long.
>
>>
>>> Richard S. can you confirm?  I fully expect the trunk has moved some
>>> and the patches will need adjustments -- consider adjustments which
>>> work in a manner similar to the patches to date pre-approved.
>>
>> Yeah, that's now all of the poly_int patches.  I still owe you replies
>> to some of them -- I'll get to that as soon as I can.
> NP.  I don't think any of the questions were all that significant.
> Those which were I think you already responded to.

I am disappointed that the no-op ctor issue hasn't been adequately
addressed.  No numbers were presented as to the difference it makes
to have the ctor do the expected thing (i.e., initialize the object).
In my view, the choice seems arbitrarily in favor of a hypothetical
performance improvement at -O0 without regard to the impact on
correctness.  We have recently seen the adverse effects of similar
choices in other areas: the hash table insertion[*] and the related
offset_int initialization.

Martin

[*] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82977

PS To be clear, the numbers I asked for were those showing
the difference between a no-op ctor and one that initializes
the object to some determinate state, whatever that is.  IIUC
the numbers in the following post show the aggregate slowdown
for many or most of the changes in the series, not just
the ctor.  If the numbers were significant, I suggested
a solution to explicitly request a non-op ctor to make
the default safe and eliminate the overhead where it mattered.

https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01028.html