Forwarding... I think I can't email this list from my @apple.com address.

---------- Forwarded message ----------
From: JF Bastien <jfbastien_at_[hidden]>
Date: Thu, Feb 15, 2018 at 6:26 PM
Subject: Re: [ub] A proposal to define signed overflow submitted?
To: Richard Smith <richardsmith_at_[hidden]>
Cc: ub <ub_at_[hidden]>



On Feb 15, 2018, at 16:47, Richard Smith <richardsmith_at_[hidden]> wrote:

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”
>

Fine by me. The only bit I expect to be contended is signed integer
overflow as I propose, so I’m not sure how much of a paper you’ll have. I
have the arguments for and against my proposal ready, and intend to present
both sides already.

— namely, remove sign-magnitude and ones'-complement from the standard, and
> perhaps give defined behavior to (-1 << 1) and (-1 >> 1),
>

I think this is all non-contended. Happy to hear otherwise.

but conservatively retain the undefined behavior of (INT_MAX + 1)
>

That’s the point of contention I expected :)


and (1 << 100).
>

Yes, this is really out of scope because existing ISAs do different things.

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


That’s one of my goals.

 * 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


Another goal I had was to get that discussion going in EWG.

Please come prepared with specific "optimization lost" numbers, as well as
"bugs found"!

... 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.


Oh yes! I’d like to hear people’s ideas here. Basically, ~nobody really
opts into UB with signed overflow, they just happen to never hit it
dynamically. If we had a way to opt-in or opt-out then I think we’d be
better off. I have ideas of how I’d do this, hinted at in paper, but part
of this paper’s goal is to hear others’ ideas.

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
>