Overflowing negative constants in printed x64 assembly

[ashay]

Description

https://godbolt.org/z/jfPx7oenM

When constants are smaller than -0x1000000 and DOTNET_JitDisasm is set, the runtime prints these as 64-bit constants, even if the instruction expects a 32-bit constant (based on the register widths of the instruction). This can result in invalid assembly code like mov eax, 0xFFFFFFFFFEFFFFFF.

To be precise, the assembled program is correct, only the printing of the program is incorrect.

Reproduction Steps

using System.Runtime.CompilerServices;

class Program
{
  public static void Main(string[] args)
  {
  }

  [MethodImpl(MethodImplOptions.NoInlining)]
  public int foo(int x)
  {
    return -0x1000001;
  }
}

Expected behavior

mov      eax, 0xFEFFFFFF

Actual behavior

mov      eax, 0xFFFFFFFFFEFFFFFF

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[xtqqczze]

This can result in invalid assembly code like mov eax, 0xFFFFFFFFFEFFFFFF.

It’s not actually invalid, it’s the same encoded immediate, just printed in a sign-extended 64-bit form instead of the narrower 32-bit form that the instruction consumes.

The constant is faithfully represented, just not in the canonical width for the operand.

[ashay]

I agree. Hence the line:

To be precise, the assembled program is correct, only the printing of the program is incorrect.

[xtqqczze]

To be precise, the assembled program is correct, only the printing of the program is incorrect.

The disassembly output is not "incorrect" either, the immediate is unambiguously represented.

Tools like llvm-mca understand this representation with no issue:
https://analysis.godbolt.org/z/KG9fMqcnc

[JulieLeeMSFT]

Closing this issue as the author closed his PR per the comment in #118814 (comment).