Re: [eigen] XLC Port: Part II - External definition of a template member function of a template class causing the problems?

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

2010/1/30 Aron Ahmadia <aja2111@xxxxxxxxxxxx>:
> Hi Benoit,
>
> I got that code workarounding by inlining the template function member
> definitions into the class definition.  I decided to skip forward and
> see if there were any other big issues that were causing the XLC
> compiler to crash, and ei_traits appears to be another one.  The XLC
> compiler is complaining when it tries to instansiate the ei_traits
> template class using a single template argument (MatrixType) with the
> error that the undefined class is not valid:
>
> "eigen/Eigen/src/Core/util/ForwardDeclarations.h", line 46.30:
> 1540-1109 (S) The use of undefined class
> "Eigen::ei_traits<Eigen::Matrix<float,3,3,0,3,3> >" is not valid.
>
> My suspicion is that ei_traits is not defined in a manner that XLC
> approves of, or that it is bugging out for another reason.  I will
> spend some time investigating this week and try to narrow down exactly
> how and where XLC is breaking.  One possibility is that it can't
> handle a template class instantiation to resolve another template
> argument.  Another possibility is that it can't find a definition of
> ei_traits that it likes.  I think I can eliminate the second
> possibility by trying to explicitly instantiate an ei_traits object
> with the given argument.s
>
> Nevermind, I just tried it.  XLC is okay with this:
> Eigen::ei_traits<Eigen::Matrix<float,3,3,0,3,3> > a;
>
> and compiles, links, and runs it through a main.cpp routine.
> It gives the same errors about ei_traits with these lines of code:
> Eigen::Matrix<float,3,3,0,3,3> m;
> Matrix3f m3;
>
> "eigen/Eigen/src/Core/util/ForwardDeclarations.h", line 44.30:
> 1540-1109 (S) The use of undefined class
> "Eigen::ei_traits<Eigen::Matrix<float,3,3,0,3,3> >" is not valid.
>
> I think this points to your use of ei_traits here:
> template<typename MatrixType, int BlockRows=Dynamic, int BlockCols=Dynamic,
>  int _DirectAccessStatus =
> (ei_traits<MatrixType>::Flags&DirectAccessBit) ? HasDirectAccess :
> NoDirectAccess> class Block;
>
> Some other compiler errors in the code seem to indicate that XLC is
> unable to handle the instantiation of a template class to resolve a
> non-class template argument.

Ah, thanks, I'm starting to understand and this makes sense. I really
hope that it is not the case:

> that XLC is
> unable to handle the instantiation of a template class to resolve a
> non-class template argument.

Because if that is the case, then it is virtually impossible to do any
template metaprogramming with XLC :( At least I can say that we are
doing this at many places and this is a very important device for us,
so if that is what XLC doesn't like, fixing it would involve a very
big set of changes and the resulting Eigen would be far clumsier
(right now I'm not even sure that's possible).

Benoit


>
> Cheers,
> Aron
>
> On Sat, Jan 30, 2010 at 4:56 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 2010/1/27 Aron Ahmadia <aja2111@xxxxxxxxxxxx>:
>>> Hi all,
>>>
>>> I'm still looking at the port, and I've managed to narrow down the
>>> problem.  For those of you who've been following along at home, XLC
>>> has been throwing this error when trying to compile the Eigen files:
>>>                                              [0]
>>> "eigen/Eigen/src/Core/SelfAdjointView.h", line 147.81: 1540-0716 (S)
>>> The template argument "Eigen::SelfAdjointView" does not match the
>>> template parameter "class T".
>>> "eigen/Eigen/src/Core/SelfAdjointView.h", line 134.112: 1540-0716 (S)
>>> The template argument "Eigen::SelfAdjointView" does not match the
>>> template parameter "class T".
>>>
>>> Suspiciously, there's no trace of SelfAdjointView being used as a
>>> template parameter argument anywhere in there, or any trace of a
>>> parameter named 'class T'.
>>>
>>> So I decided to create a new test file, slowly adding in the Eigen
>>> header files from Core until I got compiler errors.  Here's the
>>> current file: http://pastebin.com/m267235e7
>>>
>>> If you'll notice, SelfAdjointView.h is being successfully included
>>> here.  What causes the breakage is SelfadjointProduct.h.  This
>>> actually isn't that surprising, since a function that declared in
>>> SelfAdjointView.h is later defined in SelfadjointProduct.h (By the
>>> way, should this be renamed to SelfAdjointProduct.h to fit the rest of
>>> the naming scheme better?)
>>>
>>> Here is the declaration and the definition:
>>>
>>> template<typename DerivedU>
>>> SelfAdjointView& rankUpdate(const MatrixBase<DerivedU>& u, Scalar alpha)
>>>
>>>
>>> template<typename MatrixType, unsigned int UpLo>
>>> template<typename DerivedU>
>>> SelfAdjointView<MatrixType,UpLo>& SelfAdjointView<MatrixType,UpLo>
>>> ::rankUpdate(const MatrixBase<DerivedU>& u, Scalar alpha)
>>> {
>>>  typedef ei_blas_traits<DerivedU> UBlasTraits;
>>>  typedef typename UBlasTraits::DirectLinearAccessType ActualUType;
>>>  typedef typename ei_cleantype<ActualUType>::type _ActualUType;
>>>  const ActualUType actualU = UBlasTraits::extract(u.derived());
>>>
>>>  Scalar actualAlpha = alpha * UBlasTraits::extractScalarFactor(u.derived());
>>>
>>>  enum { IsRowMajor = (ei_traits<MatrixType>::Flags&RowMajorBit) ? 1 : 0 };
>>>
>>>  ei_selfadjoint_product<Scalar,
>>>    _ActualUType::Flags&RowMajorBit ? RowMajor : ColMajor,
>>>    ei_traits<MatrixType>::Flags&RowMajorBit ? RowMajor : ColMajor,
>>>    !UBlasTraits::NeedToConjugate, UpLo>
>>>    ::run(_expression().cols(), actualU.cols(), &actualU.coeff(0,0),
>>> actualU.stride(),
>>>          const_cast<Scalar*>(_expression().data()),
>>> _expression().stride(), actualAlpha);
>>>
>>>  return *this;
>>> }
>>>
>>> So according to this page here:
>>> http://www.comeaucomputing.com/techtalk/templates
>>>
>>> You're not allowed to do the above because SelfAdjointView is the
>>> 'primary template argument'.  Unfortunately, the code refuses to
>>> compile if the template arguments are removed.
>>
>> I'm sorry, I still don't understand what is not allowed with the code
>> that you pasted here?
>>
>> Benoit
>>
>>
>>
>
>
>