Re: [eigen] XLC Port Part III: XLC failing to instantiate a partial template specialization unless it is defined before use in a forward declaration

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


Interesting!
But indeed, doing this change everywhere that pattern happens, would
probably lead to very intrusive changes in Eigen. Actually, just the
one case that you show here would already be quite an intrusive fix,
if we had to move the specialization to ForwardDeclarations.h. So I
hope that a better solution is possible and/or that XLC is fixed for
this.

Indeed it's no good news that a simple test cases seems difficult to obtain....

Benoit


2010/2/2 Aron Ahmadia <aja2111@xxxxxxxxxxxx>:
> A little more digging has turned up this nifty fact.  If I
> 'forward-define' the partial specialization for ei_traits in
> ForwardDeclarations.h (moving it from Matrix.h):
>
> template<typename _Scalar, int _Rows, int _Cols, int _Options, int
> _MaxRows, int _MaxCols>
> struct ei_traits<Matrix<_Scalar, _Rows, _Cols, _Options, _MaxRows, _MaxCols> >
> {
>  typedef _Scalar Scalar;
>  typedef Dense StorageType;
>  typedef DenseStorageMatrix DenseStorageType;
>  enum {
>    RowsAtCompileTime = _Rows,
>    ColsAtCompileTime = _Cols,
>    MaxRowsAtCompileTime = _MaxRows,
>    MaxColsAtCompileTime = _MaxCols,
>    Flags = ei_compute_matrix_flags<_Scalar, _Rows, _Cols, _Options,
> _MaxRows, _MaxCols>::ret,
>    CoeffReadCost = NumTraits<Scalar>::ReadCost
>  };
> };
>
> Then
>
> template<typename MatrixType, int BlockRows=Dynamic, int BlockCols=Dynamic,
>         int _DirectAccessStatus =
> (ei_traits<MatrixType>::Flags&DirectAccessBit) ? HasDirectAccess :
> NoDirectAccess> class Block;
>
> compiles (at least to instantiate a Matrix3f, make check is still
> failing miserably).  This sort of problem is a real head-scratcher,
> since XLC seems to handle a simple version of this correctly:
>
> #include<iostream>
> #include<vector>
>
> template<typename T> struct A;
>
> template<typename Scalar, typename Allocator, int _bits =
> (A<std::vector<Scalar, Allocator> >::bits > 10) ? 1 : 0> struct B {
>  static const int bits = _bits;
> };
>
> template<typename Scalar, typename Allocator>
> struct A < std::vector <Scalar, Allocator > > {
>  static const int bits = 3;
>  std::vector <Scalar, Allocator> y;
> };
>
> int main()
> {
>  B < int, std::allocator<int> > b1;
>  B < int, std::allocator<int>, 2 > b2;
>  std::cout << "b1 " << b1.bits << std::endl;
>  std::cout << "b2 " << b2.bits << std::endl;
>
>  return 0;
> }
>
> This news is still positive, since we can at least identify what
> exactly is causing a problem (XLC is failing to instantiate a partial
> template specialization unless the specialization has already been
> defined)  I tried forward-declaring the partial template
> specialization, a legal maneuver in XLC, but this didn't fix things.
> It's possible that "MatrixType" is not well-defined to XLC and I am
> missing other forward declarations of partial specializations that
> would fix things.
>
> Alexandre, can you follow up with the IBM Compiler Team and see if
> there are any outstanding issues in the XLC V9.0 that shipped with our
> BlueGene/P last year that would cause this sort of trouble?
>
> Thanks,
> Aron
>
>
>



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