-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gollvm: cannot use unsafe.Pointer as map key type #52861
Comments
cc @thanm |
Source code:
and the AST is generated as:
and the LLVM IR is generated as:
In the IR above, the load instruction "%deref.ld.0 = load i64, i64 %cast.22, align 8, !dbg !86" is incorrect.* I find that in the function: "Bexpression *Llvm_backend::materializeConversion(Bexpression *convExpr)", the current logic misses the case: "dref(conv(addr(ptr_type), another_ptr_type)", in the code below, the expr's pending context is incorrectly reset(by calling resolveVarContext), so the later dref expression generates an additional load instruction.
|
@thanm This test case works as expected with gccgo. Assigning to you to check GoLLVM at your leisure. |
GOLLVM has a miscompilation bug that can be reproduced with the following test case.
The bug can be reproduced with trunk:
In the following test case,
m
is a map withunsafe.Pointer
as key type. Methodtest
simply adds keyp
into mapm
and returns true if the key is not present in the map. Sook1
should betrue
andok2
should befalse
. Thegc
compiler can produce the correct output whereas GOLLVM miscompiles and leads to wrong output, i.e., bothok1
andok2
are true.Below is the LLVM IR obtained via option
-tracelevel=1
.We can find that there is an additional load that converts
i8**
intoi8*
and theni8*
is converted intoi64*
,which means not the address of
p
(i.e., typei8**
) is converted intoi64*
but thep
(i.e., typei8*
) itself is converted intoi64*
().It seems that there is something wrong with the propagation of
VarContext
. Additional load operations are generated during materialization.The text was updated successfully, but these errors were encountered: