Closed lifflander closed 5 years ago
Cross-referenced: https://cee-gitlab.sandia.gov/EM-Plasma/EMPIRE/issues/1018
The fmt related problem is discussed in this issue: https://github.com/citra-emu/citra/issues/4766
I think that the compiler warning about non-type, class templates is bug. VT does not us any class non-type templates because they are not C++11 compatible. The error is on a function pointer non-type which is allowed:
/Users/jliffla/codes/vt/virtual-transport/src/vt/messaging/active.impl.h: In instantiation of 'vt::messaging::ActiveMessenger::PendingSendType vt::messaging::ActiveMessenger::sendMsgSz(const NodeType&, MessageT*, const ByteType&, const TagType&) [with MessageT = vt::collective::barrier::BarrierMsg; void (* f)(MessageT*) = vt::collective::barrier::Barrier::barrierUp; vt::messaging::ActiveMessenger::PendingSendType = vt::messaging::PendingSend; vt::NodeType = short int; vt::ByteType = long long unsigned int; vt::TagType = int]':
/Users/jliffla/codes/vt/virtual-transport/src/vt/messaging/active.impl.h:171:64: required from 'vt::messaging::ActiveMessenger::PendingSendType vt::messaging::ActiveMessenger::sendMsg(const NodeType&, MessageT*, const TagType&) [with MessageT = vt::collective::barrier::BarrierMsg; void (* f)(MessageT*) = vt::collective::barrier::Barrier::barrierUp; vt::messaging::ActiveMessenger::PendingSendType = vt::messaging::PendingSend; vt::NodeType = short int; vt::TagType = int]'
/Users/jliffla/codes/vt/virtual-transport/src/vt/collective/barrier/barrier.cc:224:59: required from here
/Users/jliffla/codes/vt/virtual-transport/src/vt/messaging/active.impl.h:193:63: error: non-type template parameters of class type only available with '-std=c++2a' or '-std=gnu++2a'
193 | auto const& han = auto_registry::makeAutoHandler<MessageT,f>(msg);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
/Users/jliffla/codes/vt/virtual-transport/src/vt/messaging/active.impl.h: In instantiation of 'vt::messaging::ActiveMessenger::PendingSendType vt::messaging::ActiveMessenger::broadcastMsgSz(MessageT*, const ByteType&, const TagType&) [with MessageT = vt::collective::barrier::BarrierMsg; void (* f)(MessageT*) = vt::collective::barrier::Barrier::barrierDown; vt::messaging::ActiveMessenger::PendingSendType = vt::messaging::PendingSend; vt::ByteType = long long unsigned int; vt::TagType = int]':
/Users/jliffla/codes/vt/virtual-transport/src/vt/messaging/active.impl.h:164:61: required from 'vt::messaging::ActiveMessenger::PendingSendType vt::messaging::ActiveMessenger::broadcastMsg(MessageT*, const TagType&) [with MessageT = vt::collective::barrier::BarrierMsg; void (* f)(MessageT*) = vt::collective::barrier::Barrier::barrierDown; vt::messaging::ActiveMessenger::PendingSendType = vt::messaging::PendingSend; vt::TagType = int]'
/Users/jliffla/codes/vt/virtual-transport/src/vt/collective/barrier/barrier.cc:235:58: required from here
/Users/jliffla/codes/vt/virtual-transport/src/vt/messaging/active.impl.h:151:63: error: non-type template parameters of class type only available with '-std=c++2a' or '-std=gnu++2a'
151 | auto const& han = auto_registry::makeAutoHandler<MessageT,f>(msg);
| ~~~~~~~~~~~~~~~~
@lifflander This is a bug in gcc 9.1 and 9.2. I ran into this issue a little while back but I must have forgotten to submit a patch. The VT code that triggers the bug is this:
template <typename MessageT, ActiveTypedFnType<MessageT>* f>
HandlerType makeAutoHandler(MessageT* const msg);
template <typename T, T value>
HandlerType makeAutoHandler();
When GCC sees makeAutoHandler< MessageT, f >( msg )
it incorrectly tries to match the template parameter of both versions of the function, even though only the first one is in the valid overload set. It then checks the validity of the template parameters and fails on the second because it tries to instantiate a non-type template parameter of MessageT one even though it shouldn't be checking that in the first place. I'll submit a pull request with a workaround which is just renaming the second overload.
@nmm0 Have branch/PR for fix wrt naming changes? (Orphan ticket at this point?)
Hmm. Commits work better with reference #'s .. added tags and moved to new branch.
Pulling the epoch changes out of branch-scope in future PR (should be separate story, merge conflicts with other changes).
Merged, closing.
Describe the bug
This happens in the context of EMPIRE using VT, but seems to stem from VT code and FMT (TPL in VT).
To Reproduce Steps to reproduce the behavior: