Date: Fri, 16 Feb 2018 00:47:38 +0000
On Thu, 15 Feb 2018 at 16:16, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:
> On Thu, Feb 15, 2018 at 3:51 PM, Hubert Tong <
> hubert.reinterpretcast_at_[hidden]> wrote:
>
>> On Thu, Feb 15, 2018 at 6:44 PM, David Vandevoorde <daveed_at_[hidden]>
>> wrote:
>>>
>>> > On Feb 15, 2018, at 5:14 PM, Myria <myriachan_at_[hidden]> wrote:
>>> >
>>> > I'm personally on the side of defining signed overflow as wrapping,
>>> > but compiler people do have a point that it would inhibit
>>> > optimizations in certain cases involving signed integers.
>>>
>>> My understanding is that it kills a significant optimization opportunity
>>> (that is currently taken advantage of by compilers).
>>>
>> I also believe that it makes it harder for tooling to flag unintentional
>> signed overflow.
>>
>
> Yes.
>
> I am considering writing a response to JF's P0907 in which I would propose
> "just the good bits" — namely, remove sign-magnitude and ones'-complement
> from the standard, and perhaps give defined behavior to (-1 << 1) and (-1
> >> 1), but conservatively retain the undefined behavior of (INT_MAX + 1)
> and (1 << 100). I think such a conservative proposal might stand a chance
> these days; it feels analogous to the removal of trigraphs.
> Defining (INT_MAX+1 == INT_MIN), as proposed by P0907? No, that will never
> happen in a million years.
>
I'm (provisionally) in favor of that. I hope that JF's paper will have two
effects:
* if any implementers support non-two's-complement targets, they step
forward and speak up
* the arguments in favor of keeping overflow undefined (for static and
dynamic analysis, optimization, mathematical reasoning) and in favor of
making it defined (ease of writing overflow checks, giving
defined-but-maybe-wrong behavior to overflowing code rather than allowing
unbounded badness) are enumerated
... and in particular, for the common cases where people want defined
signed overflow behavior (eg, "I want to add these things, or take remedial
action if that would overflow" or "I want to perform arithmetic in the ring
of integers modulo 2^N and (somehow) signed arithmetic makes sense in my
model") we can add a concise and easy way of expressing that intent.
However, I personally will not be at JAX, and if someone beats me to
> writing this paper, I will not be upset. :)
>
> –Arthur
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
wrote:
> On Thu, Feb 15, 2018 at 3:51 PM, Hubert Tong <
> hubert.reinterpretcast_at_[hidden]> wrote:
>
>> On Thu, Feb 15, 2018 at 6:44 PM, David Vandevoorde <daveed_at_[hidden]>
>> wrote:
>>>
>>> > On Feb 15, 2018, at 5:14 PM, Myria <myriachan_at_[hidden]> wrote:
>>> >
>>> > I'm personally on the side of defining signed overflow as wrapping,
>>> > but compiler people do have a point that it would inhibit
>>> > optimizations in certain cases involving signed integers.
>>>
>>> My understanding is that it kills a significant optimization opportunity
>>> (that is currently taken advantage of by compilers).
>>>
>> I also believe that it makes it harder for tooling to flag unintentional
>> signed overflow.
>>
>
> Yes.
>
> I am considering writing a response to JF's P0907 in which I would propose
> "just the good bits" — namely, remove sign-magnitude and ones'-complement
> from the standard, and perhaps give defined behavior to (-1 << 1) and (-1
> >> 1), but conservatively retain the undefined behavior of (INT_MAX + 1)
> and (1 << 100). I think such a conservative proposal might stand a chance
> these days; it feels analogous to the removal of trigraphs.
> Defining (INT_MAX+1 == INT_MIN), as proposed by P0907? No, that will never
> happen in a million years.
>
I'm (provisionally) in favor of that. I hope that JF's paper will have two
effects:
* if any implementers support non-two's-complement targets, they step
forward and speak up
* the arguments in favor of keeping overflow undefined (for static and
dynamic analysis, optimization, mathematical reasoning) and in favor of
making it defined (ease of writing overflow checks, giving
defined-but-maybe-wrong behavior to overflowing code rather than allowing
unbounded badness) are enumerated
... and in particular, for the common cases where people want defined
signed overflow behavior (eg, "I want to add these things, or take remedial
action if that would overflow" or "I want to perform arithmetic in the ring
of integers modulo 2^N and (somehow) signed arithmetic makes sense in my
model") we can add a concise and easy way of expressing that intent.
However, I personally will not be at JAX, and if someone beats me to
> writing this paper, I will not be upset. :)
>
> –Arthur
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
Received on 2018-02-16 01:47:52