Date: Tue, 29 Jan 2019 17:55:36 -0800
Greetings SG12,
I sent the following email yesterday, but received a response that the
email to the group was being held for moderation. After waiting more than
24 hours I've not heard back regarding moderation. I'm unsure how to
directly contact the moderator. So I'm trying again. I beg your pardon if
this leads to duplication.
Scott Schurr
S.Scott.Schurr_at_[hidden]
On Mon, Jan 28, 2019 at 9:32 AM Scott Schurr <s.scott.schurr_at_[hidden]>
wrote:
> Hello Mr. Glisse,
>
> Thanks very much for your interest in paper P1407R0. I appreciate your
> information about gcc's behavior. If an R1 version of the paper is
> published it will incorporate both of your points with attribution to you.
>
> As for the appropriate target, I hear your concerns. Certainly the
> approach proposed in the paper is far from ideal. The problem comes from
> arriving at consensus regarding what an ideal, or even good enough,
> approach would be. My personal opinion is that the status quo is about as
> far from ideal as we could get. But I also understand that there are
> plenty of people who disagree with my view.
>
> Thanks again.
>
> Scott Schurr
> S.Scott.Schurr_at_[hidden]
>
> On Sat, Jan 26, 2019 at 12:44 AM Marc Glisse <marc.glisse_at_[hidden]> wrote:
>
>> Hello,
>>
>> just a couple points missing from the paper:
>>
>> 1) with g++-7 -O2 -Wall, the motivating example on the left produces:
>>
>> <source>: In function 'int32_t add_100_without_wrap(int32_t)':
>> <source>:8:3: warning: assuming signed overflow does not occur when
>> assuming that (X + c) < X is always false [-Wstrict-overflow]
>> if (ret < a)
>>
>> However, we removed the warning from gcc-8 because it was too noisy and
>> impossible to work around when the optimization is what you actually want.
>>
>> 2) At least with gcc, -ftrapv doesn't really work. You need
>> -fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error for
>> something roughly equivalent to what -ftrapv is supposed to do.
>>
>>
>> Now my opinion: you have the wrong target. Compilers that have a -fwrapv
>> option (or -ftrapv or ubsan or ...) already indirectly describe the
>> default behavior as undefined (and the standard already describes it as
>> undefined), so it is already documented. Adding a sentence or 2 in the
>> standard and on pages that nobody reads won't help. It seems that you
>> want
>> to talk either to teachers, so they warn their students more about the
>> properties of signed overflow, or to compiler writers, to convince them
>> to
>> change the default to -fwrapv or -ftrapv (I hope they don't) or add more
>> warnings.
>>
>> --
>> Marc Glisse
>>
>
I sent the following email yesterday, but received a response that the
email to the group was being held for moderation. After waiting more than
24 hours I've not heard back regarding moderation. I'm unsure how to
directly contact the moderator. So I'm trying again. I beg your pardon if
this leads to duplication.
Scott Schurr
S.Scott.Schurr_at_[hidden]
On Mon, Jan 28, 2019 at 9:32 AM Scott Schurr <s.scott.schurr_at_[hidden]>
wrote:
> Hello Mr. Glisse,
>
> Thanks very much for your interest in paper P1407R0. I appreciate your
> information about gcc's behavior. If an R1 version of the paper is
> published it will incorporate both of your points with attribution to you.
>
> As for the appropriate target, I hear your concerns. Certainly the
> approach proposed in the paper is far from ideal. The problem comes from
> arriving at consensus regarding what an ideal, or even good enough,
> approach would be. My personal opinion is that the status quo is about as
> far from ideal as we could get. But I also understand that there are
> plenty of people who disagree with my view.
>
> Thanks again.
>
> Scott Schurr
> S.Scott.Schurr_at_[hidden]
>
> On Sat, Jan 26, 2019 at 12:44 AM Marc Glisse <marc.glisse_at_[hidden]> wrote:
>
>> Hello,
>>
>> just a couple points missing from the paper:
>>
>> 1) with g++-7 -O2 -Wall, the motivating example on the left produces:
>>
>> <source>: In function 'int32_t add_100_without_wrap(int32_t)':
>> <source>:8:3: warning: assuming signed overflow does not occur when
>> assuming that (X + c) < X is always false [-Wstrict-overflow]
>> if (ret < a)
>>
>> However, we removed the warning from gcc-8 because it was too noisy and
>> impossible to work around when the optimization is what you actually want.
>>
>> 2) At least with gcc, -ftrapv doesn't really work. You need
>> -fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error for
>> something roughly equivalent to what -ftrapv is supposed to do.
>>
>>
>> Now my opinion: you have the wrong target. Compilers that have a -fwrapv
>> option (or -ftrapv or ubsan or ...) already indirectly describe the
>> default behavior as undefined (and the standard already describes it as
>> undefined), so it is already documented. Adding a sentence or 2 in the
>> standard and on pages that nobody reads won't help. It seems that you
>> want
>> to talk either to teachers, so they warn their students more about the
>> properties of signed overflow, or to compiler writers, to convince them
>> to
>> change the default to -fwrapv or -ftrapv (I hope they don't) or add more
>> warnings.
>>
>> --
>> Marc Glisse
>>
>
Received on 2019-01-30 02:55:48