Failure to build stable branch with LLVM 3.3 / 3.4

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Failure to build stable branch with LLVM 3.3 / 3.4

jbect
Hi all,

The attached unit test, extracted form test/jit.tst, fails when I build on the stable branch with LLVM 3.3 or 3.4.

I tried bisecting to find when the problem appeared, but I currently cannot go back beyond cs aab79a1885cc (june 2016, "limit gnulib headers to liboctave/wrappers directory") because of some gnulib/gcc6 related problem apparently.

Does anybody which version of LLVM Octave was last reported to work with ?

Has anyone been able to compile with --enable-jit and pass all the tests in test/jit.tst since june 2016 ?

@++
Julien


jit_tst_that_fails.m (330 bytes) Download Attachment
jit_tst_that_fails.log (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Failure to build stable branch with LLVM 3.3 / 3.4

Michael Godfrey
You may want to look at bug#51574 which discusses work to get LLVM 3.8 to work in
current dev.

On 11/03/2017 08:50 PM, Julien Bect wrote:
Has anyone been able to compile with --enable-jit and pass all the tests in test/jit.tst since june 2016 ?

Reply | Threaded
Open this post in threaded view
|

Re: Failure to build stable branch with LLVM 3.3 / 3.4

jbect
Le 03/11/2017 à 22:17, Michael D Godfrey a écrit :
You may want to look at bug#51574 which discusses work to get LLVM 3.8 to work in
current dev.

Yes, I know, I am the one working on #51574 ;-)

As I explained there, I am now in a position where I can compile the default branch with LLVM 3.8, pass a significant portion of the unit tests, and get a decent speed-up on some test loops.

But I get test failures that I don't undertstand there, so I think that I should first have a working version of Octave with --enable-jit to compare to.

Which is why I am back to the stable branch, with LLVM 3.3/3.4, trying understand why things stopped working...
Reply | Threaded
Open this post in threaded view
|

Re: Failure to build stable branch with LLVM 3.3 / 3.4

jbect
In reply to this post by jbect
Le 03/11/2017 à 21:50, Julien Bect a écrit :
>
> The attached unit test, extracted form test/jit.tst, fails when I
> build on the stable branch with LLVM 3.3 or 3.4.


I suspect that the regression comes from the fact that out-of-range
indexing once changed the error_state variable and now (since ~ the end
of 2015 ?) throws an octave::out_of_range exception.

If I understand correctly, the existing JIT handles error by looking at
the error_state variable.

Does that make any sense ?


Reply | Threaded
Open this post in threaded view
|

Re: Failure to build stable branch with LLVM 3.3 / 3.4

Michael Godfrey

On 11/03/2017 09:51 PM, Julien Bect wrote:
Le 03/11/2017 à 21:50, Julien Bect a écrit :

The attached unit test, extracted form test/jit.tst, fails when I build on the stable branch with LLVM 3.3 or 3.4.


I suspect that the regression comes from the fact that out-of-range indexing once changed the error_state variable and now (since ~ the end of 2015 ?) throws an octave::out_of_range exception.

If I understand correctly, the existing JIT handles error by looking at the error_state variable.

Does that make any sense ?

I did some testing of the LLVM 3.4 version but I would not be confident
that it was robust. So, it would not surprise me if it had out-of-range problems.
And, it stopped working due to the updates of LLVM.
Many things have changed since then. So, it may be quicker to keep working
on the 3.8 version in the current dev system.
Reply | Threaded
Open this post in threaded view
|

Re: Failure to build stable branch with LLVM 3.3 / 3.4

jbect
In reply to this post by jbect
Le 03/11/2017 à 22:51, Julien Bect a écrit :

> Le 03/11/2017 à 21:50, Julien Bect a écrit :
>>
>> The attached unit test, extracted form test/jit.tst, fails when I
>> build on the stable branch with LLVM 3.3 or 3.4.
>
>
> I suspect that the regression comes from the fact that out-of-range
> indexing once changed the error_state variable and now (since ~ the
> end of 2015 ?) throws an octave::out_of_range exception.
>
> If I understand correctly, the existing JIT handles error by looking
> at the error_state variable.
>
> Does that make any sense ?

Just found out a relevant bug report : https://savannah.gnu.org/bugs/?46192.