The mac failure is something about orc and unwinding exceptions through jit-compiled code on mac, which we don't need, but I don't immediately see how to turn it off.

Let's merge this already to revive all the other tests. I need them to validate the transcendentals.

I pushed a version without the ifdef, but we'll have to wait for the bots to verify it works with llvm 18

Time to learn about the buildbots. Can I temporarily disable build bots on my PR by adding the skip_buildbots tag and remove it later? Would be useful to free up build bot compute for priority PRs like this.

The mac failure is something about orc and unwinding exceptions through jit-compiled code on mac, which we don't need, but I don't immediately see how to turn it off.

How did you diagnose this?

Also, two thoughts:

• ORC seems to be a Linux thing, when I do some internet searches. Is that the issue: LLVM doing ORC things for macOS?
• I'd be careful disabling unwinding stuff, unless it's specific to exceptions. Debugability is nice. I don't know what the particular thing you diagnosed is or does. Like mentioned by @alexreinking recently, the Halide pipelines are meant to be exception-free and non-breakable, but that's not the case for the runtime.

I diagnosed it by searching the LLVM source for the cantFail call that failed.

LLVM's orc is the JIT engine for all platforms, and they recently made some macos changes. Unwinding is specific to exceptions. We can't actually do any unwinding through our generated code because we don't register any unwinding information to do things like free our allocations, so it doesn't matter if the JIT engine supports it. The runtime isn't allowed to throw exceptions for this reason too.

I diagnosed it by searching the LLVM source for the cantFail call that failed.

Halide also has a handful of cantFail calls in the source, related to jitting. Did you check those?
https://github.com/search?q=repo%3Ahalide%2FHalide%20cantFail&type=code

@abadams The mac failure seemed to disappear overnight. I guess this was a real mistake on LLVM's side...