aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-readobj/llvm-readobj.cpp
diff options
context:
space:
mode:
authorMarco Elver <elver@google.com>2022-01-12 14:40:41 +0100
committerMarco Elver <elver@google.com>2022-01-12 15:13:10 +0100
commit732ad8ea62edc403727af57537b5d83dcfa937aa (patch)
tree3eeefb8b126db36d88f37b4d52e29b42c876e84c /llvm/tools/llvm-readobj/llvm-readobj.cpp
parentc8c3021e9fe6de5dd45e8893636399e50f3d11f7 (diff)
downloadllvm-732ad8ea62edc403727af57537b5d83dcfa937aa.zip
llvm-732ad8ea62edc403727af57537b5d83dcfa937aa.tar.gz
llvm-732ad8ea62edc403727af57537b5d83dcfa937aa.tar.bz2
[clang][auto-init] Provide __builtin_alloca*_uninitialized variants
When `-ftrivial-auto-var-init=` is enabled, allocas unconditionally receive auto-initialization since [1]. In certain cases, it turns out, this is causing problems. For example, when using alloca to add a random stack offset, as the Linux kernel does on syscall entry [2]. In this case, none of the alloca'd stack memory is ever used, and initializing it should be controllable; furthermore, it is not always possible to safely call memset (see [2]). Introduce `__builtin_alloca_uninitialized()` (and `__builtin_alloca_with_align_uninitialized`), which never performs initialization when `-ftrivial-auto-var-init=` is enabled. [1] https://reviews.llvm.org/D60548 [2] https://lkml.kernel.org/r/YbHTKUjEejZCLyhX@elver.google.com Reviewed By: glider Differential Revision: https://reviews.llvm.org/D115440
Diffstat (limited to 'llvm/tools/llvm-readobj/llvm-readobj.cpp')
0 files changed, 0 insertions, 0 deletions