aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenModule.cpp
diff options
context:
space:
mode:
authoryonghong-song <yhs@fb.com>2025-06-13 11:58:48 -0700
committerGitHub <noreply@github.com>2025-06-13 11:58:48 -0700
commit2f1e6eb6c3e731266052536c3f98cce3a71a316e (patch)
treed5ab90b1f5bf61eb7b0d760c13e0858d7d90162b /clang/lib/CodeGen/CodeGenModule.cpp
parenta08de429e4ae0baaed23060cbae5c73dc6ffcc5d (diff)
downloadllvm-2f1e6eb6c3e731266052536c3f98cce3a71a316e.zip
llvm-2f1e6eb6c3e731266052536c3f98cce3a71a316e.tar.gz
llvm-2f1e6eb6c3e731266052536c3f98cce3a71a316e.tar.bz2
[BPF] Report an warning if certain insn imm operand cannot fit in 32bit (#142989)
Ihor Solodrai reported a case ([1]) where gcc reports an error but clang ignores that error and proceeds to generate incorrect code. More specifically, the problematic code looks like: if r1 == 0xcafefeeddeadbeef goto <label> Here, 0xcafefeeddeadbeef needs to be encoded in a 32-bit imm field of the insns and the 32-bit imm allows sign extenstion to 64-bit imm. Obviously, 0xcafefeeddeadbeef cannot encode properly. The compilation failed for gcc with the following error: Error: immediate out of range, shall fit in 32 bits Given a 64-bit imm value, converting to the proper 32-bit imm value must satisfy the following 64-bit patterns: 00000000 00000000 00000000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 11111111 11111111 11111111 11111111 1xxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx So if the top 32-bits is 0 or the top 33-bits is 0x1ffffffff, then the 64-bit imm value can be truncated into proper 32-bit imm. Otherwise, a warning message, the same as gcc, will be issued. If -Werror is enabled during compilation, the warning will turn into an error. [1] https://lore.kernel.org/bpf/70affb12-327b-4882-bd1d-afda8b8c6f56@linux.dev/
Diffstat (limited to 'clang/lib/CodeGen/CodeGenModule.cpp')
0 files changed, 0 insertions, 0 deletions