On 17/01/17 13:26, Emil Velikov wrote:
> On 16 January 2017 at 14:44, Jose Fonseca wrote:
>> On 16/01/17 13:46, Emil Velikov wrote:
>>>
>>> On 14 January 2017 at 08:46, Jose Fonseca wrote:
I suspect this might break builds with LLVM 3.6 or higher.
The LLVMLinkInJIT must be ins
On 16 January 2017 at 14:44, Jose Fonseca wrote:
> On 16/01/17 13:46, Emil Velikov wrote:
>>
>> On 14 January 2017 at 08:46, Jose Fonseca wrote:
>>>
>>> I suspect this might break builds with LLVM 3.6 or higher.
>>>
>>> The LLVMLinkInJIT must be inside #if ... #endif, and it must not be
>>> expan
On 16/01/17 13:46, Emil Velikov wrote:
On 14 January 2017 at 08:46, Jose Fonseca wrote:
I suspect this might break builds with LLVM 3.6 or higher.
The LLVMLinkInJIT must be inside #if ... #endif, and it must not be expanded
when HAVE_LLVM >= 0x0306, since LLVMLinkInJIT(),
That is, when HAVE_L
On 14 January 2017 at 08:46, Jose Fonseca wrote:
> I suspect this might break builds with LLVM 3.6 or higher.
>
> The LLVMLinkInJIT must be inside #if ... #endif, and it must not be expanded
> when HAVE_LLVM >= 0x0306, since LLVMLinkInJIT(),
>
> That is, when HAVE_LLVM >= 0x0306:
> - USE_MCJIT sho
I suspect this might break builds with LLVM 3.6 or higher.
The LLVMLinkInJIT must be inside #if ... #endif, and it must not be
expanded when HAVE_LLVM >= 0x0306, since LLVMLinkInJIT(),
That is, when HAVE_LLVM >= 0x0306:
- USE_MCJIT should be static const
- no point claling GALLIVM_MCJIT
- must
Earlier commit made the decision whether to use MCJIT a run-time one. At
the same time, it changed the code-flow in the following manner:
- LLVMLinkInMCJIT() was executed regardless of whether MCJIT is to be
used or not. Admittedly it is a no-op at least in some builds.
- LLVMLinkInJIT() was exec
