[histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?

Boost - Dev mailing list
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 <boost/type_traits/rank.hpp>
#include <boost/histogram/axis/traits.hpp>

int main() { return 0; }
```

produces this error message (excerpt):

```
cc1plus: error: return type specified for deduction guide
In file included from <source>:2:
/celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:11: error: 'decl-specifier' in declaration of deduction guide
  411 | constexpr unsigned rank(const Axis& axis) {
      |           ^~~~~~~~
/celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:1: error: 'decl-specifier' in declaration of deduction guide
  411 | constexpr unsigned rank(const Axis& axis) {
      | ^~~~~~~~~
/celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:11: error: 'unsigned' specified with 'rank<...auto...>'
  411 | constexpr unsigned rank(const Axis& axis) {
      |           ^~~~~~~~
/celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:20: error: deduction guide for 'boost::rank<T>' must have trailing return type
  411 | constexpr unsigned rank(const Axis& axis) {
      |                    ^~~~
In file included from <source>:1:
/celibs/boost_1_74_0/boost/type_traits/rank.hpp:82:27: note: 'template<class T> struct boost::rank' declared here
   82 | template <class T> struct rank : public integral_constant<std::size_t, (::boost::detail::rank_imp<T, 0>::value)>{};
      |                           ^~~~
```

gcc interprets my function called `rank` as a deduction guide for `boost::rank` in boost/type_traits/rank.hpp. It then continues to complain that this function does not look like a deduction guide. Well, it isn't one, duh. I can see nothing wrong with my code or the code in boost/type_traits, so my guess is a bug in gcc. If you all agree, I would report this. If this is really a bug in gcc, however, it exists since v7.1 all the way to gcc trunk.

In either case, it would be great if we could use a workaround in Boost until that problem is fixed. I found a workaround is to replace line 82 in boost/type_traits/rank.hpp with:

```
template <class T> using rank = integral_constant<std::size_t, (::boost::detail::rank_imp<T, 0>::value)>;
```

This avoids the issue because now the struct ``rank`` is gone and therefore gcc does not try to find a deduction guide for it. Is there a better solution?

Best regards,
Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?

Boost - Dev mailing list

> On 30. Oct 2020, at 14:52, Hans Dembinski <[hidden email]> 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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?

Boost - Dev mailing list
Le 30/10/2020 à 15:16, Hans Dembinski via Boost a écrit :

>> On 30. Oct 2020, at 14:52, Hans Dembinski <[hidden email]> 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.
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?

Boost - Dev mailing list

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 <[hidden email]>
>>> 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.

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?

Boost - Dev mailing list
Dear Thomas and John,

> On 30. Oct 2020, at 19:17, John Maddock via Boost <[hidden email]> 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 <[hidden email]> 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.
>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost