https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108674
Roman Lebedev <lebedev.ri at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|DUPLICATE |---
Status|RESOLVED |UNCONFIRMED
--- Comment #3 from Roman Lebedev <lebedev.ri at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> I think this is a bug in clang in the first place for enabling
> unsigned-integer-overflow at all.
> I would file a bug with clang to disable unsigned-integer-overflow by
> default when using -fsanitize=undefined .
This is incorrect.
unsigned-integer-overflow is *NOT* enabled by -fsanitize=undefined
It is enabled by -fsanitize=integer, separately.
I'm not enabling it erroneously, but very intentionally.
> GCC has already decided to never implement unsigned-integer-overflow even
> because of how broken this is.
This is quite the hot take.
I understand that the behaviours it diagnoses
are well-defined by the C and C++ standards,
and are well-used in various codebases,
however not all of those behaviors are desired by everyone.
For example, ((signed char)127)+1 is not a signed overflow,
even though you really can't tell me that the effective wraparound
is the semantics *everyone* expects there. :)
However, that is not the question here.
I really don't care whether or not you rely on the wraparound semantics
of the unsigned types in the library. I really don't.
This is only a problem because it happens in a public header.
All i'm asking is to improve the UX of the user-facing side
of the C++ standard library implementation,
and make it more usable by wider variety of the scenarios.
In fact, this is a regression.
This was not happening in libstdc++-11, or ever before.
