On Thu, Mar 22, 2018 at 11:46 AM, Andres Freund <and...@anarazel.de> wrote: > On 2018-03-22 11:36:47 +1300, Thomas Munro wrote: >> Not sure if we'll want to try to actively identify and avoid known >> buggy versions or not? > > I'm currently not inclined to invest a lot of effort into it, besides > trying to get the bug fixed. > > A possible testcase would be to call > createLocalIndirectStubsManagerBuilder() and report an error if it > returns nullptr. But that'd fail once the bug is fixed, because we don't > actually *need* that functionality, it's just that LLVM instantiates the > stub manager unconditionally for some reason.
So how about we test createLocalIndirectStubsManagerBuilder(), and if it's nullptr then we also test the LLVM version number? For each major release (3.9, 4.0, 5.0, ... you can see that they did the same kind of versioning schema change that we did!) there will eventually be a minor/patch release number where this works even when nullptr is returned here. This problem is going to come up on any architecture not covered in the following code, namely anything but x86, x86_64 and (since 6.0) aarch64 (aka arm64), so we definitely don't want to leave JIT disabled once that bug is fixed: https://github.com/llvm-mirror/llvm/blob/release_39/lib/ExecutionEngine/Orc/IndirectionUtils.cpp#L48 https://github.com/llvm-mirror/llvm/blob/release_60/lib/ExecutionEngine/Orc/IndirectionUtils.cpp#L48 -- Thomas Munro http://www.enterprisedb.com