[eigen] Re: 3.0.4 coming soon, testing appreciated

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

Benoit Jacob <jacob.benoit.1@...> writes:

> This is now fixed in both branches: f7e4c54e8c44 in default branch,
> dfea1f0cbf7a in 3.0 branch.
> Can you please retry?
> The fix is very nontrivial so I would like to discuss it here.
> We used to have 2 different ways of computing whether we statically
> align types: one for the actual static alignment stuff in
> DenseStorage.h, checking if the byte size is a multiple of 16 bytes,
> and one for the AlignedBit flag computation in compute_matrix_flags in
> XprHelper.h, checking if the Scalar type is vectorizable and if
> Rows*Cols is a multiple of the vectorization packet size.
> For example, when vectorization is disabled, Matrix4d is still
> statically aligned (we need that to preserve the ABI) but its Flags do
> not have the AlignedBit.

It looks like this introduced another problem which manifests itself in the
matrix_exponential_8 test failing occasionally. The issue is illustrated by the
following program:

int main()
  Matrix<std::complex<long double>, 2, 2> mat1;
  std::cout << mat1.data() << std::endl;
  std::cout << mat1.col(0) << std::endl;

The last line fails 50% of the time on the assertion on MapBase.h:174 which is

(size_t(m_data) % (sizeof(Scalar)*internal::packet_traits<Scalar>::size)) == 0)
        && "data is not aligned");

AlignedBit is set and sizeof(Scalar) is 32, but m_data is only aligned on a
16-byte boundary, so it bombs out.

I don't know whether it's the assertion or the computation in
compute_matrix_flags in XprHelper.h that is wrong.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/