Re: [eigen] cwiseop_1 test failure

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

ok, after some times I found that the error does not occur if I
compile with "-O2 -fno-guess-branch-probability" instead of "-O2"
only. Actually this optimization ( -f-guess-branch-probability) seems
to be related to the -fprofile-arcs option which is the object of the
aforementioned bug report. So I'll update it.

gael

On Fri, Jun 11, 2010 at 3:04 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> even better, if you comment all the lines *after* the first test which fails :
>
> VERIFY_IS_APPROX(m4.setConstant(s1), m3);
>
> then no error at all !!!
>
> gael
>
> On Fri, Jun 11, 2010 at 2:57 PM, Gael Guennebaud
> <gael.guennebaud@xxxxxxxxx> wrote:
>> to be honest I really think this is a GCC issue like the one I
>> reported here a couple of months ago:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42255
>>
>> At that time this bug only showed up with when coverage testing was
>> enabled, but it seems to me we are now hitting the same bug with -O2
>> only.
>>
>> Indeed, I rewrote the test_ei_isApprox function like this:
>>
>> EIGEN_DONT_INLINE void foo(bool& x) {x=x;}
>>
>> template<typename Type1, typename Type2>
>> EIGEN_DONT_INLINE bool test_ei_isApprox(const Type1& a, const Type2& b)
>> {
>>  bool ret = a.isApprox(b, test_precision<typename Type1::Scalar>());
>>  foo(ret);
>>  return ret;
>> }
>>
>> and that fixed the issue (both the failure and valgrind's issue).
>>
>> However, if I comment the line foo(ret);, then the issue shows up.
>> Note that here Type1 == Type1 == Matrix<float, 1, 1>. It cannot be
>> more trivial.
>>
>> I even get a segfault at the line return a.isApprox(b); when doing:
>>
>> template<typename Type1, typename Type2>
>> inline bool test_ei_isApprox(const Type1& a, const Type2& b)
>> {
>>  bool ret;
>>  std::cerr << a << " == " << b << " " << (a-b) << " " << (ret =
>> a.isApprox(b)) << "\n";
>>  return a.isApprox(b);
>> }
>>
>> Really strange.
>>
>> gael
>>
>> On Fri, Jun 11, 2010 at 12:41 PM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx> wrote:
>>> Hello,
>>>
>>> I had a quick look at the cwiseop_1 test, which according to the dash board
>>> fails on both Gael's and my computer but only with GCC 4.3.
>>>
>>> I did not get very far and I have other commitments at the moment (and I've
>>> also run out of ideas), but perhaps somebody can continue from here.
>>>
>>> The offending line is
>>>
>>>   VERIFY_IS_APPROX(m4.setConstant(s1), m3);
>>>
>>> Here, m3 and m4 are of type MatrixType = Matrix<1,1,float>, s1 is a random
>>> float, and m3 is set to MatrixType::Constant(1,1,s1).
>>>
>>> I did not manage to get an self-contained test case, though given more time
>>> this should be possible.
>>>
>>> valgrind reports:
>>> Use of uninitialised value of size 4
>>>    at 0x804A35F: bool Eigen::test_ei_isApprox<Eigen::Matrix<float, 1, 1, 0,
>>> 1, 1>, Eigen::Matrix<float, 1, 1, 0, 1, 1> >(Eigen::Matrix<float, 1, 1, 0,
>>> 1, 1> const&, Eigen::Matrix<float, 1, 1, 0, 1, 1> const&) (in .../cwiseop_1)
>>>    by 0x804AE1E: void cwiseops<Eigen::Matrix<float, 1, 1, 0, 1, 1>
>>>>(Eigen::Matrix<float, 1, 1, 0, 1, 1> const&) (in .../cwiseop_1)
>>>    by 0x8049DB9: test_cwiseop() (in .../cwiseop_1)
>>>    by 0x804A0EA: main (in .../cwiseop_1)
>>>
>>> The error persists if I replace
>>>
>>>   VERIFY_IS_APPROX(m4.setConstant(s1), m3);
>>>
>>> by
>>>
>>>   VERIFY(test_ei_isApprox(m4.setConstant(s1), m3));
>>>
>>> However, the error goes away if I replace it by
>>>
>>>   VERIFY(m4.setConstant(s1).isApprox(m3, test_precision<typename
>>> MatrixType::Scalar>()));
>>>
>>> As far as I see, this is just inlining the definition of test_ei_isApprox,
>>> so I don't see why this makes a difference.
>>>
>>>
>>> Jitse
>>>
>>>
>>>
>>>
>>
>