diff options
author | yonghong-song <yhs@fb.com> | 2025-06-13 11:58:48 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-06-13 11:58:48 -0700 |
commit | 2f1e6eb6c3e731266052536c3f98cce3a71a316e (patch) | |
tree | d5ab90b1f5bf61eb7b0d760c13e0858d7d90162b /clang/lib/CodeGen/CodeGenModule.cpp | |
parent | a08de429e4ae0baaed23060cbae5c73dc6ffcc5d (diff) | |
download | llvm-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