That would be great. Thank for the fix. Thx, Haochen
From: Tomasz Kaminski <[email protected]> Sent: Thursday, November 27, 2025 12:20 AM To: Jiang, Haochen <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [r16-5613 Regression] FAIL: std/ranges/adaptors/93978.cc -std=gnu++26 (test for excess errors) on Linux/x86_64 Thank you for the report, similarly to the PR122864, it would uncover real bug caused by typo. On Wed, Nov 26, 2025 at 5:19 PM Tomasz Kaminski <[email protected]<mailto:[email protected]>> wrote: I was able to reproduce the problem and I believe it is the same problem as reported here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122864. The warning is produced. It was already fixed on master by: commit r16-5627-g4e7213aa081f1c0ca5b7e6a60d4e7ba5bcfb1f8a<https://gcc.gnu.org/cgit/gcc/commit/?id=4e7213aa081f1c0ca5b7e6a60d4e7ba5bcfb1f8a> Author: Tomasz KamiÅski <[email protected]<mailto:[email protected]>> Date: Wed Nov 26 14:28:39 2025 +0100 libstdc++: Fix typo in operator used in __pack_ints [PR122864<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122864>] `<=` was used instead of `<<`, this was detected by clang warning. PR libstdc++/122864<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122864> libstdc++-v3/ChangeLog: * include/std/chrono (chrono::__pack_ints): Replace `<=` with `<<`. On Wed, Nov 26, 2025 at 3:28 PM Tomasz Kaminski <[email protected]<mailto:[email protected]>> wrote: Would it be possible to include information on what the failure was? I have already pushed a patch that corrects warnings here, and use of `__packed` as the name, so would be interested if it still reproduces. On Wed, Nov 26, 2025 at 3:15 PM Haochen Jiang <[email protected]<mailto:[email protected]>> wrote: On Linux/x86_64, 1c9d93bfcd172c156fd0e94ea9990569bf46aeda is the first bad commit commit 1c9d93bfcd172c156fd0e94ea9990569bf46aeda Author: Tomasz Kamiński <[email protected]<mailto:[email protected]>> Date: Wed Nov 19 10:29:18 2025 +0100 libstdc++: Hashing support for chrono value classes [PR110357] caused FAIL: std/ranges/adaptors/93978.cc -std=gnu++26 (test for excess errors) with GCC configured with ../../gcc/configure --prefix=/export/users3/haochenj/src/gcc-bisect/master/master/r16-5613/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap To reproduce: $ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check RUNTESTFLAGS="conformance.exp=std/ranges/adaptors/93978.cc --target_board='unix{-m32}'" $ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check RUNTESTFLAGS="conformance.exp=std/ranges/adaptors/93978.cc --target_board='unix{-m32\ -march=cascadelake}'" $ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check RUNTESTFLAGS="conformance.exp=std/ranges/adaptors/93978.cc --target_board='unix{-m64}'" $ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check RUNTESTFLAGS="conformance.exp=std/ranges/adaptors/93978.cc --target_board='unix{-m64\ -march=cascadelake}'" (Please directly reply to this email for question about this report.) (If you met problems with cascadelake related, disabling AVX512F in command line might save that.) (However, please make sure that there is no potential problems with AVX512.)
