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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Fixes all the false positives it had reported for LibreOffice (which had all involved expressions containing either ~ or +).
Just for the record, the additional analysis has a measurable compile-time impact (0.3% at O0): https://llvm-compile-time-tracker.com/compare.php?from=e7f53044e7263cdbbb4fed9abf086b88ba486bba&to=cff6dda604cb0548bef5e5951dd1e74536110588&stat=instructions
Hi, this change seems like hits a false positive case in chromium build: https://bugs.chromium.org/p/chromium/issues/detail?id=1124085
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.
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...)
NonNegative