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

[Rohit Garg <rpg.314@xxxxxxxxx>]

On Tue, Feb 2, 2010 at 11:36 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 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.

I assume this behavior is allowed by spec. However, does the C++ spec
*require* that it be allowed by conforming compilers? It will be
interesting to know what C++ experts think on this issue.

If this is not required by spec, then it will make Eigen a special
case hack that just happens to run on gcc, icc and msvc. In such a
situation, asking for XLC to be fixed is no good.

XLC devs will probably not bother with implementing such changes
unless C++ spec requires it.


>
> 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
>>
>>
>>
>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay