As a part of another code that uses Eigen (MTKPP) that I am trying to compile, I ran in to n issue with Eigen code.

Here is some relevant information.
GNU: gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)
IBM: IBM XL C/C++ for Linux, V11.1 (5724-X14), Version: 11.01.0000.0002

OS: RHEL 6.0 on IBM POWER 7

I tried with IBM XL compilers and ran in the same issues that were discussed here:
http://www.lbmethod.org/forum/read.php?4,3080
And
http://listengine.tuxfamily.org/lists.t ... 00180.html
http://listengine.tuxfamily.org/lists.t ... 00289.html

So I abandoned efforts with XL for now.

I tried with GNU and ran in to this message only when I use "-mcpu=power7" flag. The flag triggers generation of SIMD (Altivec) code.


libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I/home/user/amber11/AmberTools/src/boost-1.38.0/ -I./.. -I../../src/eigen3b2 -O3 -mtune=power7 -mcpu=power7 -DNDEBUG -DUSE_TINYXML -DTIXML_USE_STL -DC99_OK -O2 -fPIC -DHAVE_ZLIB -DHAVE_ZLIB -MT sheet.lo -MD -MP -MF .deps/sheet.Tpo -c sheet.cpp -o sheet.o
In file included from ../../src/eigen3b2/Eigen/Core:249,
from ../../src/eigen3b2/Eigen/Dense:1,
from table.h:47,
from sheet.h:46,
from sheet.cpp:33:
../../src/eigen3b2/Eigen/src/Core/arch/AltiVec/Complex.h: In function 'Packet Eigen::ei_pset1(const typename Eigen::ei_unpacket_traits<Packet>::type&) [with Packet = Eigen::Packet2cf]':
../../src/eigen3b2/Eigen/src/Core/arch/AltiVec/Complex.h:71: error: no matching function for call to 'ei_pload(const float*)'
../../src/eigen3b2/Eigen/src/Core/arch/AltiVec/Complex.h:74: error: no matching function for call to 'ei_ploadu(const float*)'
../../src/eigen3b2/Eigen/src/Core/arch/AltiVec/Complex.h: At global scope:
../../src/eigen3b2/Eigen/src/Core/arch/AltiVec/Complex.h:109: error: template-id 'ei_pload<std::complex<float> >' for 'Eigen::Packet2cf Eigen::ei_pload(const std::complex<float>*)' does not match any template declaration
../../src/eigen3b2/Eigen/src/Core/arch/AltiVec/Complex.h:110: error: template-id 'ei_ploadu<std::complex<float> >' for 'Eigen::Packet2cf Eigen::ei_ploadu(const std::complex<float>*)' does not match any template declaration
../../src/eigen3b2/Eigen/src/Core/arch/AltiVec/Complex.h: In function 'typename Eigen::ei_unpacket_traits<T>::type Eigen::ei_predux(const Packet&) [with Packet = Eigen::Packet2cf]':
../../src/eigen3b2/Eigen/src/Core/arch/AltiVec/Complex.h:137: error: 'sum' was not declared in this scope
make[3]: *** [sheet.lo] Error 1

I looked through the code in Complex.h and Core. Looks like Packetmath.h under Arch/AltiVec is being included. AFAIK, the definitions for ei_pload are in Packetmath.h.

I havent yet investigated the missing declaration for 'sum'

Of course, when dont use "-mcpu=power7", compiles fine without the Altivec include files.

Any help is sincerely appreciated.

Thank you,
K

I see you are using an old version of Eigen3 (beta2 ?). Could you try with the release version that contains fixes for AltiVec.

Yes, trying with the latest code did not cause any problems and code succeeded compilation with altivec code included. Thank you. If you notice the '3b2' in the text below, its because created a symbolic link to avoid modifying all my scripts for now.

However, still fails with XL compilers. XL compilers have problems with templates the way they are used in the code.

I am documenting here for informational purposes and dont really expect a response.

