[Bug c++/107813] New: Enum with underlying type uint8_t bad promotion for unsigned char

[Bug c++/107813] New: Enum with underlying type uint8_t bad promotion for unsigned char

[gdrzewo at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107813

            Bug ID: 107813
           Summary: Enum with underlying type uint8_t bad promotion for
                    unsigned char
           Product: gcc
           Version: og10 (devel/omp/gcc-10)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gdrzewo at gmail dot com
  Target Milestone: ---

After migration from GCC9 to GCC10+ encountered the problem with printing
underlying types for enum with uint8_t. Below is minimal reproduction. Flooder
is a kind of wrapper for ostream used for logger.

#include <iostream>

enum TEnum: uint8_t {
    Kot = 67
};

struct Flooder
{
    Flooder(std::ostream& oo): o(oo) {};

    std::ostream& o;

    template <typename T>
    Flooder& operator<<(const T& t)
    {
        this->o << t;
        return *this;
    }
};

template<>
Flooder& Flooder::operator<<(const unsigned char& c) {
    o << static_cast<unsigned int>(c);
    return *this;
}

int main() {
    Flooder f(std::cout);

    auto cat = TEnum::Kot;
    unsigned char dog = 'D';

    std::cout << "first is enum uint8_t, second is unsigned char type, both
should be numbers" << std::endl;

    f << cat << " vs " << dog << "\n\r";

    return 0;
}

Std out 
(gcc9)
first is enum uint8_t, second is unsigned char type, both should be numbers
67 vs 68

(gcc10)
first is enum uint8_t, second is unsigned char type, both should be numbers
C vs 68

[Bug c++/107813] Enum with underlying type uint8_t bad promotion for unsigned char

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107813

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
GCC 10 is correct. The template is a exact match for the argument, accepting
any argument type, so the enum should not be converted to unsigned char.

When you call this->o << t then there is no exact match, so an implicit
conversion to unsigned char happens.

[Bug c++/107813] Enum with underlying type uint8_t bad promotion for unsigned char

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107813

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reduced:

void f(unsigned char) = delete;
void f(int) { }

enum TEnum: unsigned char {
    Kot = 67
};

template<typename T> void g(const T& t) { f(t); }
template<> void g(const unsigned char&) { }

int main()
{
  g(Kot);
}


This compiles with GCC 9 and not with GCC 10. But GCC 10 is correct, this was
fixed by commit r10-3736-ge295e3d981355c

    PR c++/92032 - DR 1601: Promotion of enum with fixed underlying type.

[Bug c++/107813] Enum with underlying type uint8_t bad promotion for unsigned char

[gdrzewo at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107813

--- Comment #3 from Grzegorz Drzewiecki <gdrzewo at gmail dot com> ---
(In reply to Jonathan Wakely from comment #1)
> When you call this->o << t then there is no exact match, so an implicit
> conversion to unsigned char happens.

OK. But what botter me. I've added global operator like:

std::ostream &operator<<(std::ostream &os, unsigned char c) {
    return os << static_cast<unsigned int>(c);
}

With this one my example works fine:

f << cat << " vs " << dog << "\n\r";

stdout: 67 vs 68.

There is different conversion for either global operator or template operator.

[Bug c++/107813] Enum with underlying type uint8_t bad promotion for unsigned char

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107813

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Grzegorz Drzewiecki from comment #3)
> (In reply to Jonathan Wakely from comment #1)
> > When you call this->o << t then there is no exact match, so an implicit
> > conversion to unsigned char happens.
> 
> OK. But what botter me. I've added global operator like:
> 
> std::ostream &operator<<(std::ostream &os, unsigned char c) {

Adding this is undefined behaviour, you're not allowed to redefine what it
means to write fundamental types to std::istream.

>     return os << static_cast<unsigned int>(c);
> }
> 
> With this one my example works fine:
> 
> f << cat << " vs " << dog << "\n\r";
> 
> stdout: 67 vs 68.
> 
> There is different conversion for either global operator or template
> operator.

No there isn't. You've just changed what the "this->o << t" expression inside
the template operator does. That template operator is still called, but now it
uses a different function to print the enum. You can easily verify this by
stepping through the code in a debugger.

There is no GCC bug here, this is just how C++ works.