aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenFunction.cpp
diff options
context:
space:
mode:
authorPhilip Reames <listmail@philipreames.com>2021-04-16 15:28:15 -0700
committerPhilip Reames <listmail@philipreames.com>2021-04-16 15:36:15 -0700
commit11707435ccb44a9377bfed407453e0646a159636 (patch)
treefd77f60f4c5b431313778dfe8a2fcfe686960869 /clang/lib/CodeGen/CodeGenFunction.cpp
parentbc636c1c2c8aafeac5ce3aba0b268fdcb1914864 (diff)
downloadllvm-11707435ccb44a9377bfed407453e0646a159636.zip
llvm-11707435ccb44a9377bfed407453e0646a159636.tar.gz
llvm-11707435ccb44a9377bfed407453e0646a159636.tar.bz2
[inferattrs] Don't infer lib func attributes for nobuiltin functions
If we have a nobuiltin function, we can't assume we know anything about the implementation. I noticed this when tracing through a log from an in the wild miscompile (https://github.com/emscripten-core/emscripten/issues/9443) triggered after 8666463. We were incorrectly assuming that a custom allocator could not free. (It's not clear yet this is the only problem in said issue.) I also noticed something similiar mentioned in the commit message of ab243e when scrolling back through history. Through, from what I can tell, that commit fixed symptom not root cause. The interface we have for library function detection is extremely error prone, but given the interaction between ``nobuiltin`` decls and ``builtin`` callsites, it's really hard to imagine something much cleaner. I may iterate on that, but it'll be invasive enough I didn't want to hold an obvious functional fix on it.
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.cpp')
0 files changed, 0 insertions, 0 deletions