[Bug libstdc++/94545] New: std::to_integer(std::numeric_limits::max()) returns 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94545 Bug ID: 94545 Summary: std::to_integer(std::numeric_limits::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-op
[Bug libstdc++/94545] std::to_integer(std::numeric_limits::max()) returns 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94545
--- Comment #2 from Thomas Mercier ---
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
struct mylimits
{
static constexpr _Tp max() noexcept {
static_assert(sizeof(_Tp) == 0, "There is no specialization of mylimits for
this type.");
}
};
template<>
struct mylimits
{
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(std::numeric_limits::max()) returns 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94545 --- Comment #5 from Thomas Mercier --- (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 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.
[Bug c/85598] New: Incorrect warning only at -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598
Bug ID: 85598
Summary: Incorrect warning only at -O2 and -O3
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.mercier.jr at gmail dot com
Target Milestone: ---
Created attachment 44049
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44049&action=edit
Preprocessed file of program that reproduces the behavior
$ gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/brazil-pkg-cache/packages/GCC/GCC-7.x.200154.0/AL2012/DEV.STD.PTHREAD/build/gcc-7.3.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/local/p4clients/pkgbuild-Kfsa6/workspace/src/GCC/build/private/src/gcc-7.3.0/configure
--prefix=/local/p4clients/pkgbuild-Kfsa6/workspace/src/GCC/build/gcc-7.3.0
--enable-languages=c,c++,fortran --disable-plugin
--with-build-config=bootstrap-lto
--with-gmp=/local/p4clients/pkgbuild-Kfsa6/workspace/src/GCC/build/private/stage2
--with-mpfr=/local/p4clients/pkgbuild-Kfsa6/workspace/src/GCC/build/private/stage2
--with-mpc=/local/p4clients/pkgbuild-Kfsa6/workspace/src/GCC/build/private/stage2
--with-fpmath=sse --with-cpu-64=core2 --disable-multilib --disable-bootstrap
--with-glibc-version=2.12
--with-cloog=/local/p4clients/pkgbuild-Kfsa6/workspace/src/GCC/build/private/stage2
--with-ppl=/local/p4clients/pkgbuild-Kfsa6/workspace/src/GCC/build/private/stage2
--with-isl=/local/p4clients/pkgbuild-Kfsa6/workspace/src/GCC/build/private/stage2
--enable-libsanitizer --disable-stage1-checking
Thread model: posix
gcc version 7.3.0 (GCC)
When compiled with -O2 or -O3 optimization enabled, the following warning is
printed:
$ gcc -Wall -O2 /tmp/test.c
/tmp/test.c: In function ‘main’:
/tmp/test.c:9:31: warning: ‘snprintf’ output may be truncated before the last
format character [-Wformat-truncation=]
snprintf(str, 4, "%%%02X", x);
^
/tmp/test.c:9:7: note: ‘snprintf’ output between 4 and 5 bytes into a
destination of size 4
snprintf(str, 4, "%%%02X", x);
^
With lesser levels of optimization, no warning is printed:
$ gcc -Wall -O1 /tmp/test.c
$
This is the entire program (preprocessed attached):
#include
int main()
{
char temp[100];
unsigned int x;
char *str = temp;
for(x=0; x<256; ++x) {
snprintf(str, 4, "%%%02X", x);
}
}
Calling snprintf with NULL and 0 for the first two arguments returns 3 for all
values of the loop. I believe the correct behavior from GCC is no warning at
any optimization level.
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
Thomas Mercier changed:
What|Removed |Added
CC||thomas.mercier.jr at gmail dot
com
--- Comment #13 from Thomas Mercier ---
Was this feature meant to be protected by -std=c23? It doesn't appear to be in
GCC 13:
/tmp$ cat test.c
enum node_stat_item : unsigned {
NR_LRU_BASE = -1,
NR_INACTIVE_ANON = NR_LRU_BASE, /* must match order of LRU_[IN]ACTIVE
*/
NR_ACTIVE_ANON, /* " " " " " */
NR_INACTIVE_FILE,
};
int main()
{}
/tmp$ gcc --version
gcc (Debian 13.2.0-10) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/tmp$ gcc -std=c11 test.c
test.c:2:23: error: enumerator value outside the range of underlying type
2 | NR_LRU_BASE = -1,
| ^
test.c:4:9: error: overflow in enumeration values
4 | NR_ACTIVE_ANON, /* " " " " "
*/
|
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
--- Comment #15 from Thomas Mercier ---
No objection to the error message, but I would have expected a syntax error for
standards earlier than 23 which don't claim to support manually specifying the
underlying type for the enum. Like this with gcc 12:
test.c:1:21: error: expected identifier or ‘(’ before ‘:’ token
1 | enum node_stat_item : unsigned {
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 --- Comment #17 from Thomas Mercier --- I see, thank you!
