<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - AArch64 StackTagging pass crash"
href="https://bugs.llvm.org/show_bug.cgi?id=49268">49268</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>AArch64 StackTagging pass crash
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: AArch64
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jjpenix@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>arnaud.degrandmaison@arm.com, llvm-bugs@lists.llvm.org, smithp352@googlemail.com, Ties.Stuij@arm.com
</td>
</tr></table>
<p>
<div>
<pre>The following IR causes an assertion to fail when the AArch64StackTagging pass
is run with 'opt --aarch64-stack-tagging [FILE]' or 'llc [FILE]':
; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "test.cpp"
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-unknown-linux-gnu"
%0 = type { %1 }
%1 = type { %2 }
%2 = type { i32*, i32*, i32* }
%3 = type { %0 }
; Function Attrs: sanitize_memtag
define dso_local i32 @main() #0 {
%1 = alloca %0, align 8
%2 = alloca %3, align 8
call void @_ZN3FooD2Ev(%3* nonnull dereferenceable(24) %2) #2
call void @_ZNSt6vectorIiSaIiEED2Ev(%0* nonnull dereferenceable(24) %1) #2
ret i32 0
}
declare dso_local void @_ZN3FooD2Ev(%3*) unnamed_addr #1 align 2
declare dso_local void @_ZNSt6vectorIiSaIiEED2Ev(%0*) unnamed_addr #1 align 2
attributes #0 = { sanitize_memtag }
attributes #1 = { "use-soft-float"="false" }
attributes #2 = { nounwind }
!llvm.ident = !{!0}
!0 = !{!"clang version 13.0.0 (<a href="https://github.com/llvm/llvm-project">https://github.com/llvm/llvm-project</a>
85f025e5b33d148808177427eebca4cc14f93079)"}
The assertion/stack trace produced is as follows:
/llvm-project/llvm/include/llvm/Support/Casting.h:269: typename
llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::Function; Y =
llvm::Value; typename llvm::cast_retty<X, Y*>::ret_type = llvm::Function*]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
PLEASE submit a bug report to <a href="https://bugs.llvm.org/">https://bugs.llvm.org/</a> and include the crash
backtrace.
Stack dump:
0. Program arguments: opt --aarch64-stack-tagging
bugpoint-reduced-simplified.ll
1. Running pass 'Function Pass Manager' on module
'bugpoint-reduced-simplified.ll'.
2. Running pass 'AArch64 Stack Tagging' on function '@main'
#0 0x00007f5639c33dd4 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/mortimer/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:0
#1 0x00007f5639c33e8b PrintStackTraceSignalHandler(void*)
/home/mortimer/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:0
#2 0x00007f5639c31b49 llvm::sys::RunSignalHandlers()
/home/mortimer/llvm-project/llvm/lib/Support/Signals.cpp:71:0
#3 0x00007f5639c33755 SignalHandler(int)
/home/mortimer/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:0
#4 0x00007f56429d3980 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#5 0x00007f5639112fb7 raise
/build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#6 0x00007f5639114921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
#7 0x00007f563910448a __assert_fail_base
/build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0
#8 0x00007f5639104502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#9 0x00007f563a21e396 llvm::cast_retty<llvm::Function, llvm::Value*>::ret_type
llvm::cast<llvm::Function, llvm::Value>(llvm::Value*)
/home/mortimer/llvm-project/llvm/include/llvm/Support/Casting.h:269:0
#10 0x00007f563a41ca0e llvm::Intrinsic::getDeclaration(llvm::Module*, unsigned
int, llvm::ArrayRef<llvm::Type*>)
/home/mortimer/llvm-project/llvm/lib/IR/Function.cpp:1281:0
#11 0x00007f564e9f9c18 (anonymous
namespace)::AArch64StackTagging::runOnFunction(llvm::Function&)
/home/mortimer/llvm-project/llvm/lib/Target/AArch64/AArch64StackTagging.cpp:686:0
#12 0x00007f563a4a21bc llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1434:0
#13 0x00007f563a4a2465 llvm::FPPassManager::runOnModule(llvm::Module&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1480:0
#14 0x00007f563a4a288d (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1549:0
#15 0x00007f563a49da75 llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:540:0
#16 0x00007f563a4a3117 llvm::legacy::PassManager::run(llvm::Module&)
/home/mortimer/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1677:0
#17 0x000055bb8c06c73d main
/home/mortimer/llvm-project/llvm/tools/opt/opt.cpp:1013:0
#18 0x00007f56390f5bf7 __libc_start_main
/build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:344:0
#19 0x000055bb8c03305a _start
(/home/mortimer/llvm-project/build/bin/opt+0x7e05a)
I originally ran into this crash in Rust but it can be reproduced in C++/using
clang with the following (where the IR came from). Note that the 'opt --strip'
step is needed to reproduce:
// Compile with 'clang++ -target aarch64-unknown-linux-gnu -fsanitize=memtag
-march=armv8+memtag -c -emit-llvm [FILE]'
// Run 'opt --strip --aarch64-stack-tagging [FILE]', this crashes (or just run
strip then llc)
#include <vector>
struct Foo {
std::vector<int> data;
};
int main() {
auto a = std::vector<int>();
auto b = Foo { std::vector<int>() };
}
My understanding is that the two allocas share the same "shape", but are
considered different types. When the pass tries to get the declaration for the
aarch64_tagp intrinsic for each of the allocas, they resolve to the same
intrinsic name (llvm.aarch64.tagp.p0sl_s_sa8i8s), but have different actual
types (ex: { %"type 0x55fa23ce6470", [8 x i8] }* vs { %"type 0x55fa23ce63d0",
[8 x i8] }*), resulting in a bitcast being returned from
Module::getOrInsertFunction and the cast to a Function* in
Intrinsic::getDeclaration to fail. This does not happen without the '--strip'
step as the two allocas resolve to different intrinsic names
(llvm.aarch64.tagp.p0sl_s_class.std::vectorsa8i8s vs
llvm.aarch64.tagp.p0sl_s_struct.Foosa8i8s) so new declarations are returned for
the two allocas.
I'm not sure how to resolve this. Maybe the Intrinsic::getName or
getMangledTypeStr functions should account for unique types? Maybe
Module::getOrInsertFunction should still create a new function declaration if
the found one is related to an overloaded intrinsic? I'm unsure as to the
broader implications of each/if there is an altogether different/better
approach--any advice would be greatly appreciated!</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>