Steven Johnson

FYI: the crash above happens reliably on Windows, but I haven't been able to trigger anything similar on OSX or Linux builds. I'm gonna try pulling this into an experimental...

So I'm at a bit of a loss to explain the apparent use-after-free on Windows; I pulled these changes into Google and ran this test on Linux-x64 under ASAN, TSAN,...

> I suspect that this is an issue with SpecificExpr, which just grabs a reference If it is taking a reference to an Expr-that-can-go-stale, that would indeed fit the pattern...

> note that this PR relies on https://github.com/halide/Halide/pull/6900 In that case we shouldn't land this yet -- if we can't track down the failure in 6900 in the next day...

> Any chance the changes I pushed to https://github.com/halide/Halide/pull/6961 last night fixed the issues in Google? I'll try that now.

Nice work finding and fixing the dangling-reference stuff -- it didn't occur to me that you could insert `is_lvalue...` checks as a means of verification. > having SpecificExpr hold an...

(LGTM pending green)

Pulling this into Google for testing, I get many failures of the form: ``` Internal Error at [third_party/halide/halide/src/IR.cpp:42] Condition failed: a.type() == b.type(): Add of mismatched types *** SIGABRT received...

Yeah, I'd use a mutex instead -- enforcing serial ordering of the entire power_on and power_off calls seems like a wise thing.

Could we do something like: ``` qurt_mutex_t &get_mutex() { static bool is_inited = false; static qurt_mutex_t m = {0}; // probably doesn't matter if (!__atomic_test_and_set(&is_inited, __ATOMIC_ACQUIRE)) { qurt_mutex_init(&m); } return...