aboutsummaryrefslogtreecommitdiffstats
path: root/plt
diff options
context:
space:
mode:
authorMagnus Lång <[email protected]>2016-11-07 17:37:22 +0100
committerMagnus Lång <[email protected]>2016-11-07 18:04:53 +0100
commitd5f0e614ab2998a153de569290bf2fca78d88af6 (patch)
tree0527dbcff1380e23b50299b3fa03639ae545ae2c /plt
parent3e06b82f0f29d90bff0783e7f3d1dabb435782f5 (diff)
downloadotp-d5f0e614ab2998a153de569290bf2fca78d88af6.tar.gz
otp-d5f0e614ab2998a153de569290bf2fca78d88af6.tar.bz2
otp-d5f0e614ab2998a153de569290bf2fca78d88af6.zip
hipe_llvm: Fix incorrect atom alignment assumption
ErLLVM was declaring atoms in the following manner: @atom_ok = external constant i64 ; Used inside a function like this %var = ptrtoint i64* @atom_ok to i64 However, doing so makes LLVM think the `atom_ok` is 8-byte aligned, since it refers to a i64 value. This resulted in LLVM occasionally incorrectly optimising away type tests on atoms, causing incorrect behaviour or even segfaults. One such case is in bs_match_compiler:coverage_apply/2, in which an is_boxed test on a literal atom was optimised away, causing the code to try and load the "header" of an atom. This problem reproduces with LLVM versions 3.7 through 3.9. By declaring atoms as i8 (byte) constants instead, LLVM no longer makes these alignment assumptions, and the bug is fixed.
Diffstat (limited to 'plt')
0 files changed, 0 insertions, 0 deletions