When I read that title, I also had the reaction "you have the wrong target"
but in my case, I assumed the target was SG20. I think it's a great paper
to send to that study group.

My main concern, though, boils down to the idea that "Can't happen" is
somehow a behaviour. It seems to be suggested, for example, that overflow
as it occurs in current implementations can realistically be defined. I'm
not sure that's practical because such behaviour is highly sensitive to
many non-obvious factors. Overflow at a single point in the code may
produce wildly different 'behaviours' depending on factors such as: from
where it's invoked, various toolchain options and minor revisions to the
implementation. And even with this information at hand, the write-up might
well be onerous to the implementer and worse than useless for the user
because it would involve describing in much detail the optimization
algorithms involved. So I don't think implementation-defined is a
straight-forward solution to the problem.

Generally, I agree I'd like to see effort put toward thinking of the
correct way to deliver the idea of UB. It's the wrong wording to give to
users of the language. It's implementor speak. Like a bailiff using
legalese to explain why somebody has just lost their home, it causes
confusion and anger.

On Sat, 26 Jan 2019 at 08:54 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
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>