libtool: compile: xlC -DHAVE_CONFIG_H -I. -I../.. -I/home/user/amber11/AmberTools/src/boost-1.38.0/ -I./.. -I../../src/eigen3b2 -O3 -qarch=pwr7 -qtune=pwr7 -qsimd=auto -DNDEBUG -DUSE_TINYXML -DTIXML_USE_STL -DC99_OK -O2 -fPIC -DHAVE_ZLIB -DHAVE_ZLIB -c sheet.cpp -o sheet.o
/opt/ibmcmp/vacpp/11.1/bin/.orig/xlC: 1501-216 (W) command option -fPIC is not recognized - passed to ld
"../../src/eigen3b2/Eigen/src/Core/SelfAdjointView.h", line 161.79: 1540-0716 (S) The template argument "Eigen::SelfAdjointView" does not match the template parameter "class T".
"../../src/eigen3b2/Eigen/src/Core/SelfAdjointView.h", line 148.110: 1540-0716 (S) The template argument "Eigen::SelfAdjointView" does not match the template parameter "class T".
"../../src/eigen3b2/Eigen/src/Core/Diagonal.h", line 213.1: 1540-0224 (S) The type name "Index" is used where a variable or function name is expected.
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "diagonal".
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "dot".
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "lazyProduct".
"../../src/eigen3b2/Eigen/src/Core/PlainObjectBase.h", line 52.67: 1540-0700 (I) The previous message was produced while processing "lazyAssign".
"../../src/eigen3b2/Eigen/src/Core/PlainObjectBase.h", line 52.67: 1540-0700 (I) The previous message was produced while processing "class Eigen::MatrixBase<Eigen::Matrix<double,-1,-1,0,-1,-1> >".
"../../src/eigen3b2/Eigen/src/Core/Diagonal.h", line 213.1: 1540-0224 (S) The type name "Index" is used where a variable or function name is expected.
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "diagonal".
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "dot".
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "lazyProduct".
"../../src/eigen3b2/Eigen/src/Core/PlainObjectBase.h", line 52.67: 1540-0700 (I) The previous message was produced while processing "lazyAssign".
"../../src/eigen3b2/Eigen/src/Core/PlainObjectBase.h", line 52.67: 1540-0700 (I) The previous message was produced while processing "class Eigen::MatrixBase<Eigen::Matrix<int,-1,-1,0,-1,-1> >".
"../../src/eigen3b2/Eigen/src/Core/Diagonal.h", line 213.1: 1540-0224 (S) The type name "Index" is used where a variable or function name is expected.
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "diagonal".
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "dot".
"../../src/eigen3b2/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "lazyProduct".
"../../src/eigen3b2/Eigen/src/Core/PlainObjectBase.h", line 52.67: 1540-0700 (I) The previous message was produced while processing "lazyAssign".
"../../src/eigen3b2/Eigen/src/Core/PlainObjectBase.h", line 52.67: 1540-0700 (I) The previous message was produced while processing "class Eigen::MatrixBase<Eigen::Matrix<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,-1,-1,0,-1,-1> >".
make[3]: *** [sheet.lo] Error 1

yes, IBM XL compiler is known not to be ready yet to compile Eigen though some progresses have been made from their side.

Hi! I recently added wrappers in our program in order use EIGEN and substitute LAPACK. I am very grateful with you, EIGEN3 is a great program,


Lets pass to the main point:

ggael wrote:yes, IBM XL compiler is known not to be ready yet to compile Eigen though some progresses have been made from their side.

Do you have a PMR number (a bug report to IBM)?

I would like to know more about EIGEN+XL IBM. Probably we can help and save some effort within it.

Thanks!

yes Aron reported many issues, and many of them have been fixed. The next version (if not already out) should contain many fixes and be able to compile Eigen.

Let me expand on caguamo inquiry.

The version of the XLC++ compiler on Blue Gene series is version 9.0 while the rest of the world (e.g. POWER7) is on version 11.1. PMRs are filed against specific version of the compiler. So if Aron's PMR was filed against version 11.1, it will not be backed ported to version 9.0 for Blue Gene. That's just the way things work. I suspect that the PMR was filed against version 11.1 of the compiler, can someone please clarify this?

If the PMR was filed against 11.1, can we get the simple test case Aron used to file his PMR so we can submit another PMR for version 9.0 of the compiler. This would save us the time of constructing the simple example. If the PMR was filed against 9.0, then we would like to know if it was fixed in the April 2011 PTF or later?

Thanks,
Nick Romero
Argonne Leadership Computing Facility

