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. Repository: rC Clang https://reviews.llvm.org/D44559 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
