Re: [eigen] beta1 tagged (NOT RELEASED), first try

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/6/30 Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>:
>
> In data mercoledì 30 giugno 2010 16:29:00, Benoit Jacob ha scritto:
>> Please give this a good testing. Beta1 will only be released once it's
>> received enough testing.
>
> Here are my first results, starting from the worse
>
> ** clang: does not compile at all, but i have an idea why, will send another mail related to this. Of course, this is far from being the most important test. Meanwhile, if you happen to know what this means... i dont! :
> ------------------------------------------------------------------------
> In file included from /home/orzel/hg/eigen/unsupported/test/polynomialsolver.cpp:25:
> In file included from /home/orzel/hg/eigen/unsupported/test/../../test/main.h:162:
> In file included from /home/orzel/hg/eigen/Eigen/QR:4:
> In file included from /home/orzel/hg/eigen/unsupported/test/../../Eigen/Core:222:
> /home/orzel/hg/eigen/unsupported/test/../../Eigen/src/Core/arch/SSE/PacketMath.h:291:30: warning: compound literals are a C99-specific feature
>  vecs[1] = _mm_castsi128_ps(_mm_shuffle_epi32(_mm_castps_si128(vecs[0]), 0x55));
>
> (with an arrow pointing to the the first underscore of _mm_castps_si128)
> ------------------------------------------------------------------------
>
> Another important warning is that in GeneralMatrixMatrix.h, ei_gemm_blocking_space is sometimes a class, sometimes a struct. I dont know on which one we should settle (probably 'class'?)
>
>
> ** icc: compile fails with http://freehackers.pastebin.com/GCeBKbEn , not sure what to do..

Thanks a lot for the report,

>
> ** gcc 3.3.6:

I was going to write about this: do we really want to support GCC 3.3
in eigen3? As far as I know, it's never been tested. While it is
supported in eigen2, I think that for eigen3, supporting GCC 3.4
should be enough. I guess that people might have policies of
supporting GCC 3.3 (used to be the case with KDE, not sure if that's
still the case) but I would like to hear about technical reasons, not
policies.

Benoit

> i have some warnings like this:
> ------------------------------------------------------------------------
> /home/orzel/hg/eigen/Eigen/src/Core/Product.h:235: warning: `static' is not at
>   beginning of declaration
> /home/orzel/hg/eigen/Eigen/src/Core/Product.h:247: warning: `static' is not at
>   beginning of declaration
> ------------------------------------------------------------------------
>
> They dissapear if i apply this, but i'm not confident enough to commit. This patch does not seem to prevent compilation with other compilers
> ------------------------------------------------------------------------
> --- a/Eigen/src/Core/Product.h
> +++ b/Eigen/src/Core/Product.h
> @@ -232,7 +232,7 @@
>
>  template<> struct ei_outer_product_selector<ColMajor> {
>   template<typename ProductType, typename Dest>
> -  EIGEN_DONT_INLINE static void run(const ProductType& prod, Dest& dest, typename ProductType::Scalar alpha) {
> +  static EIGEN_DONT_INLINE void run(const ProductType& prod, Dest& dest, typename ProductType::Scalar alpha) {
>     typedef typename Dest::Index Index;
>     // FIXME make sure lhs is sequentially stored
>     // FIXME not very good if rhs is real and lhs complex while alpha is real too
> @@ -244,7 +244,7 @@
>
>  template<> struct ei_outer_product_selector<RowMajor> {
>   template<typename ProductType, typename Dest>
> -  EIGEN_DONT_INLINE static void run(const ProductType& prod, Dest& dest, typename ProductType::Scalar alpha) {
> +  static EIGEN_DONT_INLINE void run(const ProductType& prod, Dest& dest, typename ProductType::Scalar alpha) {
>     typedef typename Dest::Index Index;
>     // FIXME make sure rhs is sequentially stored
>     // FIXME not very good if lhs is real and rhs complex while alpha is real too
>
> ------------------------------------------------------------------------
>
> then, still with gcc 3.3.6, compilation fails anyway with http://freehackers.pastebin.com/mRarbwcp
>
> ** gcc 4.1.2 : tests 451() and 452() fail
> everything's fine ! :-)
>
> ------------------------------------------------------------------------
>
> ** gcc 4.5 : everything's fine ! :-)
>
> Thomas
> --
> Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>
> http://www.freehackers.org/thomas
>
>
>
>