Re: [eigen] InnerPanel change mis-detects alignment? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] InnerPanel change mis-detects alignment?
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Sat, 7 Aug 2010 23:36:31 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=4TfKcGPbHYiTJL0iqcvlumdoMNBpv9YBXnunlYSWv7I=; b=P+4bWgwHNZkWDOMM4vJL0zvHbC3yRJtt27mHcnwRkJ5jYC3E0kdZ6g5eNvFWv4mcpX dGi2GEyvGW8dUxwmyMJYwK1HL16Vm+bu/Du3eD7lM61RBlPUySAZLNA5qjXsaku9QLk3 xBAXHg4GdJ/L6FQZbzxJsDuFkn9ATAk4Ec5RE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=NWEuacg4GFReCa8NBY3MN3x9Kna7CU7Enpa1RjwSyj532votTfPjkYUzO0aPq1z6sM u3+3WevYf7jfFPosRSALxqYGFOZon33HgKJhpqAqZQmRFKC/gi2cnmEcSkkhwYFniFvH 0EqGG0QnhIWGueOma5uKonPGBakaKknScy7lo=
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
>
>
>