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

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

2010/2/2 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.

Really? I was assuming that once stuff has been forward-declared, you
can use it before it's been defined. I was assuming that that applied
to template specializations too.

Moreover the XLC devs already have an open bug report about this, see
Alexandre's mail...

Benoit

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