Hi Chandler,

I'll be interested to see how others weigh in. If opinions remain
divided, one way to help resolve the issue would be to stress-test a few
large applications compiled with integer undefined behavior checking and
then take a close look at the resulting signed left-shift UBs. If more
of them are real bugs, you win the argument; if more of them are
instances where people expected unsigned semantics, I win. Honestly, I
stopped looking closely at these several years ago after I realized how
hard it was to convince people to fix the less benign integer UBs. I
even got flamed by the main PHP guy over a signed addition overflow bug
one time.

I'm interested to hear more about situations where measurable speedup
can be had by exploiting the remaining UBs after shift-into-sign-bit
becomes defined. I'm afraid that I can already hear the screaming users
when you deploy these optimizations, but at least there's a checker.

> Did you distinguish between those due to shift-into-sign-bit, and those
> which actually shifted completely off the top?

We didn't make this distinction. However, according to Richard Smith,
--std=c++11 causes Clang to turn off the shift-into-sign-bit error
message. I hope we can tweak the -fsanitize=... flags a bit to make
selective checking easier.

> The committee has recently given serious consideration to the behavior of
> C++ on unisys machines that are still in use... I'm not familiar with them,
> but I hesitate to make this assumption.

Well, my guess is that Unisys has already been forced to implement two's
complement signed shifts since the alternative would almost certainly
break shifty applications like crpyto.

John