This is an archive of the discontinued LLVM Phabricator instance.

More accurately compute the ranges of possible values for +, -, *, &, %.
ClosedPublic

Authored by rsmith on Aug 11 2020, 1:53 PM.

Details

Summary

Continue to heuristically pick the wider of the two operands for
narrowing conversion warnings so that some_char + 1 isn't treated as
being wider than a char, but use the more accurate computation for
tautological comparison warnings.

Diff Detail

Event Timeline

rsmith created this revision.Aug 11 2020, 1:53 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 11 2020, 1:53 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
rsmith requested review of this revision.Aug 11 2020, 1:53 PM
sberg added a comment.Aug 12 2020, 5:19 AM

Fixes all the false positives it had reported for LibreOffice (which had all involved expressions containing either ~ or +).

rtrieu accepted this revision.Aug 12 2020, 7:01 PM

LGTM

clang/lib/Sema/SemaChecking.cpp
10172

NonNegative

This revision is now accepted and ready to land.Aug 12 2020, 7:01 PM
This revision was landed with ongoing or failed builds.Aug 31 2020, 11:17 PM
This revision was automatically updated to reflect the committed changes.
zequanwu added a subscriber: zequanwu.EditedSep 1 2020, 5:42 PM

Hi, this change seems like hits a false positive case in chromium build: https://bugs.chromium.org/p/chromium/issues/detail?id=1124085

rsmith added a comment.Sep 1 2020, 5:42 PM

Thanks, it seems very likely that this is caused by CheckImplicitConversion now calling CheckExprRange twice. It looks like that's not only avoidable, but there's a (pre-existing) bug here that we can squash at the same time :) Should be fixed in rG0ffbbce78de60f4f4d03d6ef97fe2f3bb4275e08.

rsmith added a comment.Sep 1 2020, 5:53 PM

Hi, this change seems like hits a false positive case in chromium build: https://bugs.chromium.org/p/chromium/issues/detail?id=1124085

That's not a false positive. The code is (simplified):

int RoundDown(int a, long b) { return a & -b; }

... which is implicitly converting an expression of type long to int, losing precision. For example, RoundDown(-1, 0x1'0000'0000) is -4294967296 prior to the implicit conversion from long to int. Given that the truncation is presumably intentional (0 at least seems like the least-bad answer for rounding down 0 to a multiple of 2^32 as a 32-bit integer), you can suppress the warning with a cast.

Hi, this change seems like hits a false positive case in chromium build: https://bugs.chromium.org/p/chromium/issues/detail?id=1124085

That's not a false positive. The code is (simplified):

int RoundDown(int a, long b) { return a & -b; }

... which is implicitly converting an expression of type long to int, losing precision. For example, RoundDown(-1, 0x1'0000'0000) is -4294967296 prior to the implicit conversion from long to int. Given that the truncation is presumably intentional (0 at least seems like the least-bad answer for rounding down 0 to a multiple of 2^32 as a 32-bit integer), you can suppress the warning with a cast.

Sorry, I didn't notice that the type of second parameter is based on __LP64__ (didn't scroll up...)