Re: [eigen] InnerPanel change mis-detects alignment?

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi,

again the issue was not in this change but it existed before.

I've simply removed the AlignedBit flag for non vectorizable scalar
types and reapplied this changeset.

cheers,

gael

On Wed, Aug 11, 2010 at 6:14 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Hi,
>
> I have backed out Gael's changeset for now, so we can quietly take our
> time to fix this.
>
> Many thanks to Jitse, and counting on everyone's understanding. The
> bug seemed to occur only on certain platforms, e.g. here on linux
> x86-64 I couldn't reproduce it (and fedora doesn't make it easy to
> build 32bit binaries).
>
> Jitse, I guess this was caught by our unit tests, right? If not,
> please add your test case as a new unit test.
>
> Cheers,
> Benoit
>
> 2010/8/7 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> Hi,
>>
>> sorry for looking at it only right now. Actually the problem is either
>> in the assert:
>>
>> ei_assert(EIGEN_IMPLIES(ei_traits<Derived>::Flags&AlignedBit,
>> (size_t(m_data)&0xf)==0)
>>                 && "data is not aligned");
>>
>> MapBase.h line 193, or in the way the AlignedBit flag is assigned.
>> Indeed, without SSE we have:
>>
>> (Matrix3f::Flags & AlignedBit) == AlignedBit (== 64)
>>
>> because in this case ei_packet_traits<float>::size == 1.
>>
>> Well, maybe there is an issue in both. First, I doubt it makes sense
>> to set the AlignedBit flags for scalar types which are not vectorized,
>> and second the hard coded alignment test ((size_t(m_data)&0xf)==0)) is
>> clearly not satisfactory....
>>
>> gael
>>
>> On Fri, Jul 30, 2010 at 1:23 PM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx> wrote:
>>> Hello,
>>>
>>> Changeset 05aa89b0c8a4 (allow vectorization of mat44.col() by adding a
>>> InnerPanel boolean), committed about a week ago, breaks quite a number of
>>> tests on my computer (32bits linux, gcc 4.3.3). Here is a simple example:
>>>
>>> -------------------
>>> #include <Eigen/Core>
>>> #include <iostream>
>>> using namespace Eigen;
>>> using namespace std;
>>>
>>> int main()
>>> {
>>>  Matrix3f m = Matrix3f::Random();
>>>  cout << "m = \n" << m << "\n";
>>>  cout << "m.data() = " << m.data() << "\n";
>>>  cout << "m.col(0) = \n" << m.col(0) << "\n";
>>>  return 0;
>>> }
>>> -------------------
>>>
>>> When compiled with no flags I get the following output
>>>
>>> -------------------
>>> m =
>>>  0.680375   0.59688 -0.329554
>>> -0.211234  0.823295  0.536459
>>>  0.566198 -0.604897 -0.444451
>>> m.data() = 0xbfe53e38
>>> eigenfoo: /home/amsta/jitse/scratch/eigen-dev/Eigen/src/Core/MapBase.h:193:
>>> void Eigen::MapBase<Derived>::checkSanity() const [with Derived =
>>> Eigen::Block<Eigen::Matrix<float, 3, 3, 0, 3, 3>, 3, 1, true, true>]:
>>> Assertion `(!(ei_traits<Derived>::Flags&AlignedBit) ||
>>> ((size_t(m_data)&0xf)==0)) && "data is not aligned"' failed.
>>> Aborted
>>> -------------------
>>>
>>> It looks like Eigen thinks that m.col(0) is aligned on a 16-byte boundary,
>>> which it is not. The backtrace produced by gdb is
>>>
>>> -------------------
>>> #0  0x00110402 in __kernel_vsyscall ()
>>> #1  0x00551fa0 in raise () from /lib/libc.so.6
>>> #2  0x005538b1 in abort () from /lib/libc.so.6
>>> #3  0x0054b3ce in __assert_fail () from /lib/libc.so.6
>>> #4  0x08049814 in Eigen::MapBase<Eigen::Block<Eigen::Matrix<float, 3, 3, 0,
>>> 3, 3>, 3, 1, true, true> >::checkSanity (this=0xbf9ac120)
>>>    at /home/amsta/jitse/scratch/eigen-dev/Eigen/src/Core/MapBase.h:192
>>> #5  0x080498aa in MapBase (this=0xbf9ac120, data=0xbf9ac0f8, rows=3, cols=1)
>>>    at /home/amsta/jitse/scratch/eigen-dev/Eigen/src/Core/MapBase.h:174
>>> #6  0x080498ff in Block (this=0xbf9ac120, xpr=@0xbf9ac0f8, i=0)
>>>    at /home/amsta/jitse/scratch/eigen-dev/Eigen/src/Core/Block.h:252
>>> #7  0x0804997e in Eigen::DenseBase<Eigen::Matrix<float, 3, 3, 0, 3, 3>
>>>>::col    (this=0xbf9ac0f8, i=0)
>>>    at /home/amsta/jitse/scratch/eigen-dev/Eigen/src/Core/Block.h:944
>>> #8  0x08048cec in main () at eigenfoo.cc:11
>>> -------------------
>>>
>>> This issue disappears when I go back to the revision before changeset
>>> 05aa89b0c8a4. It also disappears when I compile with -msse2.
>>>
>>> I hope this is enough for you to find out what's happening. If not, I can
>>> have a further look.
>>>
>>> Cheers,
>>> Jitse
>>>
>>>
>>>
>>
>>
>>
>
>
>