RFR: 8370459: C2: CompressBitsNode::Value produces wrong result on Windows (1UL vs 1ULL), found by ExpressionFuzzer

[Emanuel Peter]

It seems we keep finding issues in `CompressBitsNode::Value`, using the `TemplateFramework` https://github.com/openjdk/jdk/pull/26885.

This is a JDK26 regression of the bugfix https://github.com/openjdk/jdk/pull/23947, which was itself reported by my prototype of the `TemplateFramework`.

The bug is simple: On windows `1UL` is only a 32-bit value, and not a 64-bit value. We should use `1ULL` instead. Impacted lines:
https://github.com/openjdk/jdk/blob/b02c1256768bc9983d4dba899cd19219e11a380a/src/hotspot/share/opto/intrinsicnode.cpp#L276
https://github.com/openjdk/jdk/blob/b02c1256768bc9983d4dba899cd19219e11a380a/src/hotspot/share/opto/intrinsicnode.cpp#L379

This means that simple cases like these wrongly constant fold to zero:
- `Long.compress(-2683206580L, Integer.toUnsignedLong(x))`
- `Long.compress(x, 0xffff_ffffL)`

------------------------------------------------------------------

This sort of bug (`1UL` vs `1ULL`) is of course very subtle, and easy to miss in a code review. So that is why testing is paramount.

Why was this not caught in the testing of https://github.com/openjdk/jdk/pull/23947? After all there were quite a few tests there, right? There were simply not enough tests, or not the right ones ;)

I did at the time ask for a "range-based" test (https://github.com/openjdk/jdk/pull/23947#issuecomment-2853896251). I then doubled down and even proposed a conctete test (https://github.com/openjdk/jdk/pull/23947#issuecomment-2935548411) that would create "**range-based**" inputs:

public static test(int mask, int src) {
  mask = Math.max(CON1, Math.min(CON2, mask));
  src = Math.max(CON2, Math.min(CON4, src));
  result = Integer.compress(src, mask);
  int sum = 0;
  if (sum > LIMIT_1) { sum += 1; }
  if (sum > LIMIT_2) { sum += 2; }
  if (sum > LIMIT_3) { sum += 4; }
  if (sum > LIMIT_4) { sum += 8; }
  if (sum > LIMIT_5) { sum += 16; }
  if (sum > LIMIT_6) { sum += 32; }
  if (sum > LIMIT_7) { sum += 64; }
  if (sum > LIMIT_8) { sum += 128; }
  return new int[] {sum, result};
}

What is implortant here: both the `src` and `mask` must have random ranges. But the test that ended up being integrated only made the `src` "range-based" using the `min/max`. **Without the `mask` being tested "range-based", the bug here could not have been caught by that test**.

I was asked again for my review (https://github.com/openjdk/jdk/pull/23947#issuecomment-3062355806), but I had to go on vacation, and was not able to catch the issue (https://github.com/openjdk/jdk/pull/23947).

-------------

Commit messages:
 - the constant case
 - fix v1
 - rm templated test
 - more tests
 - x7
 - x6
 - x5
 - x4
 - x3
 - x2
 - ... and 1 more: https://git.openjdk.org/jdk/compare/2c07214d...794ef7b3

Changes: https://git.openjdk.org/jdk/pull/28062/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370459
  Stats: 111 lines in 2 files changed: 96 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/28062.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28062/head:pull/28062

PR: https://git.openjdk.org/jdk/pull/28062