test-charpoly fails on MIPS

[latinovic]

On Debian, linbox fails to build for mips and mipsel on testing:

FAIL: test-charpoly

Full log:
https://buildd.debian.org/status/fetch.php?pkg=linbox&arch=mipsel&ver=1.3.2-1.1%2Bb4&stamp=1467891077

I had tested latest version, same tests failed, but with this time with Segmentation Fault.

I have investigated this issue further here is a back trace:

#0  0x77b242e0 in __gmpz_set () from /usr/lib/mipsel-linux-gnu/libgmp.so.10
#1  0x77bc56e8 in __gmpz_neg (__gmp_u=0x4ad4d0, __gmp_w=0x7ffdec18) at /usr/include/mipsel-linux-gnu/gmp.h:1813
#2  Givaro::Integer::operator- (this=0x4ad4d0) at gmp++_int_add.C:136
#3  0x77bc050c in Givaro::Integer::operator-= (this=0x5630c0, n=...) at gmp++_int_sub.C:90
#4  0x0044fa38 in LinBox::FullMultipCRA<Givaro::Modular<double, double> >::smallbigreconstruct (this=0x7ffdeed8, invprod=..., u0=..., u1=...) at ../linbox/algorithms/cra-full-multip.h:634
#5  LinBox::FullMultipCRA<Givaro::Modular<double, double> >::progress<Givaro::Modular<double, double> > (this=this@entry=0x7ffdeed8, D=..., e=...) at ../linbox/algorithms/cra-full-multip.h:413
#6  0x00465e3c in LinBox::EarlyMultipCRA<Givaro::Modular<double, double> >::progress<Givaro::Modular<double, double> > (e=..., D=..., this=0x7ffdeea8) at ../linbox/algorithms/cra-early-multip.h:176
#7  LinBox::ChineseRemainderSeq<LinBox::EarlyMultipCRA<Givaro::Modular<double, double> > >::operator()<LinBox::BlasVector<Givaro::ZRing<Givaro::Integer>, std::vector<Givaro::Integer, std::allocator<Givaro::Integer> > >, LinBox::IntegerModularCharpoly<LinBox::ScalarMatrix<Givaro::ZRing<Givaro::Integer> >, LinBox::BlasEliminationTraits>, LinBox::RandomPrimeIterator> (this=0x7ffdeea8, res=..., Iteration=..., primeiter=...)
    at ../linbox/algorithms/cra-domain-seq.h:212
#8  0x0046628c in LinBox::charpoly<LinBox::BlasVector<Givaro::ZRing<Givaro::Integer>, std::vector<Givaro::Integer, std::allocator<Givaro::Integer> > >, LinBox::ScalarMatrix<Givaro::ZRing<Givaro::Integer> > > (
    P=..., A=..., tag=..., M=...) at ../linbox/solutions/charpoly.h:446
#9  0x004665bc in LinBox::charpoly<LinBox::ScalarMatrix<Givaro::ZRing<Givaro::Integer> >, LinBox::BlasVector<Givaro::ZRing<Givaro::Integer>, std::vector<Givaro::Integer, std::allocator<Givaro::Integer> > > > (
    M=..., tag=..., A=..., P=...) at ../linbox/solutions/charpoly.h:224
#10 LinBox::charpoly<LinBox::ScalarMatrix<Givaro::ZRing<Givaro::Integer> >, LinBox::BlasVector<Givaro::ZRing<Givaro::Integer>, std::vector<Givaro::Integer, std::allocator<Givaro::Integer> > >, LinBox::HybridSpecifier> (M=..., A=..., P=...) at ../linbox/solutions/charpoly.h:75
#11 LinBox::charpoly<LinBox::ScalarMatrix<Givaro::ZRing<Givaro::Integer> >, LinBox::BlasVector<Givaro::ZRing<Givaro::Integer>, std::vector<Givaro::Integer, std::allocator<Givaro::Integer> > > > (P=..., A=...)
    at ../linbox/solutions/charpoly.h:84
#12 0x00420110 in testIdentityCharpoly<Givaro::ZRing<Givaro::Integer> > (Z=..., n=50, symmetrizing=<optimized out>) at test-charpoly.C:101
#13 0x00411e8c in main (argc=<optimized out>, argv=<optimized out>) at test-charpoly.C:351

The problem is that _mp_d value in __gmp_u is 0 (frame 1: /usr/include/mipsel-linux-gnu/gmp.h:1813)

p *__gmp_u
$3 = {_mp_alloc = 6023144, _mp_size = 17, _mp_d = 0x0}

I believe that the reason for this is frame 5: (../linbox/algorithms/cra-full-multip.h:413)

p t_it._iter._M_current.gmp_rep 
$5 = {_mp_alloc = 6023144, _mp_size = 17, _mp_d = 0x0}

408                     BlasVector<Givaro::ZRing<Integer> >::iterator      ri_it = ri.begin();
409                     BlasVector<Givaro::ZRing<Integer> >::const_iterator t_it= _tab_it->begin();
410 
411                     Integer invprod; precomputeInvProd(invprod, mi(), _mod_it->operator()());
412                     for( ; ri_it != ri.end(); ++ri_it, ++ t_it)
413                         smallbigreconstruct(*ri_it, *t_it, invprod);
414 
415                     // Product (lazy) computation
416                     mi.mulin(*_mod_it);

I am not sure why this happens, and why this issues appears only on mips and mipsel.
It seems that the version that fails now (on Debian 1.3.2-1.1) had been built successfully in the past but with older toolchain,
Also if the test is built with lover optimization level, the test executes successfully.
The same happen if flag -fno-inline is added during test compilation.

I will investigate this issue further, any help would be appreciated.

Dejan