This bugzilla service is closed. All entries have been migrated to
Bug 1166 - MatrixXd block, VectorXd and noalias
Summary: MatrixXd block, VectorXd and noalias
Alias: None
Product: Eigen
Classification: Unclassified
Component: Core - expression templates (show other bugs)
Version: 3.3 (current stable)
Hardware: All All
: Normal Wrong Result
Assignee: Nobody
Depends on:
Reported: 2016-02-14 09:49 UTC by Benjamin Chretien
Modified: 2019-12-04 15:26 UTC (History)
3 users (show)

Repro code (885 bytes, text/x-c++src)
2016-02-14 09:49 UTC, Benjamin Chretien
no flags Details

Description Benjamin Chretien 2016-02-14 09:49:30 UTC
Created attachment 653 [details]
Repro code

While investigating an error in our code relying on Eigen, I noticed the following behavior. Given a MatrixXd a, the result of this operation on a block b of a MatrixXd m is wrong:

    b.noalias() = 2. * x.transpose() * a;

when noalias() is used and x is a VectorXd. As a result, the block b of the matrix contains the wrong data (misplaced in memory). However, if x is a MatrixXd with the proper size, things work normally. I attached a repro code that shows the issue. I tested in on Eigen 3.2.7 and 3.3-beta1.

    Eigen 3.2.92
    Using MatrixXd:
    With noalias():
     0  0
    30 44

    Without noalias():
     0  0
    30 44

    Using VectorXd:
    With noalias():
     0 44
    30  0

    Without noalias():
     0  0
    30 44

Am I doing something wrong here?
Comment 1 Gael Guennebaud 2016-02-14 22:02:14 UTC
I confirm. The problem is when extracting the inner-stride of the destination using:


which is not necessarily correct when the destination expression is not a vector expression at compile-time, as with m.block(1, 0, 1, 2). This works fine with m.row(1), which is the workaround you should follow.

On Eigen's side, a quick fix would be enforce the destination to be a vector by calling:


This should not produce any runtime overhead.
Comment 2 Benjamin Chretien 2016-02-15 01:02:22 UTC
Duly noted, thanks for the quick answer!
Comment 3 Gael Guennebaud 2016-02-15 20:46:14 UTC (3.2)
Summary:     Bug 1166: fix shortcomming in gemv when the destination is not a vector at compile-time.

btw, thanks for find that one.
Comment 4 Benjamin Chretien 2016-02-19 01:41:43 UTC
Well thanks for the quick fix (and maintenance release), it's greatly appreciated!
Comment 5 Nobody 2019-12-04 15:26:10 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:

Note You need to log in before you can comment on or make changes to this bug.