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 ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] XLC Port Part III: XLC failing to instantiate a partial template specialization unless it is defined before use in a forward declaration*From*: Rohit Garg <rpg.314@xxxxxxxxx>*Date*: Wed, 3 Feb 2010 00:07:16 +0530*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=n96wHLb2wYs1xZa/cpU8dI7zASJkSE0QFH3WEiFdTiA=; b=f0AxkmXDNzYoTHFwFlGYAfjoS23A4hsuhig42BbQUtHkcz9gO5medXEJJhIWUvmQLh /lwSI1VN09BPpGZOM2tp4lI8VZSFWjpctep2cf+1xWCqVuI2GO95SaVCOLEixAUnFFy7 K1M4OH4t3D36i3PlmgmKolQcczr4SJ1XZWf/o=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=OF8N6InyesPwM9HSJgEOLN9eRA3xQbykiaUyf75tnAkmBMaxSLd37+lKdChUXNK8hm WoAf5G5reGkdtcxVWZNDo3DyC9bKuSfbJuZnkefLga+6+gffbUJoXk1YR0rIKoJ5y8S9 8BhwKnQ7bhgXzzW9agk1LKsWCfjbL09YS/onY=

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

**Follow-Ups**:

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] About the BSD license** - Next by Date:
**Re: [eigen] XLC Port Part III: XLC failing to instantiate a partial template specialization unless it is defined before use in a forward declaration** - Previous by thread:
- Next by thread:

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