yes, Aron is a Blue Gene user, so he reported for the 9.0 version.

If that can help, here is the PMR: 02135,999,832 and quoting an IBM guy:

In terms of availability of these fixes in XL for BG/P, V9.0 compiler - we expect to ship the PTF that will contain all of them before end of April 2011.

the last version should contains fixes.

I just tried the April 2011 PTF and there still seems to be issues:

"/home/naromero/eigen/Eigen/src/Core/Diagonal.h", line 224.1: 1540-0224 (S) The type name "Index" is used where a variable or function name is expected.
"/home/naromero/eigen/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "diagonal".
"/home/naromero/eigen/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "dot".
"/home/naromero/eigen/Eigen/src/Core/MatrixBase.h", line 61.34: 1540-0700 (I) The previous message was produced while processing "lazyProduct".
"/home/naromero/eigen/Eigen/src/Core/PlainObjectBase.h", line 52.67: 1540-0700 (I) The previous message was produced while processing "lazyAssign".
"/home/naromero/eigen/Eigen/src/Core/PlainObjectBase.h", line 52.67: 1540-0700 (I) The previous message was produced while processing "class Eigen::MatrixBase<Eigen::Matrix<double,1,1,0,1,1> >".

This is using the SVN version of Eigen and here is my test code:
#include <iostream>
#include <Eigen/Dense>

using namespace std;
using namespace Eigen;

int main()
{
Eigen::Matrix<double, 1,1> g;
}

yes, they only fixed issues from side triggered by Eigen2. Maybe there are issues from our side too and/or Eigen3 triggers new issues from their side.

Regarding your specific issue, it is really strange because in this context Index is template integer parameter, not a typename !!! So could help us fixing it by trying to rename Index to Id lines 222 and 223 (file Eigen/src/Core/Diagonal.h). If that stupid change works, you will probably have to do the same lines 231/232. The thing is that MatrixBase defines a type Index.

ggael,

the changes that you suggested made the compilation successful. Nevertheless, more errors and warnings show up when I call other Eigen functionalities.

for instance:

#include <iostream>
#include <Eigen/Dense>

using namespace std;
using namespace Eigen;

int main()
{
MatrixXf g = MatrixXf::Random(3,3);
}

The error

"/home/avazquez/soft/algebra/eigen/eigenXL/include/eigen3/Eigen/src/Core/CwiseNullaryOp.h", line 62.24: 1540-0198 (W) The omitted keyword "private" is assumed for base class "internal::no_assignment_operator".
"/home/avazquez/soft/algebra/eigen/eigenXL/include/eigen3/Eigen/src/Core/CwiseNullaryOp.h", line 62.24: 1540-0198 (W) The omitted keyword "private" is assumed for base class "internal::no_assignment_operator".

Best wishes,

hi, those are warnings, do you only get warnings?

For this example: yes, there are only warnings, and I got a binary,

nevertheless, in the case of calling an eigensolver or a decomposition routine there are many errors and warnings

If it is helpful, I can be punctual posting all of them (with certain order, obviously)

yes please, the best is to post them on our bug tracker:

http://eigen.tuxfamily.org/bz/

A PMR has been submitted (10351 122 000).

The bug is a name lookup bug: Whenever a templated member of a templated class is defined outside the class, template parameters in that definition are not looked up properly if their names shadow names in enclosing namespaces.

In plain English, it means, for example, that in this segment:

Code: Select all

template<typename Scalar>                                               
template<int Dim>                                                       
inline Transform<Scalar,Dim,Affine>                                     
UniformScaling<Scalar>::operator* (const Translation<Scalar,Dim>& t)   
const                                                                   
{                                                                       
  return Transform<Scalar,Dim,Affine>();                               
}                                                                       


... the fact that Scalar shadows another symbol named Scalar in an enclosing (parent) namespace, makes the compiler not look up Scalar correctly when processing the definition of UniformScaling<T>::operator*. A spurious error occurs, and the error message itself references another outside symbol named _Scalar, which seems to indicate that symbol table entries are getting crossed up.

The nice thing is that there's a trivial workaround: Rename the template parameters to something different, so that they don't shadow the names of other symbols. Renaming Scalar to Scalar2 above, for example, makes the error go away.