[histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?
Dear John and the other gurus,
a strange bug was reported for Boost.Histogram. It is a difficult one for which I would like to ask for help. To me it looks like a bug in gcc.
Here is the issue:
https://github.com/boostorg/histogram/issues/290
And here is a link to reproduce it:
https://godbolt.org/z/oK4866
The following innocent code compiled with gcc-7.1 or newer with -std=c++17
```
#include
On 30. Oct 2020, at 14:52, Hans Dembinski
wrote: Dear John and the other gurus,
a strange bug was reported for Boost.Histogram. It is a difficult one for which I would like to ask for help. To me it looks like a bug in gcc.
Here is the issue: https://github.com/boostorg/histogram/issues/290
Here is an absolute minimal example which does not include boost at all. https://godbolt.org/z/hrcYao clang is ok, msvc is ok, gcc fails.
Le 30/10/2020 à 15:16, Hans Dembinski via Boost a écrit :
On 30. Oct 2020, at 14:52, Hans Dembinski
wrote: Dear John and the other gurus,
a strange bug was reported for Boost.Histogram. It is a difficult one for which I would like to ask for help. To me it looks like a bug in gcc.
Here is the issue: https://github.com/boostorg/histogram/issues/290 Here is an absolute minimal example which does not include boost at all.
clang is ok, msvc is ok, gcc fails.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Not, an expert but I would say it looks like a gcc bug. As a workaround the function in the nested namespace can be declared with a trailing return type, this doesn't seem to trigger the bug: https://godbolt.org/z/fY979r Thomas
On 30/10/2020 15:39, Thomas Ferrand via Boost wrote:
Le 30/10/2020 à 15:16, Hans Dembinski via Boost a écrit :
On 30. Oct 2020, at 14:52, Hans Dembinski
wrote: Dear John and the other gurus,
a strange bug was reported for Boost.Histogram. It is a difficult one for which I would like to ask for help. To me it looks like a bug in gcc.
Here is the issue: https://github.com/boostorg/histogram/issues/290 Here is an absolute minimal example which does not include boost at all.
clang is ok, msvc is ok, gcc fails.
A bit of messing about shows that: * Returning T is OK. * Returning std::size_t is OK * Returning "unsigned int" is OK * Returning "signed int" is OK But: * Returning "unsigned" fails. * Returning "signed" fails. So is changing the return type to "unsigned int" a viable option? Weird, and does look like a bug. HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Not, an expert but I would say it looks like a gcc bug.
As a workaround the function in the nested namespace can be declared with a trailing return type, this doesn't seem to trigger the bug: https://godbolt.org/z/fY979r
Thomas
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Dear Thomas and John,
On 30. Oct 2020, at 19:17, John Maddock via Boost
wrote: On 30/10/2020 15:39, Thomas Ferrand via Boost wrote:
Le 30/10/2020 à 15:16, Hans Dembinski via Boost a écrit :
On 30. Oct 2020, at 14:52, Hans Dembinski
wrote: Dear John and the other gurus,
a strange bug was reported for Boost.Histogram. It is a difficult one for which I would like to ask for help. To me it looks like a bug in gcc.
Here is the issue: https://github.com/boostorg/histogram/issues/290 Here is an absolute minimal example which does not include boost at all.
clang is ok, msvc is ok, gcc fails.
A bit of messing about shows that:
* Returning T is OK.
* Returning std::size_t is OK
* Returning "unsigned int" is OK
* Returning "signed int" is OK
But:
* Returning "unsigned" fails.
* Returning "signed" fails.
So is changing the return type to "unsigned int" a viable option?
Weird, and does look like a bug.
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Not, an expert but I would say it looks like a gcc bug.
As a workaround the function in the nested namespace can be declared with a trailing return type, this doesn't seem to trigger the bug: https://godbolt.org/z/fY979r
thank you for the two easy work arounds. I didn't consider playing with the return type. Good that I can implement the workaround on my end. I will report this bug to the gcc folks. Thanks, Hans
participants (3)
-
Hans Dembinski
-
John Maddock
-
Thomas Ferrand