I think the warning is flagging a real issue - maybe we should just fix it?

Failing that, can you open an issue about the problem the warning is flagging and then add a comment here referring to that issue?

Looks like the fix isn’t quite that simple

Failing that, can you open an issue about the problem the warning is flagging and then add a comment here referring to that issue?

btw I'm also happy with doing this

@mattip just in case you have a quicker thought. Maybe ignoring the warning is even the best thing (so long the compiler doesn't say "this is UB, I'll do something random", I am pretty sure things are correct)...
In C++ I feel we might be able to do a trick like seeing which type is actually used for the comparison and cast to that, but I dunno that is nice.

(I.e. I think the cast is only right if we cast an integer to a float. In all other cases > will do promotion for the comparison and that is necessary?)

I think the problem is on the left side, not the right side, no?

I think the problem is on the left side, not the right side, no?

I don't think that is the problem, we have something like a double->long cast there, which gives us: double_value > LONG_MAX.
(IIRC, RTYPE is just there to cast half to float?)

Normally all is fine:

• The left hand has a smaller range (e.g. many int->int casts) it is tautological but the compiler realizes that.
• Both are integer values: I think things work out (but didn't think it fully through again, maybe there is an other branch that deals with signed/unsigned comparison shenanigans)
• For float to integer casts: The imprecise casts here should be OK, I guess. But we get the new warning here now...

The problem is, adding the cast fixes the last one, but breaks some of the first two.

btw I'm also happy with doing this

I opened #31540 and reverted the PR to ignore the warnings.

Thanks, just adding the warning filter makes sense. Really not sure there is a nice other pattern available, TBH.