You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After commit 8101d18 was merged into our downstream repo, we started to see assertion failures in many of our tests, and it seems many buildbots also hit the same assertion failure.
Here is a reduced version of one of our internal tests that hits the assertion failure:
/* repro.cpp */
#definea() structusing b = float;
a() c { b d; };
using n = b;
voide(n *, long, long);
long f;
float *g;
voidh(n *i, long j) {
for (long k; f; ++k)
for (long l = 0; l < j; ++l)
g[l * k] = i[l];
c input[]{{}, {}, {}, {}, {}, {}, {}, 15.1f, 16.1f};
e(reinterpret_cast<b *>(input), 2, 6);
}
voidm() {
c input[]{16.1f};
h(reinterpret_cast<b *>(input), 6);
}
When compiled with optimizations using a compiler built from 9bb7c11 (the change immediately preceding 8101d18) there is no assertion failure and it succeeds (although the assertion failure was added in the mentioned commit so it makes sense the previous commit would not hit it, but I digress):
A dominance query of a block that is in a different function is
ill-defined, so assert that getNode() is only called for blocks that are
in the same function.
There are three cases, where this behavior did occur. LoopFuse didn't
explicitly do this, but didn't invalidate the SCEV block dispositions,
leaving dangling pointers to free'ed basic blocks behind, causing
use-after-free. We do, however, want to be able to dereference basic
blocks inside the dominator tree, so that we can refer to them by a
number stored inside the basic block.
Reverts llvm#102780
Reland llvm#101198Fixesllvm#102784
Co-authored-by: Alexis Engelke <engelke@in.tum.de>
After commit 8101d18 was merged into our downstream repo, we started to see assertion failures in many of our tests, and it seems many buildbots also hit the same assertion failure.
Here is a reduced version of one of our internal tests that hits the assertion failure:
When compiled with optimizations using a compiler built from 9bb7c11 (the change immediately preceding 8101d18) there is no assertion failure and it succeeds (although the assertion failure was added in the mentioned commit so it makes sense the previous commit would not hit it, but I digress):
When compiled with optimizations using a compiler built from 8101d18, we see an assertion failure during the compilation:
The text was updated successfully, but these errors were encountered: