Re: [eigen] Problem with GCC<4.5+amd64+vectorization (Was: On lazy evaluation and temporary matrices)

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Nope, it's for a good amd64 linux gcc ;-)
Thanks for the link for GCC bug reports... if I find time I'll try
once more to isolate a test case.

And don't worry for the delay... as long as the patch makes it before
3.0 I'll be happy!

JL

On Wed, Jan 12, 2011 at 2:59 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Oh by the way --- is this GCC on Windows?
>
> GCC/Windows sure had stack alignment problems that were solved in GCC 4.5:
> http://gcc.gnu.org/gcc-4.5/changes.html
>
> We even have a dox page about them, linked from the unaligned arrays
> assert page:
> http://eigen.tuxfamily.org/dox-devel/TopicWrongStackAlignment.html
>
> Benoit
>
> 2011/1/12 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> Have you made a GCC bug report about this?
>>
>> http://gcc.gnu.org/bugs/#need
>>
>> If you follow these instructions (produce .ii selfcontained
>> preprocessed test case, probably compress it as it's going to be
>> large) they should be able to fix it.
>>
>> Of course this only works if you can produce a small test case...
>>
>> Benoit
>>
>> 2011/1/10 Jose Luis Blanco <joseluisblancoc@xxxxxxxxx>:
>>> I don't think many would find this problem, but after two month I
>>> finally fixed this issue and wanted to leave here a (dirty) solution
>>> for the joy of future readers of the list archive ;-)
>>>
>>> It turned out that just for one specific part of my code, an Eigen
>>> matrix wasn't computed OK. This only happened with GCC older than 4.5
>>> and for the amd64 architecture. In all other cases, everthing works
>>> nicely. Since valgrind doesn't complain of anything, I wasn't able to
>>> generate an isolated test case and the code actually works for all
>>> other situations, I'm forced to think it may be some intrincated bug
>>> in GCC 4.4 (?).
>>>
>>> My solution has been to:
>>>
>>> 1) Disable vectorization for GCC <4.5 with EIGEN_DONT_VECTORIZE
>>> (thanks Gael!) in the file with the problematic code, and
>>> 2) move to GCC 4.5 !!
>>>
>>> JL
>>>
>>> On Thu, Nov 25, 2010 at 8:25 AM, Gael Guennebaud
>>> <gael.guennebaud@xxxxxxxxx> wrote:
>>>> Hi,
>>>>
>>>> first make sure to test it in "debug mode", i.e., without NDEBUG or
>>>> EIGEN_DEBUG defined to enable the detection of some some alignment
>>>> issues. If that does not help, try to disable vectorization by
>>>> defining EIGEN_DONT_VECTORIZE.
>>>>
>>>> Is your code multithreaded?
>>>>
>>>> Also in your case the .eval() is superfluous.
>>>>
>>>> gael
>>>>
>>>> On Thu, Nov 25, 2010 at 2:45 AM, Jose Luis Blanco
>>>> <joseluisblancoc@xxxxxxxxx> wrote:
>>>>> Hi Thomas,
>>>>>
>>>>> Thanks, I added the EIGEN_ALIGN16 macro to all the number arrays, it
>>>>> definitively makes sense... but it behaves exactly the same :-(
>>>>>
>>>>> Best,
>>>>> JL
>>>>>
>>>>> PS: And yes, it's beta3*, actually an hg checkout from a few days ago...
>>>>>
>>>>> On Thu, Nov 25, 2010 at 2:22 AM, Thomas Capricelli
>>>>> <orzel@xxxxxxxxxxxxxxx> wrote:
>>>>>> It looks like an alignement problem. You should ensure "numbers" is aligned,
>>>>>> see bottom of http://eigen.tuxfamily.org/dox-devel/
>>>>>>
>>>>>> (I assume you use the devel branch.. 3.0beta*)
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>
>>>>>>
>>>>>> http://www.freehackers.org/thomas
>>>>>>
>>>>>> On Thursday 25 November 2010 02:01:48 Jose Luis Blanco wrote:
>>>>>>
>>>>>>> Hi guys,
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> I need the help of someone knowing the inner workings of Eigen. I've
>>>>>>
>>>>>>> spent a few days stuck debugging an error in some silly computations
>>>>>>
>>>>>>> with Eigen matrices, and want to rule out potential errors...
>>>>>>
>>>>>>> Consider this code:
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> ======================
>>>>>>
>>>>>>> void func( Matrix<...> &m_out )
>>>>>>
>>>>>>> {
>>>>>>
>>>>>>> Matrix<...> I = ....
>>>>>>
>>>>>>> const double numbers[] = { 1.0, x(), -y()*x() , whatever, .... };
>>>>>>
>>>>>>> m_out = I * Matrix<...>(numbers);
>>>>>>
>>>>>>> }
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> int main()
>>>>>>
>>>>>>> {
>>>>>>
>>>>>>> Matrix<...> M;
>>>>>>
>>>>>>> func(M);
>>>>>>
>>>>>>> cout << M << endl;
>>>>>>
>>>>>>> }
>>>>>>
>>>>>>> ======================
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> Is it a problem for the temporary object "Matrix<...>(numbers)" to be
>>>>>>
>>>>>>> created with a pointer to memory on the stack, while the evaluation of
>>>>>>
>>>>>>> the object for the matrix product is actually evaluated *out* of that
>>>>>>
>>>>>>> function (where obviously that pointer is invalid)??
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> I ask because I'm having a very erratic behavior in code like above
>>>>>>
>>>>>>> (on GCC doesn't work, it does on MSVC; adding a "cout << ..." for an
>>>>>>
>>>>>>> unrelated matrix changes the result, etc...).
>>>>>>
>>>>>>> Is it necessary to use instead:
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> ( I * Matrix<...>(numbers) ).eval();
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> or not even with this .eval() is my code correct?
>>>>>>
>>>>>>> I'm still having random wrong matrix elements with and without eval(),
>>>>>>
>>>>>>> so I wanted to be sure on this part before keep on debugging...
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> Thanks for your time!
>>>>>>
>>>>>>> JL
>>>>>>
>>>
>>>
>>>
>>
>
>



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/