https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92859
Bug ID: 92859
Summary: compiler treats enum type as an integer during
overload resolution when a bit-field of this enum is
considered
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: armagvvg at gmail dot com
Target Milestone: ---
Created attachment 47440
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47440&action=edit
gzipped preprocessed file
Enumeration types are different from their underlying types when participating
in function overload resolution. But the compiler doesn't differentiate them
when a bit-field member is defined from the enumeration type. And an overloaded
stream operator is defined inside a class where that enum exists. The sample:
--------
#include <iostream>
struct ES {
enum E { v };
// 1
friend std::ostream& operator<<(std::ostream& os, E) { return os << "E"; }
};
// 2 - should be the same but...
// std::ostream& operator<<(std::ostream& os, ES::E) { return os << "E"; }
struct S {
ES::E e : 1;
};
int main() {
S s{};
std::cout << s.e << std::endl;
return 0;
}
--------
It's expected that an output should be 'E' thus calling the operator<<(..., E)
defined here. But 's.e' field is considered integer and '0' is printed.
What's more interesting, if the operator will be defined as marked by '2', all
it works as expected.
Compiled with: g++ -Wall -Wextra -std=c++11 --save-temps -o tst.gcc tst.cpp
No output during compilation.
> gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
> uname -r
5.0.0-32-generic
I've repeated this bug also on my work with gcc 9.1.0. The same behaviour using
-std=c++14 and -std=c++17.
