Fix a few gcc warnings in jit

[am11]

Fixes #57861

Cleans up 1045 occurrences of warning from gcc debug build logs. Remaining one compiler warning related to 'bit field width overflow', which has 2565 occurrences, is tracked by #33541.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Cleans up 1045 occurrences of warning from gcc debug build logs. Remaining one compiler warning related to 'bit field width overflow', which has 2565 occurrences, is tracked by #33541.

Author:	am11
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[am11]

Some more details..
The warn-as-error -Wall compiler flag is enabled for all compilers, for all non-mono subsets. The exception is jit with gcc, where -Wall is explicitly disabled due to log flood caused by bit field width overflow issue (see #33541 (comment)). Aside from that issue, there were a couple of warnings found in the build logs by applying the following filter, that this PR aims to fix:
./build.sh clr -gcc 2>&1 | grep -i warn | sort -u | grep -v "too small to hold all values"

There is one occurrence of a warning from gas assembler 'Warning: ignoring changed section attributes for .rodata' and that is not related to gs_cookie (instead it's some intermediate assembly generated in /tmp; I'll investigate if there is anything actionable). All remaining 2564 warnings are in jit related to the same bit field width.

[SingleAccretion]

I think the proper way to fix the range checks is to use the FitsIn<T>() method (e. g. FitsIn<int32_t>(value)).

[am11]

I think the proper way to fix the range checks is to use the FitsIn<T>() method (e. g. FitsIn<int32_t>(value)).

Thanks, wow didn't realize something like that exists. I will try FitsIn<T> next. 👍
I was looking a way to plumb std::numeric_limits<T>::max and friends through PAL, experimented with it a bit, but unsurprisingly it had longer tail (works on one platform doesn't meant it'd cover the matrix). 😅

[am11]

@jakobbotsch, should we worry about other usages of FitsIn<T>() on 32-bit platforms and fix that for cases like FitsIn<int>(anUnsignedInt)? Note that we have globally turned off family of tautological comparison warnings, so bug in utility function can get slipped rather easily.

[jakobbotsch]

@jakobbotsch, should we worry about other usages of FitsIn() on 32-bit platforms and fix that for cases like FitsIn(anUnsignedInt)?

I don't think so, FitsIn is a quite semantic operation, asking if the "semantic" value can be represented in another data type. It's not always the operation we want in the JIT when we want to cast between signed/unsigned values for various reasons.

[jakobbotsch]

Thanks!