diff options
author | Matt Arsenault <Matthew.Arsenault@amd.com> | 2013-10-29 20:59:29 +0000 |
---|---|---|
committer | Matt Arsenault <Matthew.Arsenault@amd.com> | 2013-10-29 20:59:29 +0000 |
commit | a1ca46d003edfb1dd461372bc398394d135707a8 (patch) | |
tree | 00b1da4e2ec9379b2f89e208be618441dc635597 /llvm/lib/CodeGen/StackProtector.cpp | |
parent | 9ab670fb54a59046301a64f5fb6bd4b72cefdfe0 (diff) | |
download | bcm5719-llvm-a1ca46d003edfb1dd461372bc398394d135707a8.tar.gz bcm5719-llvm-a1ca46d003edfb1dd461372bc398394d135707a8.zip |
Workaround MSVC 32-bit miscompile of getCondCodeAction.
Use 32-bit types for the array instead of 64. This should
generally be better anyway.
In optimized + assert builds, I saw a failure when a
cond code / type combination that is never set was loading
a non-zero value and hitting the != Promote assert.
It turns out when loading the 64-bit value to do the shift,
the assembly loads the 2 32-bit halves from non-consecutive
addresses. The address the second half of the loaded uint64_t
doesn't include the offset of the array in the struct. Instead
of being offset + 4, it's just + 4.
I'm not entirely sure why this wasn't observed before.
setCondCodeAction isn't heavily used by the in-tree targets,
and not with the higher valued vector SimpleValueTypes. Only
PPC is using one of the > 32 valued types, and that is probably
never used by anyone on a 32-bit MSVC compiled host.
I ran into this when upgrading LLVM versions, so I guess the
value loaded from the nonsense address happened to work out
before.
No test since I'm not really sure if / how it can be reproduced
with the current in tree targets, and it's not supposed to change
anything.
llvm-svn: 193650
Diffstat (limited to 'llvm/lib/CodeGen/StackProtector.cpp')
0 files changed, 0 insertions, 0 deletions