aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ExecutionEngine/Orc/ObjectTransformLayer.cpp
diff options
context:
space:
mode:
authorRichard Smith <richard-llvm@metafoo.co.uk>2018-05-23 21:18:00 +0000
committerRichard Smith <richard-llvm@metafoo.co.uk>2018-05-23 21:18:00 +0000
commit08b682bec1ee742425beed6e17b139aa9018a7e7 (patch)
treee775845b53c41cb523adb5eed6eba18e22c87a1f /llvm/lib/ExecutionEngine/Orc/ObjectTransformLayer.cpp
parent13229aff5401159ebac03117bd93368867fef273 (diff)
downloadllvm-08b682bec1ee742425beed6e17b139aa9018a7e7.zip
llvm-08b682bec1ee742425beed6e17b139aa9018a7e7.tar.gz
llvm-08b682bec1ee742425beed6e17b139aa9018a7e7.tar.bz2
Rework __builtin_classify_type support to better match GCC and to not assert on
unusual types. Following the observed behavior of GCC, we now return -1 for vector types (along with all of our extensions that GCC doesn't support), and for atomic types we classify the underlying type. GCC appears to have changed its classification for function and array arguments between version 5 and version 6. Previously it would classify them as pointers in C and as functions or arrays in C++, but from version 6 onwards, it classifies them as pointers. We now follow the more recent GCC behavior rather than emulating what I can only assume to be a historical bug in their C++ support for this builtin. Finally, no version of GCC that I can find has ever used the "method" classification for C++ pointers to member functions. Instead, GCC classifies them as record types, presumably reflecting an internal implementation detail, but whatever the reason we now produce compatible results. llvm-svn: 333126
Diffstat (limited to 'llvm/lib/ExecutionEngine/Orc/ObjectTransformLayer.cpp')
0 files changed, 0 insertions, 0 deletions