mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 18:54:02 +01:00
e84c42802f
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.
6 lines
175 B
LLVM
6 lines
175 B
LLVM
; RUN: opt -S -inferattrs < %s | FileCheck %s
|
|
|
|
; CHECK: Function Attrs: nobuiltin allocsize(0)
|
|
; CHECK: declare i8* @_Znwm(i32)
|
|
declare i8* @_Znwm(i32) nobuiltin allocsize(0)
|