This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen
Bug 1046 - fixed matrix types do not report correct alignment requirements
Summary: fixed matrix types do not report correct alignment requirements
Status: RESOLVED FIXED
Alias: None
Product: Eigen
Classification: Unclassified
Component: Interoperability (show other bugs)
Version: 3.2
Hardware: All All
: Low Feature Request
Assignee: Nobody
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 3.4
  Show dependency treegraph
 
Reported: 2015-07-27 10:01 UTC by nevion
Modified: 2019-12-04 14:47 UTC (History)
4 users (show)



Attachments
test case showing alingments of fixed types (1.30 KB, text/x-csrc)
2015-07-27 10:01 UTC, nevion
no flags Details

Description nevion 2015-07-27 10:01:32 UTC
Created attachment 594 [details]
test case showing alingments of fixed types

Eigen Fixed types do not report their alignment and thus prohibit integration into most alignment aware code based on std::alignment_of.  A darn shame, really.

Added c++11 test:
c++ -std=c++11 -Ieigen.hg/ eigen_alignment_test.cpp -o eigen_alignment_test
Comment 1 Christoph Hertzberg 2015-07-27 10:46:21 UTC
Please use the existing Bug for further discussion.

Side note: Eigen::Aligned is not a valid flag for Matrix<...,Options> -- you can only use AutoAlign or DontAlign here.

*** This bug has been marked as a duplicate of bug 965 ***
Comment 2 nevion 2015-07-27 11:16:51 UTC
whoops, the AutoAlign and Align get me every time.  Please just regex /Aligned to AutoAlign.

I didn't follow up on the discussion of that bug because while the topic is related, it's purpose was for solving alignment in C++11.

I am NOT against alignas being used in Eigen but given Eigen is fickle about C++11, the attribute is, in the absense of alignas the thing to use so we can have std / boost alignment_of work properly.

Both of these bugs can be solved by using something like BOOST_ALIGNMENT [ config/include/boost/config/suffix.hpp ] as the specifier to always do the best possible thing.

In particular something that uses something like this 

class BOOST_ALIGNMENT(compute_default_alignment<T>::value + 0) Matrix{

};

//gcc compile time constant attribute +0 bug -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55382

re-opening on those grounds, however if you wish to consider it duplicate still, I will abide by that
Comment 3 Gael Guennebaud 2015-07-27 11:22:23 UTC
I don't really see the difference with bug 965, as your suggested fix for this issue, is to use c++11 alignas when available... This is what BOOST_ALIGNMENT does, isn't it?
Comment 4 nevion 2015-07-27 12:23:39 UTC
It uses __attribute__ ((__aligned__(x))) or __declspec(align(x)) when alignas isn't available.  The end expectations are a little different too perhaps.  alignas will be quite different as time goes on but the other 2 are only good in more carefully controlled situations and of course alignment_of.

It's definitely related and is partially solved with alignas but we can provide sizeable utility with the others... if you want to mark that as bug 965, that's ok - but let's get it implemented!
Comment 5 Gael Guennebaud 2015-07-28 16:20:41 UTC
ok, so the idea would be to add an Eigen::alignment_of for Eigen's type. In c++11, Eigen::alignment_of would simply be an alias for std::alignment_of as we would use alignas. This  Eigen::alignment_ aspect is actually related and part of bug 973 that I'm working on.
Comment 6 Gael Guennebaud 2019-02-19 09:36:19 UTC
For the record, Eigen now uses alignas by default when available. I've added unit tests for std::alignment_of:

https://bitbucket.org/eigen/eigen/commits/3e526efbfe341

We're in 2019, let's not bother about a home-made Eigen::alignment_of.
Comment 7 Nobody 2019-12-04 14:47:51 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to gitlab.com'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: https://gitlab.com/libeigen/eigen/issues/1046.

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