Re: [eigen] can't reproduce gcc 4.3.4 errors |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] can't reproduce gcc 4.3.4 errors
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 29 Jun 2010 08:57:56 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=s7Y72XHcup5EnXhaCKPvIP8BQctjM0lY56nxKlIm2fM=; b=ITUg/DvL2bNUO8Ax5CaSwTXmIHMuelhqdy6672ixAueuwYjMQDwBwGAmP2vVJ7NeoA xIB7+Ljer4pF9BScxVaFxP+QdTHki8LcO9+TCLj3moINZX18JhM81GHYA8Vygc7Dexk5 Pnrt6C6twR0TXeEqpQnbPlZLgX3nOmPCAR68g=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Vc7dedgUuSgg2j1JDB5VqZ4lJQkmqyqh51kIpoe2g0XSguFCHLC1WhS2EPzjol6M3p dEX+FWIgMwVOs6KNCw1a//IKdqUbBkdtUt+en7YbbJk4vlV25GF6g64e8zjo6vaJfF7I fy1jJAq+DLBYmBNSx1vKursF/KxnCfJQsRH+Q=
2010/6/29 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2010/6/29 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> 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.
>
> I really can't reproduce your errors, tried your test program with -O2
> in valgrind, nothing.
>
> But can you try this: replace this line:
>
>> EIGEN_STRONG_INLINE X(const X&) {}
>
> by
>
> EIGEN_STRONG_INLINE X(const X&)
> {
> *reinterpret_cast<char*>(this) = *reinterpret_cast<const char*>(&X);
> }
>
> this assumes that sizeof(X)==1, of course.
Argh. This is going to be even worse in other cases, I guess, with the EBCO..
It looks like EBCO + strict aliasing are an explosive cocktail! All I
could recommend is mention this empty class and EBCO stuff to GCC devs
to see if it rings a bell...
Benoit
>
> Benoit
>
>>
>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>