Re: [eigen] MSC compiler error: worth working around?

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

Sorry, it's not issue #94, it is #101 !

https://bitbucket.org/eigen/eigen/issue/101/innerstride-causes-recursive-call

Sorry for the confusion.
Benoit

2010/4/16 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2010/4/16 Eamon Nerbonne <eamon.nerbonne@xxxxxxxxx>:
>> On Fri, Apr 16, 2010 at 13:21, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
>> wrote:
>>>
>>> 2010/4/16 Eamon Nerbonne <eamon.nerbonne@xxxxxxxxx>:
>>> > Hi all,
>>> > In the course of specializing some of my code to accept various eigen
>>> > matrix
>>> > types, I ran into an MSC bug.
>>>
>>> There's 1 thing I dont understand: you're not the only one using MSC,
>>> so why are you the first one to hit this problem? Hauke, do you know
>>> about this?
>>
>> Possibly it's compiler version related (not what I expect though).  However,
>> it's also code that typically people outside of eigen won't use often.  In
>> my case it's something like this:
>> SomeNonEigenType<... , (MatrixBase<TDerived>::IsVectorAtCompileTime?1: 2) ,
>> ... >
>> Which I suppose just isn't that common?
>
> hoho, a MSC bug triggered by a ternary ?: operator used in a template
> parameter: this reminds me of issue 94.
> https://bitbucket.org/eigen/eigen/issue/94/anymatrixbase-evalto-caught-in-infinit
>
> Can you try moving the ?: out of the template parameter:
>
> enum { foo = MatrixBase<TDerived>::IsVectorAtCompileTime?1: 2 };
> SomeNonEigenType<... , foo , ... >
>
>
>>
>> Also, in eigen2, the "using Base::IsVectorAtCompileTime;" syntax wasn't
>> used, but rather that was evaluated at the spot (rows == 1 || cols==1) - so
>> eigen2 wouldn't have triggered this bug with MatrixBase, at least.
>> Actually, that's an argument in favor of working around the bug; otherwise
>> going eigen2-->eigen3 may involve compiler crashes which doesn't make
>> upgrading any easier.
>
> We want anyway to support MSC with eigen3, which means we have to work
> around its bugs anyway.
>
>>
>>
>>> >  Essentially, eigen's classes have lots of
>>> > members in the style of "using Base::SomeEnumMember;".  Using those kind
>>> > of
>>> > "inherited" members as part of computations (not just unmodified usage)
>>> > in
>>> > template parameters in MSC triggers compiler bugs or an ICE (depending
>>> > on
>>> > the computation).  I submitted a simple test-case & bug report to
>>> > microsoft,
>>> > but that's been closed [WontFix].
>>>
>>> At least they didn't sue you for patent infringement (USPTO 29043801
>>> "Method for triggering a bug in MSC with enums").
>>
>> I'm not too thrilled with their bug-resolution process either.   Still,
>> sometimes they do fix em, so I do report em.
>>
>>> > One workaround would be to replace "using Base::SomeEnumMember;" with
>>> > "enum{ SomeEnumMember = ei_traits<typename
>>> > Base::Derived>::SomeEnumMember};".
>>>
>>> Often, the stuff is only present in a Base class, not in ei_traits. So
>>> it would be:
>>>  enum { SomeEnum = Base::SomeEnum };
>>>
>>> > Leaving it out entirely works in MSC but
>>> > not in GCC, unless I'm missing something.
>>>
>>> Ah great! So on MSC we could replace using by just a comment opener "//"
>>> ?
>>>
>>> Maybe the bug could be worked around by introducing a macro
>>>    EIGEN_IMPORT_ENUM(Enum, From)
>>
>> As far as I can tell, yes, that just works.  I'm not sure if that's due to
>> MSC being too leniant or GCC's in error, but it doesn't work that way in
>> GCC.
>
> Try my suggestion above, though. Let's see if its the same as bug #94.
>
> Benoit
>
>>
>>>
>>> >  Alternatively, wouldn't it be
>>> > possible to remove these helpers entirely and just always refer to
>>> > ei_traits
>>> > for these things?
>>>
>>> Again, the enums aren't always present in the traits. See in MatrixBase..h.
>>> Also, a "using" statement is probably simpler, since it doesn't define
>>> anything new, so if we have the choice, it's probably better.
>>
>> Hmm, I see - yeah, it's not quite as straightforward as I hoped...
>>
>