Re: [eigen] can't reproduce gcc 4.3.4 errors

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


2010/6/29 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> More news:
>
> in util/XprHelper.h we have:
>
> // just a workaround because GCC seems to not really like empty structs
> #ifdef __GNUG__
>  #define EIGEN_EMPTY_STRUCT_CTOR(X) \
>    EIGEN_STRONG_INLINE X() {} \
>    EIGEN_STRONG_INLINE X(const X&) {}
> #else
>  #define EIGEN_EMPTY_STRUCT_CTOR(X)
> #endif
>
> and all our empty functors are declared with it:
>
> template<typename Scalar> struct ei_scalar_opposite_op {
>  EIGEN_EMPTY_STRUCT_CTOR(ei_scalar_opposite_op)
>  ...
> };
>
> If I remove this trick, i.e., by defining EIGEN_EMPTY_STRUCT_CTOR(X)
> to nothing, then I get only 2 errors (with -O2):
>
> guenneba@devel10:~/eigen/build/test> ./adjoint_1
> Initializing random number generator with seed 1277814460
> Repeating each test 10 times
> Test adjoint(Matrix<float, 1, 1>()) failed in
> "/home/guenneba/eigen/test/adjoint.cpp" (71)
>    ei_isApprox((s1 * v1 + s2 * v2).dot(v3), ei_conj(s1) * v1.dot(v3)
> + ei_conj(s2) * v2.dot(v3), largerEps)
>
> guenneba@devel10:~/eigen/build/test> ./eigensolver_complex_3
> Initializing random number generator with seed 1277814463
> Repeating each test 10 times
> Test eigensolver(Matrix<std::complex<float>, 1, 1>()) failed in
> "/home/guenneba/eigen/test/eigensolver_complex.cpp" (87)
>    test_ei_isApprox(id.operatorNorm(), RealScalar(1))
>
> I don't remember exactly why I've introduced this trick, probably
> because I found GCC produced poor code without it.

Yes, that was the reason.

> This is still very
> strange.

Perhaps G++ devs will be able to make sense of that.

I have a question. In this line:

>    EIGEN_STRONG_INLINE X(const X&) {}

you are basically telling the compiler that the empty struct X in
question has a copy constructor doing nothing. But at the same time,
empty structs have nonzero sizeof() (typically sizeof==1, but check
it). So if this empty struct (which is never exactly empty) aliases
other data, which it totally does if the EBCO (empty base class
optimization) happened, then boom! That could explain it.

Benoit

