Re: [eigen] SparseQR compilation error

On Tue, Aug 20, 2013 at 9:59 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

On Tue, Aug 20, 2013 at 2:56 PM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx> wrote:

Nothing changed :( - same memory violations, at least for Scalar = mpreal & MSVC2010 compiler.

"memory violations"? I thought we were talking about a compilation issue?

gael

Cannot run detailed diagnostics now, will do it as soon as will got access to Intel Compiler.

Thank you for looking at this!

On Tue, Aug 20, 2013 at 9:35 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

This might bypass some operator= overloads. What about the patch below. If it does not work, removing the "private:" line should work.

gael.

diff --git a/Eigen/src/SparseCore/SparseBlock.h b/Eigen/src/SparseCore/SparseBlock.h
--- a/Eigen/src/SparseCore/SparseBlock.h

+++ b/Eigen/src/SparseCore/SparseBlock.h
@@ -61,16 +61,19 @@ public:
EIGEN_STRONG_INLINE Index rows() const { return IsRowMajor ? m_outerSize.value() : m_matrix.rows(); }
EIGEN_STRONG_INLINE Index cols() const { return IsRowMajor ? m_matrix.cols() : m_outerSize.value(); }

protected:

typename XprType::Nested m_matrix;
Index m_outerStart;
const internal::variable_if_dynamic<Index, OuterSize> m_outerSize;

+
+ private:
+ EIGEN_INHERIT_ASSIGNMENT_OPERATORS(BlockImpl)
};

/***************************************************************************

* specialisation for SparseMatrix
***************************************************************************/

template<typename _Scalar, int _Options, typename _Index, int BlockRows, int BlockCols>

On Wed, Aug 14, 2013 at 2:19 PM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx> wrote:

Issue can be fixed by uncommenting line 107 in src/Core/Block.h.

Was (causes Intel C++ to go crazy):
//typedef typename Impl::Base Base;
typedef Impl Base;

Now (compiles fine with Intel C++ & MSVC2010):
typedef typename Impl::Base Base;

//typedef Impl Base;

Please confirm if this acceptable fix.

On Wed, Aug 14, 2013 at 5:38 PM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx> wrote:

Seems that Intel might not fix the issue in a short time :(.

Is there any way to overcome the issue from our side?

Maybe by some (small) changes of code in SparseQR, so that "operator=" of "Eigen::BlockImpl" is much more visible for ICC ;) ?

Will be happy to provide any assistance in this respect.

ICC is widely used on Windows, would be unfortunate to loose compatibility with it.

Pavel.

On Tue, Aug 13, 2013 at 3:41 PM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx> wrote:
Yes, ICC gives the same error on the _expression_ alone:

typedef Eigen::SparseMatrix< double > SparseDoubleMatrix;
typedef SparseDoubleMatrix::Index Index;

typedef PermutationMatrix<Dynamic, Dynamic, Index> PermutationType;

SparseDoubleMatrix A(10,10);
PermutationType pivotperm;

pivotperm.setIdentity(A.cols());

A = A * pivotperm; // <- same error here

Have no idea why.

On Mon, Aug 12, 2013 at 9:45 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

not really because it fails on that line of SparseQR:

m_R = tempR * m_pivotperm;

where m_R and tempR are SparseMatrix<double> and m_pivotperm is a permutation matrix. The block expressions are triggered in the permutation product code. It would be interesting to see if the above _expression_ alone leads to the same error.

gael

On Mon, Aug 12, 2013 at 1:56 PM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx> wrote:

Of course they are different :).

I meant the way they use components which compiler doesn't like.

I assume they both using Eigen::Block (?), in QR this leads to error but in LU it is fine.

Maybe this fact could help in adjusting QR to avoid problem with compiler (as in LU).

That was just an idea.

On Mon, Aug 12, 2013 at 8:45 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

On Mon, Aug 12, 2013 at 1:04 PM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx> wrote:

I reported this issue on Intel C++ forum.
From my experience Windows version of ICC seems to have many problems (as newer as more buggy).
Will probably try to roll back to older version.

ok, let's see.

How much SparseLU different from SparseQR architecture-wise?

SparseLU has same interface and works just fine. Maybe we can do SparseQR in similar way ;)?

beside the interface and the elimination tree, they have absolutely nothing in common!

gael

On Mon, Aug 12, 2013 at 7:51 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

Hi,

as already observed on the forum, this error seems to show up only with ICC on Windows. No problem with ICC 11, 12, 13 on Linux. Moreover, I don't understand this issue as the base class "Eigen::BlockImpl<const Eigen::SparseMatrix<double, 0, int>, -1, 1, 1, Eigen::Sparse>" does has an operator= line 194 in src/SparseCore/SparseBlock.h. So I'm clueless here.

gael

On Sat, Aug 10, 2013 at 11:23 AM, Pavel Holoborodko <pavel@xxxxxxxxxxxxxxx> wrote:

Hi,

I am testing solvers for sparse systems.

Intel C++ compiler chokes on this code:

typedef Eigen::SparseMatrix< double > SparseDoubleMatrix;

SparseQR< SparseDoubleMatrix, COLAMDOrdering<int> > solver;

SparseDoubleMatrix A(10,10);
solver.compute(A);

Compiler points to solver.compute(A) with error message:

class "Eigen::BlockImpl<const Eigen::SparseMatrix<double, 0, int>, -1, 1, 1, Eigen::Sparse>" has no member "operator="

Error persist for any OrderingType.

Interestingly, error only shows for SparseQR. If I use SparseLU - everything compiles fine.

Full template instantiation chain lead to error is in attachment.

Would appreciate any help & pointers how to solve the problem.

Thank you,
Pavel.