[Bug libstdc++/94545] New: std::to_integer<int>(std::numeric_limits<std::byte>::max()) returns 0

[Bug libstdc++/94545] New: std::to_integer<int>(std::numeric_limits<std::byte>::max()) returns 0

[thomas.mercier.jr at gmail dot com]

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

            Bug ID: 94545
           Summary: std::to_integer<int>(std::numeric_limits<std::byte>::m
                    ax()) returns 0
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thomas.mercier.jr at gmail dot com
  Target Milestone: ---

Created attachment 48252
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48252&action=edit
Preprocessed file

$ g++ -v -save-temps -std=c++17 test.cc
Using built-in specs.
COLLECT_GCC=g++
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.5.0-3ubuntu1~18.04' --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 --enable-bootstrap --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.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE test.cc -mtune=generic -march=x86-64 -std=c++1z
-fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o test.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/7
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cc -mtune=generic -march=x86-64 -auxbase test -std=c++1z
-version -fstack-protector-strong -Wformat -Wformat-security -o test.s
GNU C++14 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
        compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
        compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3eb3dc290cd5714c3e1c3ae751116f07
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o test.o test.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
-plugin-opt=-fresolution=test.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie -z now -z relro
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. test.o -lstdc++ -lm -lgcc_s -lgcc
-lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++1z' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'


The integer representation of the maximum std::byte value is 0, but I was
expecting 255.

This also appears to occur with GCC 9: https://godbolt.org/z/QfLTMH

[Bug libstdc++/94545] std::to_integer<int>(std::numeric_limits<std::byte>::max()) returns 0

[redi at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is because numeric_limits<byte>::max() is byte() because it isn't an
arithmetic type, so numeric_limits isn't meaningful.

[Bug libstdc++/94545] std::to_integer<int>(std::numeric_limits<std::byte>::max()) returns 0

[thomas.mercier.jr at gmail dot com]

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

--- Comment #2 from Thomas Mercier <thomas.mercier.jr at gmail dot com> ---
I thought that might be the response. Then why does it compile? The fact that
it does, and produces a result is surprising. I don't know what the standard
says, but just looking at cppreference it says that specializations are
provided for arithmetic types. We could have a more sane default than value
initialization
(https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/limits#L321)
that produces a compilation error if it's unspecified (something like below).

template<typename _Tp>
struct mylimits
{
  static constexpr _Tp max() noexcept {
    static_assert(sizeof(_Tp) == 0, "There is no specialization of mylimits for
this type."); 
  }
};

template<>
struct mylimits<bool>
{
  static constexpr bool max() noexcept { return true; }
};

// and so on...

Gives you:
$ g++ -std=c++17 test.cc
test.cc: In instantiation of ‘static constexpr _Tp mylimits<_Tp>::max() [with
_Tp = int]’:
test.cc:21:34:   required from here
test.cc:5:5: error: static assertion failed: There is no specialization of
mylimits for this type.
     static_assert(sizeof(_Tp) == 0, "There is no specialization of mylimits
for this type.");

[Bug libstdc++/94545] std::to_integer<int>(std::numeric_limits<std::byte>::max()) returns 0

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Thomas Mercier from comment #2)
> I thought that might be the response. Then why does it compile?

Because the standard requires it to.

> The fact that it does, and produces a result is surprising.
> I don't know what the standard says,

You should look. It's very explicit:

"The default numeric_limits<T> template shall have all members, but with 0 or
false values."

The standard is clear about what the primary template does, and is clear that
there is no specialization for std::byte.

std::byte is not a numeric type, why do you expect std::numeric_limits to be
meaningful for it?

If you want the value with all bits set, use ~std::byte().

[Bug libstdc++/94545] std::to_integer<int>(std::numeric_limits<std::byte>::max()) returns 0

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
cppreference does document this, see the second row of the "Return value" table
at https://en.cppreference.com/w/cpp/types/numeric_limits/max

[Bug libstdc++/94545] std::to_integer<int>(std::numeric_limits<std::byte>::max()) returns 0

[thomas.mercier.jr at gmail dot com]

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

--- Comment #5 from Thomas Mercier <thomas.mercier.jr at gmail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Thomas Mercier from comment #2)
> > I thought that might be the response. Then why does it compile?
> 
> Because the standard requires it to.
> 
> > The fact that it does, and produces a result is surprising.
> > I don't know what the standard says,
> 
> You should look. It's very explicit:
> 
> "The default numeric_limits<T> template shall have all members, but with 0
> or false values."
> 
> The standard is clear about what the primary template does, and is clear
> that there is no specialization for std::byte.
> 
> std::byte is not a numeric type, why do you expect std::numeric_limits to be
> meaningful for it?
> 
> If you want the value with all bits set, use ~std::byte().

Yeah paywalled unfortunately. :\ I since found the section you quote in a draft
document.

I don't have a problem with std::byte being a non-arithmetic type, but that
didn't occur to me as I was first writing the code. The behavior of the primary
template is what is surprising... and entirely compliant as you point out.