`-Wshorten-64-to-32` should not warn when value is bounded by conditionals

[Explorer09]

#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    if (argc < 2)
        return 0;

    long long x = strtoll(argv[1], NULL, 10);
    if (x >= 0 && x <= INT_MAX) {
        int y = x;
        printf("%d\n", y);
    }
    return 0;
}

Compiling with clang-19 -Wshorten-64-to-32 produces this warning on the int y = x; line:

warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]

Expected result: No warning.

[AaronBallman]

I don't think this diagnostic behavior is likely to be modified. This is a much older diagnostic intended for catching portability (not necessarily correctness) issues, but more importantly, this would require a full control flow analysis (and there's an argument to be made it should also be a data flow analysis) which is very expensive on compile times.

[Explorer09]

@AaronBallman I don't see a portability issue if I leave an implicit downcast like that. My complaint is Clang over-warn things (i.e. this case is a false positive), especially when a warning like -Wshorten-64-to-32 is enabled by default.

Since the data flow analysis (about possible value ranges) would be performed during optimization anyway, I don't see any reason to not use this information to also suppress false positive warnings.

[AaronBallman]

@AaronBallman I don't see a portability issue if I leave an implicit downcast like that. My complaint is Clang over-warn things (i.e. this case is a false positive), especially when a warning like -Wshorten-64-to-32 is enabled by default.

This case is not a false positive, it's pointing out exactly what we intended for it to point out: type incompatibilities that require a human to reason about when porting from a 32-bit int target to a 64-bit int target.

Since the data flow analysis (about possible value ranges) would be performed during optimization anyway, I don't see any reason to not use this information to also suppress false positive warnings.

Clang does not emit diagnostics from the optimizer; that leads to a very poor user experience where different -O settings change the diagnostics you get, as does changing the machine the build is happening on. This diagnostic is emitted from the frontend where we have less information about value ranges unless we explicitly perform additional (expensive) analysis.

[Explorer09]

This case is not a false positive, it's pointing out exactly what we intended for it to point out: type incompatibilities that require a human to reason about when porting from a 32-bit int target to a 64-bit int target.

There's no "type incompatibility" when I interpret the language standard strictly. This implicit conversion is allowed by the language, and because of the constraint, there is no behavior that would be undefined.

Clang does not emit diagnostics from the optimizer; that leads to a very poor user experience where different -O settings change the diagnostics you get, as does changing the machine the build is happening on. This diagnostic is emitted from the frontend where we have less information about value ranges unless we explicitly perform additional (expensive) analysis.

I can't see the "user experience" will be "poor". Honestly I think you are making an excuse. I've seen some warnings (perhaps from gcc) that are emitting only in the highest optimization level (-O3), I've also caught one case when a warning was generated in -O2 but not in -O3.