Closed stephanmg closed 6 years ago
mlampe
commented
6 years ago It's line 415
// the following line silences -Woverloaded-virtual
using ElemProlongationBase<TDomain, CrouzeixRaviartElemTransfer<TDomain> >::prolongate;in local_transfer.h that triggers this bug with gcc 8. Deleting it makes the code compile again and you also get the warning back. ;)
stephanmg
commented
6 years ago Great, will you or should I provide the commit?
P.S.: That's why I don't like suppressed warnings.
mlampe
commented
6 years ago I don't know if this is a compiler bug or a bug in ug4. Let's wait for some more comments.
stephanmg
commented
6 years ago Okay. Will fall back to some other GCC version then for now. Your comments are highly appreciated. Btw.: GCC6 and GCC7 throw also a lot of more warnings. :)
bsumirak
commented
6 years ago I would go for compiler bug.
Judging from the rest of the prolongate methods in this class, I presume that what was intended with the prolongate(Vertex* ...) method was a specialization of the last templated version of the prolongate method. However, specializations of template class template methods are not permitted by the C++ specifications (unless the template class is fully specialized as well). So the specialized method was provided without being a template specialization. Unfortunately though, it thus hides the virtual method of the same name in the base class (which is probably not intended) and this is what the warning rightfully tells us.
The using directive has been added to expose the base class prolongate methods (in case they are needed) and I do not see why this should cause an error.
How about using
this->template prolongate<TSide>(...)
in lines 525 and 547? Will that circumvent the error with GCC 8.2.0, Stephan?
stephanmg
commented
6 years ago @bsumirak I can try this if you don't have a GCC 8.2.0 at hand.
Update 1: It's running... will report back here after the build finishes. Update 2: Compilation seems to succeed with these modifications. Btw. @mlampe strategy also works. I'll leave it to the ug4 head developers to decide on this issue, GCC 7 works for me, thus I'll fall back to this version unless the issue is resolved. Thanks!
I think one should not suppress the warning in non-release builds... For GCC 6, 7, 8 more than 90 warnings are popping up anyway, so why would one care about another, potential useful, warning? Just to put my two cents in.
Best wishes, SG
mlampe
commented
6 years ago My guess is that gcc 8 is actually using what the using directive brings in. That's why removing it helps.
I've committed the "this->template ..." fix. Makes explicit what is really meant and changes nothing else.
stephanmg
commented
6 years ago My guess is that gcc 8 is actually using what the using directive brings in. That's why removing it helps.
I've committed the "this->template ..." fix. Makes explicit what is really meant and changes nothing else.
Okay. Then I guess we can close the issue.
Here is the complete build log with Docker on Ubuntu and GCC 8.2.0: (This is the docker image gcc for Gitlab)
I think one needs to include a typename in SLOC 506 (local_transfer.h in function_spaces) but I'm not sure. I hope I didn't oversee any obvious misusage by myself.
Best wishes, SG