aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/CodeGenPrepare.cpp
diff options
context:
space:
mode:
authorMartin Storsjo <martin@martin.st>2019-01-29 09:00:32 +0000
committerMartin Storsjo <martin@martin.st>2019-01-29 09:00:32 +0000
commitd27bec48542e9638ff41033ad714e90207b53c68 (patch)
tree7dc95d87cc2b3a83312c3b53463706fb25fb1795 /llvm/lib/CodeGen/CodeGenPrepare.cpp
parent27631cc670c169e99f1e8cbb03661a3aab092dcf (diff)
downloadllvm-d27bec48542e9638ff41033ad714e90207b53c68.zip
llvm-d27bec48542e9638ff41033ad714e90207b53c68.tar.gz
llvm-d27bec48542e9638ff41033ad714e90207b53c68.tar.bz2
Don't define unw_fpreg_t to uint64_t for __ARM_DWARF_EH__
The existing typedef of unw_fpreg_t to uint64_t might work and be correct for the ARM_EHABI case, but for dwarf, some cases in e.g. DwarfInstructions.hpp convert between double and unw_fpreg_t. When converting implicitly between double and unw_fpreg_t (uint64_t), the values get interpreted as integers and converted to float and vice versa, while the correct thing would be to keep the same bit pattern. Avoid the whole issue by using the same definition of unw_fpreg_t as all other architectures, when using dwarf unwinding on ARM. Change assembler functions to take a void pointer instead of unw_fpreg_t pointer, to avoid having a different mangled symbol name depending on the actual value of this typedef. Differential Revision: https://reviews.llvm.org/D57001 llvm-svn: 352461
Diffstat (limited to 'llvm/lib/CodeGen/CodeGenPrepare.cpp')
0 files changed, 0 insertions, 0 deletions