>
> Marking these empty constructors with EIGEN_DONT_INLINE also fix the errors.
>
>
> Here is the short program I used to debug this:
>
> #include <Eigen/Core>
>
> typedef std::complex<float> T;
> template <typename A> T foo(const A& a) { return (-a-a)(2); }
>
> int main()
> {
>  Eigen::Matrix<T,3,1> n1(0,0,0);
>  return int(Eigen::ei_real(foo(n1)));
> }
>
> (You need to run it under valgrind to see the issue)
>
> if foo is marked with EIGEN_DONT_INLINE, then no error
> if I manually inline foo, s/foo(n1)/(-n1-n1)(2), then no error
> if I do only a+a or -a, then no error
> if I output (-a-a)(2) at the beginning of foo, then the error still
> occurs after the output.
>
>
> gael
>
> On Tue, Jun 29, 2010 at 1:14 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> anyway, it sounds like either Eigen or some of its unit tests are
>> unsafe wrt strict aliasing!!
>>
>> If it's Eigen itself, we have no choice but to fix that, since strict
>> aliasing is part of -O2 in gcc...
>>
>> Benoit
>>
>> 2010/6/29 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>>> hehe, this sounds like the problem that Sune had the other day on IRC. CC'ing.
>>>
>>> Benoit
>>>
>>> 2010/6/29 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>>>> hm,
>>>>
>>>> -O2 -fno-strict-aliasing (and removing the hardcoded -fstrict-aliasing
>>>> from our cmakefile)
>>>>
>>>> 100% tests passed, 0 tests failed out of 453
>>>>
>>>> much better.
>>>>
>>>> gael
>>>>
>>>> On Tue, Jun 29, 2010 at 10:55 AM, Gael Guennebaud
>>>> <gael.guennebaud@xxxxxxxxx> wrote:
>>>>> ok here,  with -O2 -fno-guess-branch-probability, 4 tests fail as follow:
>>>>>
>>>>> guenneba@devel10:~/eigen/build/test> ./array_2
>>>>> Initializing random number generator with seed 1277801661
>>>>> Repeating each test 10 times
>>>>> Test comparisons(Array22f()) failed in
>>>>> "/home/guenneba/eigen/test/array.cpp" (136)
>>>>>    test_ei_isApprox(((m1.abs()+1)>RealScalar(0.1)).colwise().count(),
>>>>> ArrayOfIndices::Constant(cols,rows).transpose())
>>>>>
>>>>> guenneba@devel10:~/eigen/build/test> ./array_3
>>>>> Initializing random number generator with seed 1277801662
>>>>> Repeating each test 10 times
>>>>>
>>>>>    actual   = 2.66729
>>>>>    expected = 2.53391
>>>>>
>>>>>
>>>>>    actual   = 1.17816
>>>>>    expected = 1.93492
>>>>>
>>>>>
>>>>>    actual   = -2.79358
>>>>>    expected = -0.758141
>>>>>
>>>>>
>>>>>    actual   = -2.06046
>>>>>    expected = -2.54951
>>>>>
>>>>>
>>>>>    actual   = -1.27569
>>>>>    expected = 0.919771
>>>>>
>>>>>
>>>>>    actual   = 5.67633
>>>>>    expected = 4.85775
>>>>>
>>>>>
>>>>>    actual   = -5.2517
>>>>>    expected = -3.85892
>>>>>
>>>>>
>>>>>    actual   = -1.33353
>>>>>    expected = -0.700732
>>>>>
>>>>>
>>>>>    actual   = -3.33972
>>>>>    expected = 0.721723
>>>>>
>>>>>
>>>>>    actual   = -1.61675
>>>>>    expected = 0.256261
>>>>>
>>>>> Segmentation fault
>>>>>
>>>>> guenneba@devel10:~/eigen/build/test> ./geo_hyperplane_4
>>>>> Initializing random number generator with seed 1277801668
>>>>> Repeating each test 10 times
>>>>> Segmentation fault
>>>>>
>>>>> guenneba@devel10:~/eigen/build/test> ./geo_parametrizedline_4
>>>>> Initializing random number generator with seed 1277801673
>>>>> Repeating each test 10 times
>>>>> Segmentation fault
>>>>>
>>>>>
>>>>> gael
>>>>>
>>>>> On Tue, Jun 29, 2010 at 10:29 AM, Hauke Heibel
>>>>> <hauke.heibel@xxxxxxxxxxxxxx> wrote:
>>>>>> Ok, I can try to run the complete tests too. Here are also the flags I
>>>>>> used to run (so far just a few of) the failing tests.
>>>>>>
>>>>>> CXX:               /usr/bin/c++-4.exe
>>>>>> CXX_VERSION:       c++-4 (GCC) 4.3.4 20090804 (release) 1
>>>>>> CXX_FLAGS:          -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef
>>>>>> -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith
>>>>>> -Wwrite-strings -Wformat-s
>>>>>> ecurity -fexceptions -fno-check-new -fno-common -fstrict-aliasing
>>>>>> -Wno-variadic-macros -Wextra -pedantic
>>>>>>
>>>>>> - Hauke
>>>>>>
>>>>>> On Tue, Jun 29, 2010 at 10:25 AM, Gael Guennebaud
>>>>>> <gael.guennebaud@xxxxxxxxx> wrote:
>>>>>>> On Tue, Jun 29, 2010 at 10:14 AM, Hauke Heibel
>>>>>>> <hauke.heibel@xxxxxxxxxxxxxx> wrote:
>>>>>>>> On Mon, Jun 28, 2010 at 11:15 PM, Gael Guennebaud
>>>>>>>> <gael.guennebaud@xxxxxxxxx> wrote:
>>>>>>>>> I believe there is a bug in gcc, here is the related bug report:
>>>>>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42255
>>>>>>>>> but no fix yet.
>>>>>>>>
>>>>>>>> That means we can get rid of the errors by disabling -fprofile-arcs?
>>>>>>>
>>>>>>> A while ago, such errors appeared only with  -fprofile-arcs, i.e.,
>>>>>>> when coverage testing was enabled. But now, even without
>>>>>>> -fprofile-arcs we hit these weird errors. After some investigations, I
>>>>>>> found that disabling the guess-branch-probability optimization that is
>>>>>>> automatically enabled with -O2 solved a couple of errors:
>>>>>>>
>>>>>>> -O2 -fno-guess-branch-probability
>>>>>>>
>>>>>>> Actually, guess-branch-probability and -fprofile-arcs seems to be
>>>>>>> quite related. I've updated the bug report with that respect, but news
>>>>>>> so far.
>>>>>>>
>>>>>>> I'm currently compiling with -O2 -fno-guess-branch-probability to see
>>>>>>> if there remain other errors....
>>>>>>>
>>>>>>>
>>>>>>> gael
>>>>>>>
>>>>>>>> - Hauke
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>



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