[PATCH] D44559: [Sema] Wrong width of result of mul operation

Roman Lebedev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Mar 17 09:20:41 PDT 2018

lebedev.ri added a comment.

In https://reviews.llvm.org/D44559#1041001, @rjmccall wrote:

> In https://reviews.llvm.org/D44559#1040928, @lebedev.ri wrote:
> > In https://reviews.llvm.org/D44559#1040799, @rjmccall wrote:
> >
> > > I think we're correct not to warn here and that GCC/ICC are being noisy.  The existence of a temporary promotion to a wider type doesn't justify warning on arithmetic between two operands that are the same size as the ultimate result.  It is totally fair for users to think of this operation as being "closed" on the original type.
> >
> >
> > Could you please clarify, are you saying that PR35409 <https://bugs.llvm.org/show_bug.cgi?id=35409> is not a bug, and clang should continue to not warn in those cases?
> Correct.
> > If we would have "conversion sanitizer" <https://bugs.llvm.org/show_bug.cgi?id=21530>, detection of such problems would be easy, but without it, right now it is rather hard to detect such issues...
> What issue?  That arithmetic can overflow?

But this isn't about overflow. Arithmetic overflow issues are nicely detectable with current UBSan (+`-fsanitize=integer`, for unsigned).
This is about the **lack** of detectable overflow - implicit cast to `int`, multiplication of `int`'s (which means no overflow actually happened),
and then implicit integer demotion (which changes the "integer's value", for which there is no sanitizer, yet).

There is currently no way to detect this, at least in clang.
And it's not trivial to detect/debug such problems, which is exactly why a warning would be nice.

  rC Clang


More information about the cfe-commits mailing list