cmp compiles into an incorrect size inference when operand is a byte

[Gargaj]

When using a mov where the first operand is an address, and the second one is an immediate value with an explicit size, size inference is correct:

    12: 	mov [testval], dword 1
00ED1000 C7 05 01 40 ED 00 01 00 00 00 mov         dword ptr [testval (0ED4001h)],1  
    13: 	mov [testval], word 2
00ED100A 66 C7 05 01 40 ED 00 02 00 mov         word ptr [testval (0ED4001h)],2  
    14: 	mov [testval], byte 3
00ED1013 C6 05 01 40 ED 00 03 mov         byte ptr [testval (0ED4001h)],3  

cmp, however, treats byte as a word even if there's an explicit type declaration of treating the value as a byte. If the type declaration is on the address, the code compile correctly into a byte operation.

    15: 	cmp [testval], dword 1
00ED101A 83 3D 01 40 ED 00 01 cmp         dword ptr [testval (0ED4001h)],1  
    16: 	cmp [testval], word 2
00ED1021 66 83 3D 01 40 ED 00 02 cmp         word ptr [testval (0ED4001h)],2  
    17: 	cmp [testval], byte 3
00ED1029 66 83 3D 01 40 ED 00 03 cmp         word ptr [testval (0ED4001h)],3
    18: 	cmp byte [testval], 4
00C91031 80 3D 01 40 C9 00 04 cmp         byte ptr [testval (0C94001h)],4  

(The disassembly is from Visual Studio 2022.)

[hpax]

This is a historically awkward issue in NASM; the original implementors of NASM chose to put a size on the immediate to indicate the desired width of that immediate, not the operation size.

Therefore, what you describe here isn't a bug, but rather how the assembler is defined to work.

[hpax]

Re-opening this, because this should either have been a size match or an error due to ambiguous operand sizes.

[hpax]

Verified that NASM 2.16 treats this as a size match so this is a regression.