[Bug tree-optimization/113370] wrong code with shift and _BitInt() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113370
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-01-13
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed.
Testcase which shows what something is wrong with the original value:
```
typedef _BitInt(255) B;
[[gnu::noipa]]
B
foo(int s)
{
B a = 0;
a = (-(B)3) >> s;
return a;
}
int
main(void)
{
B x = foo(51);
unsigned long *a = (unsigned long *)
__builtin_printf("%lx\n", a[0]);
__builtin_printf("%lx\n", a[1]);
__builtin_printf("%lx\n", a[2]);
__builtin_printf("%lx\n", a[3]);
//if (x != -1)
// __builtin_abort();
return 0;
}
```
[Bug tree-optimization/113371] New: [14 Regression] ICE: verify_ssa failed: PHI node with wrong VUSE on edge from BB 19 with -O -march=silvermont -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113371 Bug ID: 113371 Summary: [14 Regression] ICE: verify_ssa failed: PHI node with wrong VUSE on edge from BB 19 with -O -march=silvermont -ftree-vectorize Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57067=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -march=silvermont -ftree-vectorize testcase.c testcase.c: In function 'BN_uadd': testcase.c:4:1: error: PHI node with wrong VUSE on edge from BB 19 4 | BN_uadd (int dif, long t1) | ^~~ .MEM_125 = PHI <.MEM_8(D)(19)> expected .MEM_45 during GIMPLE pass: vect testcase.c:4:1: internal compiler error: verify_ssa failed 0x177532f verify_ssa(bool, bool) /repo/gcc-trunk/gcc/tree-ssa.cc:1203 0x13c8545 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2095 0x13c89ae execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7215-20240112190107-g8b447fa89d5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7215-20240112190107-g8b447fa89d5-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240112 (experimental) (GCC)
[Bug tree-optimization/113370] New: wrong code with shift and _BitInt() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113370 Bug ID: 113370 Summary: wrong code with shift and _BitInt() at -O0 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57066=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7215-20240112190107-g8b447fa89d5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7215-20240112190107-g8b447fa89d5-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240112 (experimental) (GCC)
[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 --- Comment #17 from Andrew Pinski --- The log file has `2844156: ...` where the preprocessed source is but it is hard to figure out how to extract correctly.
[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING --- Comment #16 from Andrew Pinski --- Can you attach the original preprocessed source? The reduced testcase does NOT compile on the trunk and fixing the warnings/errors on it still works.
[Bug middle-end/113364] [14 regression] ICE verify_ssa: `definition in block N does not dominate use in block` with `-O3 -march=znver2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364 Andrew Pinski changed: What|Removed |Added Target||aarch64-linux-gnu ||x86_64-linux-gnu --- Comment #7 from Andrew Pinski --- Note the testcase also ICEs on aarch64 with just -O3.
[Bug middle-end/113364] [14 regression] ICE verify_ssa: `definition in block N does not dominate use in block` with `-O3 -march=znver2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364 Andrew Pinski changed: What|Removed |Added Summary|[14 regression] Failed |[14 regression] ICE |bootstrap |verify_ssa: `definition in ||block N does not dominate ||use in block` with `-O3 ||-march=znver2` Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-01-13
[Bug middle-end/113364] [14 regression] Failed bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364 --- Comment #6 from Andrew Pinski --- Created attachment 57065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57065=edit Reduced testcase `-O3 -march=znver2 ` is enough with this testcase to reproduce it.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=10837 --- Comment #5 from Sam James --- (In reply to thutt from comment #2) PR10837 has some discussion on this point too.
[Bug middle-end/113364] [14 regression] Failed bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364 --- Comment #5 from Andrew Pinski --- Still happens at r14-7220-gac1a399bf61b04 . Let me try to reduce it.
[Bug middle-end/113364] [14 regression] Failed bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
--- Comment #4 from Sam James ---
Created attachment 57064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57064=edit
sanitizer_stack_store.ii
Crashes with:
```
# /var/tmp/portage/sys-devel/gcc-14.0.1./work/build/./gcc/xgcc -c
-shared-libgcc -B/var/tmp/portage/sys-devel/gcc-14.0.1./work/build/./gcc
-nostdinc++ ./.libs/sanitizer_stack_store.ii -std=gnu++14 -m32 -O3
-march=znver2
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/sanitizer_common/sanitizer_stack_store.cpp:
In member function ‘__sanitizer::uptr*
__sanitizer::StackStore::BlockInfo::GetOrUnpack(__sanitizer::StackStore*)’:
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/sanitizer_common/sanitizer_stack_store.cpp:253:7:
error: definition in block 31 does not dominate use in block 30
253 | uptr *StackStore::BlockInfo::GetOrUnpack(StackStore *store) {
| ^~
for SSA_NAME: vect_value_122.379_589 in statement:
vect_value_122.379_590 = PHI
PHI argument
vect_value_122.379_589
for PHI node
vect_value_122.379_590 = PHI
during GIMPLE pass: vect
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/sanitizer_common/sanitizer_stack_store.cpp:253:7:
internal compiler error: verify_ssa failed
0x5604d3777a76 verify_ssa(bool, bool) [clone .constprop.0]
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./gcc/tree-ssa.cc:1203
0x5604d4e9b845 execute_function_todo
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./gcc/passes.cc:2095
0x5604d4e9b845 do_per_function
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./gcc/passes.cc:1687
0x5604d4e9b845 execute_todo
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```
```
# /var/tmp/portage/sys-devel/gcc-14.0.1./work/build/./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/var/tmp/portage/sys-devel/gcc-14.0.1./work/build/./gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
14.0.1 p, commit 9d69e54a3b402b0fad067464bd402e92c14504a9'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --with-build-config='bootstrap-O3 bootstrap-lto
bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240112 (experimental)
8b447fa89d5e6b052c9309dfd1dafebdbd829ff9 (Gentoo Hardened 14.0.1 p, commit
9d69e54a3b402b0fad067464bd402e92c14504a9)
```
[Bug target/113312] Update __attribute__((interrupt)) for Intel FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312 --- Comment #17 from H.J. Lu --- Please try users/hjl/pr113312/gcc-13 branch: https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13?ref_type=heads It supports no_callee_saved_registers attribute. It should also avoid saving registers in noreturn functions in Linux kernel.
[Bug tree-optimization/110768] [14 Regression] Dead Code Elimination Regression since r14-2623-gc11a3aedec2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Andrew Pinski --- Fixed.
[Bug tree-optimization/110941] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2379-gc496d15954c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110941 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Andrew Pinski --- Fixed.
[Bug tree-optimization/110768] [14 Regression] Dead Code Elimination Regression since r14-2623-gc11a3aedec2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768 --- Comment #7 from Andrew Pinski --- Fixed.
[Bug tree-optimization/107823] [13/14 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0) since r13-1934-g353fd1ec3df92f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107823 Andrew Pinski changed: What|Removed |Added Target Milestone|13.3|14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Andrew Pinski --- Fixed.
[Bug tree-optimization/110841] [14 Regression] Dead Code Elimination Regression since r14-2675-gef28aadad6e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110841 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:34a827039fabcf24ce78da25984a1cc8be7ca2c3 commit r14-7221-g34a827039fabcf24ce78da25984a1cc8be7ca2c3 Author: Andrew Pinski Date: Fri Jan 12 20:24:34 2024 -0800 Add a few testcases for fix missed optimization regressions Adds a few new testcases for some missed optimization regressions. The analysis on how each should be optimized is in the testcases themselves (and in the bug report). Committed as obvious after running the testsuite to make sure they pass. PR tree-optimization/107823 PR tree-optimization/110768 PR tree-optimization/110941 PR tree-optimization/110450 PR tree-optimization/110841 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/ssa-thread-22.c: New test. * gcc.dg/tree-ssa/vrp-loop-1.c: New test. * gcc.dg/tree-ssa/vrp-loop-2.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-1.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-2.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/110450] [14 Regression] Dead Code Elimination Regression at -O2 since r14-261-g0ef3756adf0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110450 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug tree-optimization/110941] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2379-gc496d15954c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110941 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:34a827039fabcf24ce78da25984a1cc8be7ca2c3 commit r14-7221-g34a827039fabcf24ce78da25984a1cc8be7ca2c3 Author: Andrew Pinski Date: Fri Jan 12 20:24:34 2024 -0800 Add a few testcases for fix missed optimization regressions Adds a few new testcases for some missed optimization regressions. The analysis on how each should be optimized is in the testcases themselves (and in the bug report). Committed as obvious after running the testsuite to make sure they pass. PR tree-optimization/107823 PR tree-optimization/110768 PR tree-optimization/110941 PR tree-optimization/110450 PR tree-optimization/110841 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/ssa-thread-22.c: New test. * gcc.dg/tree-ssa/vrp-loop-1.c: New test. * gcc.dg/tree-ssa/vrp-loop-2.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-1.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-2.c: New test. Signed-off-by: Andrew Pinski
[Bug testsuite/113369] New: Many tests with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369 Bug ID: 113369 Summary: Many tests with -save-temps Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Created attachment 57063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57063=edit The list of files with -save-temps I got random LTO test failures with "make check -jN". There are many tests with -save-temps. How many of them are really required?
[Bug tree-optimization/107823] [13/14 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0) since r13-1934-g353fd1ec3df92f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107823 --- Comment #8 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:34a827039fabcf24ce78da25984a1cc8be7ca2c3 commit r14-7221-g34a827039fabcf24ce78da25984a1cc8be7ca2c3 Author: Andrew Pinski Date: Fri Jan 12 20:24:34 2024 -0800 Add a few testcases for fix missed optimization regressions Adds a few new testcases for some missed optimization regressions. The analysis on how each should be optimized is in the testcases themselves (and in the bug report). Committed as obvious after running the testsuite to make sure they pass. PR tree-optimization/107823 PR tree-optimization/110768 PR tree-optimization/110941 PR tree-optimization/110450 PR tree-optimization/110841 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/ssa-thread-22.c: New test. * gcc.dg/tree-ssa/vrp-loop-1.c: New test. * gcc.dg/tree-ssa/vrp-loop-2.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-1.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-2.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/110450] [14 Regression] Dead Code Elimination Regression at -O2 since r14-261-g0ef3756adf0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110450 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:34a827039fabcf24ce78da25984a1cc8be7ca2c3 commit r14-7221-g34a827039fabcf24ce78da25984a1cc8be7ca2c3 Author: Andrew Pinski Date: Fri Jan 12 20:24:34 2024 -0800 Add a few testcases for fix missed optimization regressions Adds a few new testcases for some missed optimization regressions. The analysis on how each should be optimized is in the testcases themselves (and in the bug report). Committed as obvious after running the testsuite to make sure they pass. PR tree-optimization/107823 PR tree-optimization/110768 PR tree-optimization/110941 PR tree-optimization/110450 PR tree-optimization/110841 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/ssa-thread-22.c: New test. * gcc.dg/tree-ssa/vrp-loop-1.c: New test. * gcc.dg/tree-ssa/vrp-loop-2.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-1.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-2.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/110768] [14 Regression] Dead Code Elimination Regression since r14-2623-gc11a3aedec2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:34a827039fabcf24ce78da25984a1cc8be7ca2c3 commit r14-7221-g34a827039fabcf24ce78da25984a1cc8be7ca2c3 Author: Andrew Pinski Date: Fri Jan 12 20:24:34 2024 -0800 Add a few testcases for fix missed optimization regressions Adds a few new testcases for some missed optimization regressions. The analysis on how each should be optimized is in the testcases themselves (and in the bug report). Committed as obvious after running the testsuite to make sure they pass. PR tree-optimization/107823 PR tree-optimization/110768 PR tree-optimization/110941 PR tree-optimization/110450 PR tree-optimization/110841 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/ssa-thread-22.c: New test. * gcc.dg/tree-ssa/vrp-loop-1.c: New test. * gcc.dg/tree-ssa/vrp-loop-2.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-1.c: New test. * gcc.dg/tree-ssa/vrp-unreachable-2.c: New test. Signed-off-by: Andrew Pinski
[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550 --- Comment #5 from Patrick Palka --- The comment #3 testcase seems fixed after r14-7218-gc48bedd1806722.
[Bug libstdc++/106749] Implement C++23 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 Bug 106749 depends on bug 108827, which changed state. Bug 108827 Summary: [C++23] Implement P2387R3, Pipe support for user-defined range adaptors https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fully implemented for GCC 14.
[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827 --- Comment #5 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ac1a399bf61b04845f5d6fc34e4b7a4db2bc5760 commit r14-7220-gac1a399bf61b04845f5d6fc34e4b7a4db2bc5760 Author: Patrick Palka Date: Fri Jan 12 23:02:12 2024 -0500 libstdc++: Implement C++23 std::bind_back from P2387R3 [PR108827] The implementation is based off of std::bind_front. Since this is a C++23 feature we use deducing this unconditionally. PR libstdc++/108827 PR libstdc++/111327 libstdc++-v3/ChangeLog: * include/bits/version.def (bind_back): Define. * include/bits/version.h: Regenerate. * include/std/functional (_Bind_back): Define for C++23. (bind_back): Likewise. * testsuite/20_util/function_objects/bind_back/1.cc: New test (adapted from corresponding bind_front test). * testsuite/20_util/function_objects/bind_back/111327.cc: Likewise.
[Bug libstdc++/111327] std::bind_front (and std::not_fn) doesn't always perfectly forward according to value category of the call wrapper object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111327 --- Comment #8 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ac1a399bf61b04845f5d6fc34e4b7a4db2bc5760 commit r14-7220-gac1a399bf61b04845f5d6fc34e4b7a4db2bc5760 Author: Patrick Palka Date: Fri Jan 12 23:02:12 2024 -0500 libstdc++: Implement C++23 std::bind_back from P2387R3 [PR108827] The implementation is based off of std::bind_front. Since this is a C++23 feature we use deducing this unconditionally. PR libstdc++/108827 PR libstdc++/111327 libstdc++-v3/ChangeLog: * include/bits/version.def (bind_back): Define. * include/bits/version.h: Regenerate. * include/std/functional (_Bind_back): Define for C++23. (bind_back): Likewise. * testsuite/20_util/function_objects/bind_back/1.cc: New test (adapted from corresponding bind_front test). * testsuite/20_util/function_objects/bind_back/111327.cc: Likewise.
[Bug tree-optimization/110768] [14 Regression] Dead Code Elimination Regression since r14-2623-gc11a3aedec2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
--- Comment #5 from Andrew Pinski ---
Note the main difference after this patch:
Global Exported: c_11 = [irange] short int [-20409, -20409][1, 1] MASK 0xb046
VALUE 0xb047
vs before:
Global Exported: c_11 = [irange] short int [-INF, +INF] NONZERO 0xb047
That is we figure out c_11 will only either be -20409 [(short)45127] or 1 now.
That allows to get rid of if statement that leads to unreachable.
Which then allows unrolling to happen as the estimate for that loop is less.
Note the following testcase (which is fixed also on the trunk) was failing in
GCC 13:
```
void foo(void);
static int a, b;
int main() {
{
short c = 45127;
int d;
b = 0;
for (; b <= 3; b++) {
if (b) continue;
d = 0;
for (; d <= 127; d++) {
if (!(((c) >= -20409) && ((c) <= 1))) {
__builtin_unreachable();
}
if (~(0 == a) & 1) return b;
c = 0;
for (; c <= 0; c++) a = 3;
}
}
foo();
}
}
```
The difference between this one and the original testcase is the # of
iterations of the loop. The same thing applies here; though I don't know what
caused the regression between GCC 12 and 13 for this one.
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #8 from Jerry DeLisle ---
(In reply to Steve Kargl from comment #7)
--- snip ---
> libgfortran is supposedly thread-safe and looking into
> flush_all_units() shows some unlocking and testing for
> locks. With 'print *, iam('john')', there may be lock
> contention.
My first thought when I observed the test case execution is locks. Have not
looked further yet.
[Bug libstdc++/113230] 27_io/print/1.cc fails when run with qemu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113230 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #6 from Hans-Peter Nilsson --- Exactly the same for cris-elf, newlib, "sim that's colocated with gdb". Baseboard is cris-sim.exp from a standard dejagnu installation *and* (probably the key): LC_ALL=C, which seems to contradict previous comments.
[Bug gcov-profile/113367] g++.dg/tree-prof/indir-call-prof-2.C never finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113367 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from H.J. Lu --- Reboot main seems to fix the issue.
[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Amyspark changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #20 from Amyspark --- Update: verified this now works: - MSYS2's current GCC (13.2.0 https://github.com/msys2/MINGW-packages/commits/master/mingw-w64-gcc, having the GCC-enlarged stack) - with commit 928c204030fe6c8856b76fd3d6f3583902389ad3 from releases/gcc-13 (plus the "breaking" flags reverted in https://github.com/msys2/MINGW-packages/commit/7e396296feeb89af1e9c00f5d7e39ba992de2150, shortening the stack as described earlier) . Thanks!
[Bug target/113353] Wrong rounding in std::nearbyint when vectorized with -funsafe-math-optimizations on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113353 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2009-July/266131.html
[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 Hans-Peter Nilsson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Hans-Peter Nilsson --- (In reply to Jason Merrill from comment #6) > But the regression is fixed. Only partially: the "g++.dg/modules/hello-1 -std=c++2b execute" is still there, and was part of the regression; at least introduced at the same time. This both for cris-elf@r14-7217-g444a31f3b354 and powerpc64le-unknown-linux-gnu@r14-7215-g8b447fa89d (https://gcc.gnu.org/pipermail/gcc-testresults/2024-January/805221.html). Thus reopening.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113038, which changed state. Bug 113038 Summary: [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug middle-end/111378] Missed optimization for comparing with exact_log2 constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111378 --- Comment #5 from Gabriel Ravier --- It does seem as though this transformation is not particularly favorable on most platforms. In fact, it seems as though the opposite transformation (which Clang does on many targets, along with MSVC) would be useful on most target, with some exceptions, including: - PowerPC, on which llvm-mca appears to consider `srdi.` to be faster than `cmplwi` - MIPS16, though I am unsure of this - GCC code generation is messy on there and I have trouble getting llvm-mca to parse GCC's output, but it seems to consider loading the constant from memory to be far slower than even doing the shift in two steps (which MIPS16 apparently requires, given GCC emits two `srl $4, $4, 8` instructions to do the shift) - Loongarch, which seems to give code for `x < 0x1` that I would have a hard time imagining being faster than a single shift given that it outputs this: lu12i.w $r12,61440>>12 # 0xf000 ori $r5,$r12,4095 sltu $r4,$r5,$r4 xori $r6,$r4,1 andi $r4,$r6,1 whereas a shift outputs this: bstrpick.d $r4,$r4,31,16 sltui $r4,$r4,1 (note: I am not too certain for some of these, but it also seems like Alpha, C6x, FR-V, RISC-V 64 and Sparc emit much smaller code sequences (i.e. 2-3 times smaller) that look faster at first glance for the shifting version as compared to the comparing version) (PS: Given I do not have a server farm containing every single target GCC supports for the purposes of benchmarking this, I'm mostly assuming this from manually peeking at assembly output to try and guess which would be better and what from looking at what llvm-mca considers to be the faster instruction sequence on the targets it supports, so potentially llvm-mca and me could just be wrong, though I would hope LLVM correctly models the performance of the chips it targets...)
[Bug c++/110997] [13 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110997 Andrew Pinski changed: What|Removed |Added CC||ephraim.feldblum at redis dot com --- Comment #6 from Andrew Pinski --- *** Bug 113368 has been marked as a duplicate of this bug. ***
[Bug c++/113368] ICE appearing in 13, not before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113368 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. Fixed on the trunk already too. *** This bug has been marked as a duplicate of bug 110997 ***
[Bug c++/113368] New: ICE appearing in 13, not before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113368
Bug ID: 113368
Summary: ICE appearing in 13, not before.
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ephraim.feldblum at redis dot com
Target Milestone: ---
godbolt: https://godbolt.org/z/qj1WcvxMx
Hi, I've encountered an ICE. It seems to be maybe caused by some combination of
* using gcc 13.1 or 13.2 (at least on godbolt)
* static member init of a std::pair,
* member init of a std::array,
* using std::countr_zero(),
* using a std::optional,
* all when constant folding.
If any of those are changed, the ICE disappears.
input:
#include // std::array
#include// std::countr_zero
#include // std::optional
#include// std::pair
template
struct VEB {
private:
// doesn't seem to ICE without a pair
static constexpr std::pair G = {1, 1};
// doesn't seem to ICE without an array, with at least one of the template
params being one of the pair.
std::array, 1> cluster = {};
// std::array, G.second> cluster = {};
public:
constexpr void insert(int x) {
cluster[x].min();
}
};
template
requires(U <= 64)
struct VEB {
private:
unsigned cluster = {};
public:
// doesn't seem to ICE without an optional
constexpr std::optional min() const {
// doesn't seem to ICE without std::countr_zero
return std::countr_zero(cluster);
}
};
// doesn't ICE without constant folding. either constexpr or consteval
constexpr auto check_correctness() {
VEB<65> veb{};
veb.insert(0);
return true; // doesn't ICE without the return
};
// alternatively, if consteval, ICEs without return
// consteval auto check_correctness() {
// VEB<65> veb{};
// veb.insert(0);
// } // does not need the return to ICE
// doesn't ICE without constant folding, -O or better is required
int main() {
check_correctness();
}
output:
: In function 'int main()':
:49:22: in 'constexpr' expansion of 'check_correctness()'
:37:15: in 'constexpr' expansion of 'veb.VEB<65>::insert(0)'
:17:23: in 'constexpr' expansion of
'(&((VEB<65>*)this)->VEB<65>::cluster.std::array,
1>::operator[](((std::array, 1>::size_type)x)))->VEB<1>::min()'
:50:1: in 'constexpr' expansion of 'VEB<1>()'
:50:1: internal compiler error: in cxx_eval_component_reference, at
cp/constexpr.cc:4394
50 | }
| ^
0x1ce7bde internal_error(char const*, ...)
???:0
0x7290fc fancy_abort(char const*, int, char const*)
???:0
0x77e950 maybe_constant_value(tree_node*, tree_node*, mce_value)
???:0
0x11175b3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x11178a6 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x79792c cp_fold_function(tree_node*)
???:0
0x7cb265 finish_function(bool)
???:0
0x89fd5b c_parse_file()
???:0
0x98c5d9 c_common_parse_file()
???:0
[Bug libstdc++/113318] [C++23] Implement P1185R12, Naming text encodings to demystify them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318 --- Comment #4 from Jonathan Wakely --- The static array can be compiled for 16-bit targets like msp640-elf, although it's probably a bad idea to use it if you are memory-constrained.
[Bug middle-end/113354] [14 Regression] : unable to find a register to spill on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-13 Target Milestone|--- |14.0 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 Summary|Regression/14: unable to|[14 Regression] : unable to |find a register to spill on |find a register to spill on |mips|mips Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code, ra --- Comment #3 from Andrew Pinski --- .
[Bug gcov-profile/113367] g++.dg/tree-prof/indir-call-prof-2.C never finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113367 --- Comment #2 from H.J. Lu --- I don't know if it is a regression. I rebooted machines and am running "make check" again.
[Bug gcov-profile/113367] g++.dg/tree-prof/indir-call-prof-2.C never finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113367 --- Comment #1 from Andrew Pinski --- I have never seen this testcase fail this way before. I even run on a skylake xeond and it works. Is this a regression?
[Bug c++/113367] New: g++.dg/tree-prof/indir-call-prof-2.C never finishes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113367 Bug ID: 113367 Summary: g++.dg/tree-prof/indir-call-prof-2.C never finishes Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86-64 On Intel Skylake server and Ice Lake server, g++.dg/tree-prof/indir-call-prof-2.C never finishes: 3795292 hjl 20 06072 2048 2048 R 100.0 0.0 357:43.40 indir-c+
[Bug libstdc++/113318] [C++23] Implement P1185R12, Naming text encodings to demystify them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0
[Bug testsuite/113366] New: g++.dg/cpp2a/concepts-pr67774.C FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113366 Bug ID: 113366 Summary: g++.dg/cpp2a/concepts-pr67774.C FAIL Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- It appears that since r14-6569-gfe54b57728c09a: commit fe54b57728c09ab0389e2bb3f079d5210566199d Author: Jonathan Wakely Date: Thu Dec 14 23:23:34 2023 + libstdc++: Implement C++23 header [PR107760] there are two new FAILs: FAIL: g++.dg/cpp2a/concepts-pr67774.C -std=c++23 (test for excess errors) FAIL: g++.dg/cpp2a/concepts-pr67774.C -std=c++26 (test for excess errors) $ xg++ -c -fconcepts-ts -std=c++26 concepts-pr67774.C In file included from /home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/ostream:43, from /home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/iostream:41, from concepts-pr67774.C:6: /home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/format:3193:45: error: type/value mismatch at argument 1 in template parameter list for ‘template using std::__conditional_t = typename std::__conditional::type<_If, _Else>’ 3193 | const _Tp, _Tp>; | ^ /home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/format:3193:45: note: expected a constant of type ‘bool’, got ‘auto [requires std::__format::__formattable_with<, _Tp, _Context, std::basic_format_parse_context >]’ /home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/format: In constructor ‘std::basic_format_arg<_Context>::handle::handle(_Tp&)’: /home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/format:3216:37: error: ‘__maybe_const_t’ was not declared in this scope; did you mean ‘remove_const_t’? 3216 | auto __func = _S_format<__maybe_const_t<_Tp>>; | ^~~ | remove_const_t [...]
[Bug rtl-optimization/112398] Suboptimal code generation for xor pattern on subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398 --- Comment #5 from Jeffrey A. Law --- I don't think we need to do any significant bit tracking to optimize the original neg8 test. I think we can be handled entirely within the simplify-rtx framework.I've got a junior engineer that's going to take a peek at this -- so don't go and fix it Andrew ;-)
[Bug libstdc++/113327] std::sleep_for(std::chrono::hours::max()) returns immediately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113327 --- Comment #1 from Jonathan Wakely --- Converting hours::max() to milliseconds overflows and produces a negative value.
[Bug rtl-optimization/112398] Suboptimal code generation for xor pattern on subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112398 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed|2023-11-05 00:00:00 |2024-01-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libstdc++/107466] [12 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 --- Comment #10 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c224dec0e7c88e7a95633023018cdcb6ee87c65f commit r14-7216-gc224dec0e7c88e7a95633023018cdcb6ee87c65f Author: Jonathan Wakely Date: Thu Jan 11 15:09:12 2024 + libstdc++: Fix non-portable results from 64-bit std::subtract_with_carry_engine [PR107466] I implemented the resolution of LWG 3809 in r13-4364-ga64775a0edd469 but it was recently noted in the MSVC STL github repo that the change causes possible truncation for 64-bit seeds. Whether the truncation occurs (and to what value) depends on the width of uint_least32_t which is not portable, so the output of the PRNG for 64-bit seed values is no longer the same as in C++20, and no longer portable across platforms. That new issue was filed as LWG 4014. I proposed a new change which reduces the seed by the LCG's modulus before the conversion to uint_least32_t. This ensures that 64-bit seed values are consistently reduced by the modulus before any truncation. This removes the platform-dependent behaviour and restores the old behaviour for std::subtract_with_carry_engine specializations using a 64-bit result type (such as std::ranlux48_base). libstdc++-v3/ChangeLog: PR libstdc++/107466 * include/bits/random.tcc (subtract_with_carry_engine::seed): Implement proposed resolution of LWG 4014. * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number. * testsuite/26_numerics/random/subtract_with_carry_engine/cons/lwg3809.cc: Check for expected result of 64-bit engine with seed that doesn't fit in 32-bits.
[Bug target/113365] LONG DOUBLE: denormals: assigning a constant: factor 100 slow,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113365 --- Comment #3 from newbie-02 --- hi, thank you, super service, super fast, works! can't tell if the -O0 behaviour is meaningful ... but think it is rarely used. I came to it in my attempts to avoid compiler cheating / optimizing.
[Bug rtl-optimization/113098] [14 Regression] LRA ICE building glibc for mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113098 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Note it was already filed as PR 113354.
[Bug rtl-optimization/113098] [14 Regression] LRA ICE building glibc for mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113098 Joseph S. Myers changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2024-01-12 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from Joseph S. Myers --- This ICE building glibc has come back with the new fix for bug 112918 (not bisected, just presuming that commit is the cause, but it seems very likely). Note: the arc ICE observed with the previous reverted fix for bug 112918 (bug 113097) has *not* come back.
[Bug target/113365] LONG DOUBLE: denormals: assigning a constant: factor 100 slow,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113365 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- At -O0, GCC produces a lot of load/stores to the stack and subnormals always have a penality in HW for x87. Note double uses SSE while long double uses x87 so the effect there will show up more. Note if we use -O2 and change the variable to be a volatile variable (otherwise the loop is just optimized away), the speed difference is gone because you no longer have addition happening of a subnormal which is what is causing the slow down. Anyways as I mentioned this is not a GCC bug but rather a HW limitation. There are many other targets where subnormals are slow even for double too.
[Bug libstdc++/113318] [C++23] Implement P1185R12, Naming text encodings to demystify them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318 --- Comment #3 from Jonathan Wakely --- Oh, I need to filter out NATS-DANO and NATS-DANO-ADD from the generated file.
[Bug target/113365] LONG DOUBLE: denormals: assigning a constant: factor 100 slow,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113365 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski --- Likely x87 being slow for subnormals.
[Bug c/113365] New: LONG DOUBLE: denormals: assigning a constant: factor 100 slow,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113365 Bug ID: 113365 Summary: LONG DOUBLE: denormals: assigning a constant: factor 100 slow, Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: newbie-02 at gmx dot de Target Milestone: --- Created attachment 57062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57062=edit Snippet demonstrating the problem. Filed that at 'sourceware', and they responded 'likely gcc'. See subject, assigning 3.3E-4932 to a variable takes 100 times longer than 3.4E-4932. Boiled it into the attached file which here produces the following output: Assigning a long double denormal constant to a long double variable seems very slow: The '+ ( argc - 1 )' part is an attempt to block compiler cheating by compile time assigning. First column is the time used for 100 iterations. Factor ~100 looks odd to me. 0.231966; 3.6451995318824746025284E-4951; x2l = ( LDBL_MIN_DEN + ( argc - 1 ) ) 0.002198; 3.501381E-4932; x2l = ( 3.5e-4932l + ( argc - 1 ) ) 0.002153; 3.400716E-4932; x2l = ( 3.4e-4932l + ( argc - 1 ) ) 0.002115; 3.3621031431120935062627E-4932; x2l = ( 3.3621031431120935063E-4932l + ( argc - 1 ) ) Note the break here, above are 'normal, below 'denormal' values. 0.209994; 3.3621031431120935058982E-4932; x2l = ( 3.362103143112093506E-4932l + ( argc - 1 ) ) 0.207378; 3.300052E-4932; x2l = ( 3.3e-4932l + ( argc - 1 ) ) 0.205288; 3.199388E-4932; x2l = ( 3.2e-4932l + ( argc - 1 ) ) Not observed without the '+ ( argc - 1 )' part, assume compiler cheating. 0.002090; 3.6451995318824746025284E-4951; x2l = ( LDBL_MIN_DEN ) 0.001863; 3.501381E-4932; x2l = ( 3.5e-4932l ) 0.001814; 3.400716E-4932; x2l = ( 3.4e-4932l ) 0.001865; 3.3621031431120935062627E-4932; x2l = ( 3.3621031431120935063E-4932l ) 0.001811; 3.3621031431120935058982E-4932; x2l = ( 3.362103143112093506E-4932l ) 0.001868; 3.300052E-4932; x2l = ( 3.3e-4932l ) 0.001926; 3.199388E-4932; x2l = ( 3.2e-4932l ) Not observed when assigning long double values around double normal / denormal break. 0.063401; 4.9406564584124654417657E-324; x2l = ( DBL_MIN_DEN + ( argc - 1 ) ) 0.002173; 2.399368E-308; x2l = ( 2.4e-308l + ( argc - 1 ) ) 0.002116; 2.300299E-308; x2l = ( 2.3e-308l + ( argc - 1 ) ) 0.002124; 2.2250738585072013999772E-308; x2l = ( 2.2250738585072014E-308l + ( argc - 1 ) ) 0.002272; 2.225073858507200964E-308; x2l = ( 2.225073858507201E-308l + ( argc - 1 ) ) 0.002590; 2.200024E-308; x2l = ( 2.2e-308l + ( argc - 1 ) ) 0.002082; 2.099749E-308; x2l = ( 2.1e-308l + ( argc - 1 ) ) But! affecting evaluation of denormal double constants! Here penalty factor 'only' ~30. 0.062303; 4.9406564584124654417657E-324; x2l = ( DBL_MIN_DEN + ( argc - 1 ) ) 0.002470; 2.4000788233E-308; x2l = ( 2.4e-308 + ( argc - 1 ) ) 0.002405; 2.2998902644E-308; x2l = ( 2.3e-308 + ( argc - 1 ) ) 0.002234; 2.2250738585072013830902E-308; x2l = ( 2.2250738585072014E-308 + ( argc - 1 ) ) 0.063479; 2.2250738585072008890246E-308; x2l = ( 2.225073858507201E-308 + ( argc - 1 ) ) 0.062954; 2.2001957711E-308; x2l = ( 2.2e-308 + ( argc - 1 ) ) 0.062987; 2.172122E-308; x2l = ( 2.1e-308 + ( argc - 1 ) ) No such problem when assigning to double variable. 0.001588; 4.940656458412465442E-324; x2d = ( DBL_MIN_DEN + ( argc - 1 ) ) 0.001528; 2.400079E-308; x2d = ( 2.4e-308 + ( argc - 1 ) ) 0.001557; 2.299890E-308; x2d = ( 2.3e-308 + ( argc - 1 ) ) 0.001582; 2.225073858507201383E-308; x2d = ( 2.2250738585072014E-308 + ( argc - 1 ) ) 0.001528; 2.225073858507200889E-308; x2d = ( 2.225073858507201E-308 + ( argc - 1 ) ) 0.001544; 2.200196E-308; x2d = ( 2.2e-308 + ( argc - 1 ) ) 0.001483; 2.17E-308; x2d = ( 2.1e-308 + ( argc - 1 ) ) Can't tell if hardware, compiler, library whatever. Assume evaluation of constant when read.
[Bug libstdc++/113318] [C++23] Implement P1185R12, Naming text encodings to demystify them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318
--- Comment #2 from Jonathan Wakely ---
After sending that I realised that text_encoding::environment_is can be
optimized like so:
template
static bool
environment_is()
{ return text_encoding(_Id)._M_is_environment(); }
Where that calls an extern function in the library:
bool
std::text_encoding::_M_is_environment() const
{
bool matched = false;
if (locale_t loc = ::newlocale(LC_ALL_MASK, "", (locale_t)0))
{
if (const char* codeset = ::nl_langinfo_l(CODESET, loc))
matched = ranges::contains(aliases(), string_view(codeset));
::freelocale(loc);
}
return matched;
}
That way we do a fast binary search for the ID in the static array, and only do
the slower string comparisons with the actual aliases of the specified id,
instead of searching the entire array doing string comparisons.
[Bug libstdc++/113318] [C++23] Implement P1185R12, Naming text encodings to demystify them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-12 --- Comment #1 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642887.html
[Bug middle-end/111378] Missed optimization for comparing with exact_log2 constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111378 --- Comment #4 from Jeffrey A. Law --- Whether or not this is an optimization or a pessimization is dependent on the target -- some targets can express the constant trivially in a branch conditions, others can not. Some targets have barrel shifters, others do not. In some cases the constant might get hoisted out of a loop, reducing the cost, but increasing register pressure, etc. If you look at a typical RISC target the transformation just trades constant construction for a shift. For constants that can be constructed in a single instruction neither sequence is inherently faster than the other. However, the shift sequence has an additional data dependency relative to the constant construction approach, so the shifted input approach would be considered slightly less desirable. For RISC-V we can construct any power of two constant in a single instruction if we have the zbs extension (which should be common in modern implementations). I suspect it would not be profitable on MIPS or PPC either as I think they have branches with ordered comparisons of two registers and the ability to construct 2^n in a single instrution. aarch64 seems to be the one target where this could be the helpful based on c#1. I guess it doesn't have branches with ordered comparisons of two registers and instead has to do an explicit comparison. Anyway, just wanted to get various thoughts recorded.
[Bug middle-end/113364] [14 regression] Failed bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364 --- Comment #3 from Andrew Pinski --- Note the most important part of the command line is `-march=znver2 -O3` .
[Bug c/89072] -Wall -Werror should be defaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072 --- Comment #12 from Vincent Lefèvre --- (In reply to Segher Boessenkool from comment #11) > Sure. If people want the pain, they can have it. But it is never okay to > cause other people to have -Werror -- they may have a different compiler > (version) that no one else has tested with, they may have different warnings > enabled, etc. For MPFR automated tests (and sometimes during my usual development too), I use -Werror in combination with -Wall plus some other useful warnings (-Wold-style-declaration -Wold-style-definition -Wmissing-parameter-type -Wmissing-prototypes -Wmissing-declarations -Wmissing-field-initializers -Wc++-compat -Wwrite-strings -Wcast-function-type -Wcast-align=strict -Wimplicit-fallthrough), and this is very useful, though this sometimes triggers GCC bugs. But of course, it's for internal use only. And the use of -Werror without "=" is valid only because I make sure that no other -W... options are used.
[Bug middle-end/113364] [14 regression] Failed bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Please provide more details, certainly my x86_64-linux and i686-linux bootstraps went fine.
[Bug fortran/108382] [12/13/14 Regression] Incorrect parsing when acc and omp coexist and -fopenmp -fopenacc is used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108382 --- Comment #2 from Tobias Burnus --- Fixed-form Fortran likewise fails for: !$acc enter !$acc& data !$omp flush !$omp& RELEASE end ! fails in this line: "Bad continuation line"
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #4 from H.J. Lu --- When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers, most of C++ exception tests crashed.
[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #19 from Amyspark --- Working on it. Is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 the patch you referred to earlier, Richard?
[Bug middle-end/113364] [14 regression] Failed bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||build, ice-on-valid-code CC||pinskia at gcc dot gnu.org
[Bug middle-end/113364] [14 regression] Failed bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364 --- Comment #1 from Sam James --- Ugh, I lost the builddir, so give me an hour or so to get it back...
[Bug middle-end/113364] New: [14 regression] Failed bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
Bug ID: 113364
Summary: [14 regression] Failed bootstrap
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
Target Milestone: ---
```
libtool: compile:
/var/tmp/portage/sys-devel/gcc-14.0.1./work/build/./gcc/xgcc -shared-libgcc
-B/var/tmp/portage/sys-devel/gcc-14.0.1./work/build/./gcc -nostdinc++
-L/var/tmp/portage/sys-devel/gcc-14
.0.1./work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/var/tmp/portage/sys-devel/gcc-14.0.1./work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/var/tmp/portage/sys-devel/gcc-14.0.1./
work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-i
nclude -m32 -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_RPC_XDR_H=0
-DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-1
4.0.1./libsanitizer/sanitizer_common -I.. -I
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/include
-I /var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsani
tizer -isystem
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/include/system
-Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-excep
tions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-pc-linux-gnu
-I/var/tmp/portage/sys-devel/gcc-14.
0.1./work/gcc-14.0.1./libsanitizer/../libstdc++-v3/libsupc++
-std=gnu++14 -fcf-protection -mshstk -DSANITIZER_LIBBACKTRACE
-DSANITIZER_CP_DEMANGLE -I /var/tmp/portage/sys-devel/gcc-14.0.1./work/gc
c-14.0.1./libsanitizer/../libbacktrace -I ../libbacktrace -I
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/../include
-include /var/tmp/portage/sys-devel/gcc-14.0.1./wor
k/gcc-14.0.1./libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -O3
-march=native -mtls-dialect=gnu2 -fno-semantic-interposition -pipe -Wa,-O2
-Wa,-mtune=znver2 -fcf-protection=none -fdiagnostics-color=
always -fdiagnostics-urls=never -ggdb3 -fno-harden-control-flow-redundancy
-march=znver2 -O3 -fno-harden-control-flow-redundancy -D_GNU_SOURCE -m32 -c
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.
1./libsanitizer/sanitizer_common/sanitizer_stack_store.cpp -fPIC -DPIC -o
.libs/sanitizer_stack_store.o
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/sanitizer_common/sanitizer_stack_store.cpp:246:6:
warning: ISO C++ forbids flexible array member ‘data’ [-Wpedantic]
246 | u8 data[];
| ^~~~
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/sanitizer_common/sanitizer_stack_store.cpp:
In member function ‘__sanitizer::uptr*
__sanitizer::StackStore::BlockInfo::GetOrUnpack(
__sanitizer::StackStore*)’:
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/sanitizer_common/sanitizer_stack_store.cpp:253:7:
error: definition in block 21 does not dominate use in block 20
253 | uptr *StackStore::BlockInfo::GetOrUnpack(StackStore *store) {
| ^~
for SSA_NAME: vect_value_119.379_149 in statement:
vect_value_119.379_143 = PHI
PHI argument
vect_value_119.379_149
for PHI node
vect_value_119.379_143 = PHI
during GIMPLE pass: vect
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./libsanitizer/sanitizer_common/sanitizer_stack_store.cpp:253:7:
internal compiler error: verify_ssa failed
0x55623ca579c2 verify_ssa(bool, bool) [clone .constprop.0]
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./gcc/tree-ssa.cc:1203
0x55623e17bd05 execute_function_todo
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./gcc/passes.cc:2095
0x55623e17bd05 do_per_function
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./gcc/passes.cc:1687
0x55623e17bd05 execute_todo
/var/tmp/portage/sys-devel/gcc-14.0.1./work/gcc-14.0.1./gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/105505] P1951R1 (Default Arguments for pair's Forwarding Constructor) is unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105505 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jonathan Wakely --- I really have pushed it now
[Bug libstdc++/106749] Implement C++23 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 Bug 106749 depends on bug 105505, which changed state. Bug 105505 Summary: P1951R1 (Default Arguments for pair's Forwarding Constructor) is unimplemented https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105505 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/113320] libstdc++ accepts std::format(std::move(runtime_fmt), 42);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113320 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed, thanks for checking it
[Bug fortran/113305] ICE with do concurrent and ivdep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org
[Bug fortran/113363] New: ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 Bug ID: 113363 Summary: ICE on ASSOCIATE and unlimited polymorphic function Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- While discussing a patch for PR89645/99065, the following issue with ASSOCIATE and unlimited polymorphic functions was found: https://gcc.gnu.org/pipermail/fortran/2024-January/060098.html program p implicit none class(*), allocatable :: x(:) x = foo() call prt (x) deallocate (x)! up to here all is fine... associate (var => foo()) ! <- crash here call prt (var) ! <- or here end associate contains function foo() result(res) class(*), allocatable :: res(:) res = [42] end function foo subroutine prt (x) class(*), intent(in) :: x(:) select type (x) type is (integer) print *, x class default stop 99 end select end subroutine prt end This ICEs on current trunk for any of the indicated statements.
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- I am going to double check something but it might be related to PR 112616 .
[Bug fortran/113338] [F2018] Valid Code Rejected, bind(C) procedure with pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-01-12 Keywords||rejects-valid Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Blocks||85836 Summary|Valid Code Rejected,|[F2018] Valid Code |bind(C) procedure with |Rejected, bind(C) procedure |pointer argument|with pointer argument Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836 [Bug 85836] [meta-bug] Fortran 2018 support
[Bug target/113362] RISCV64 divide and remainder with the same operands generates two divide operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113362 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-12 --- Comment #2 from Andrew Pinski --- The way divu/remu should be modeled as one instruction (using also the divmod/udivmod optab to expand them) and then split into either divu or remu or divu/mul/sub in split1 depending on the REG_UNUSED notes.
[Bug target/113362] RISCV64 divide and remainder with the same operands generates two divide operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113362 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- I thought I saw this before. This is 100% a target specific issue and might even be a cost model issue.
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #7 from Steve Kargl ---
On Thu, Jan 11, 2024 at 07:03:05AM +, john.harper at vuw dot ac.nz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
>
> --- Comment #2 from john.harper at vuw dot ac.nz ---
> Thank you! You may wish to know that in my Ubuntu system the program
> runs properly if the function iam is used in an assignment statement not a
> print statement.
Interesting. One of the first things that the internal
implementation does is
/* Flush all I/O units before executing the command. */
flush_all_units();
libgfortran is supposedly thread-safe and looking into
flush_all_units() shows some unlocking and testing for
locks. With 'print *, iam('john')', there may be lock
contention.
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #6 from Jakub Jelinek --- Created attachment 57061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57061=edit SloppyCRCMap.ii.xz When using current GCC trunk instead of current GCC 13 branch (CrtStuff.i.xz is the same between both), the problematic optimization doesn't happen, both before SRA and after it the code has MEM[(struct pair *)_5 + 32B] = MEM[(const struct pair &)__args#0_4(D)];
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #5 from Jakub Jelinek --- Created attachment 57060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57060=edit Timer.ii.xz from GCC 14
[Bug c/89072] -Wall -Werror should be defaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072 --- Comment #11 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #9) > It is not always wrong, it is a reasonable choice for some projects during > their development, if they are willing to fix or work around all new > warnings, even if they are false positives. Sure. If people want the pain, they can have it. But it is never okay to cause other people to have -Werror -- they may have a different compiler (version) that no one else has tested with, they may have different warnings enabled, etc. > But enabling any kind of -Werror by default is always wrong. Yup.
[Bug rtl-optimization/113362] New: RISCV64 divide and remainder with the same operands generates two divide operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113362
Bug ID: 113362
Summary: RISCV64 divide and remainder with the same operands
generates two divide operations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sh1.gccbug at tikouka dot nz
Target Milestone: ---
Input:
void fn(uint64_t out[2], uint64_t x, uint64_t y) {
out[0] = x / y;
out[1] = x % y;
}
Output:
fn(unsigned long*, unsigned long, unsigned long):
divua5,a1,a2
remua1,a1,a2
sd a5,0(a0)
sd a1,8(a0)
ret
https://godbolt.org/z/15Tn9PqGe
The `remu` operation may be better off replaced with a multiply and subtract
like how LLVM does it. Otherwise it may result in a redundant, slow division
operation.
[Bug tree-optimization/113361] New: wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113361 Bug ID: 113361 Summary: wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57059=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc testcase.c $ ./a.out Aborted It fails at different -On levels, depending on the value of 'x'. If the type of 'x' is changed to _BitInt(63), it ICEs instead: $ x86_64-pc-linux-gnu-gcc testcase.c during GIMPLE pass: bitintlower0 testcase.c: In function 'foo': testcase.c:2:1: internal compiler error: in build_bitint_type, at tree.cc:7178 2 | foo(_BitInt(63) x) | ^~~ 0x89c77a build_bitint_type(unsigned long, int) /repo/gcc-trunk/gcc/tree.cc:7178 0x2706118 handle_operand_addr /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2244 0x270fc92 lower_mul_overflow /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:4291 0x270fc92 lower_call /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5101 0x271a4b9 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6524 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-7215-20240112190107-g8b447fa89d5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-7215-20240112190107-g8b447fa89d5-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240112 (experimental) (GCC)
[Bug c++/111272] [13/14 Regression] Truncated error messages with -std=c++23 and -std=c++26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272 --- Comment #9 from Marek Polacek --- (In reply to Paul Keir from comment #8) > I wonder if a small part of this bug still remains. You're right, there's still something bad. I've opened bug 113360 for it.
[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- -Wanalyzer-infinite-loop implemented for GCC 14 by the above patch, so marking this one as resolved.
[Bug c++/113360] [13/14 Regression] Truncated constexpr error messages with -std=c++23/26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113360 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-12 Status|UNCONFIRMED |NEW
[Bug c++/113360] [13/14 Regression] Truncated constexpr error messages with -std=c++23/26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113360 Marek Polacek changed: What|Removed |Added Target Milestone|--- |13.3 Summary|Truncated constexpr error |[13/14 Regression] |messages with -std=c++23/26 |Truncated constexpr error ||messages with -std=c++23/26
[Bug c++/113360] New: Truncated constexpr error messages with -std=c++23/26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113360
Bug ID: 113360
Summary: Truncated constexpr error messages with -std=c++23/26
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
Test by Paul Keir:
constexpr bool init_list()
{
int total{};
for (int x : {1, 2, 3})
total += x;
return total == 6;
}
static_assert(init_list(), "");
Using -std=c++23, the error message is:
: In function 'constexpr bool init_list()':
:6:24: error: deducing from brace-enclosed initializer list requires
'#include '
+++ |+#include
1 | // #include
..
6 | for (int x : {1, 2, 3})
|^
: At global scope:
:11:24: error: non-constant condition for static assertion
11 | static_assert(init_list(), "");
| ~^~
:11:24: error: 'constexpr bool init_list()' called in a constant
expression
:3:16: note: 'constexpr bool init_list()' is not usable as a
'constexpr' function because:
3 | constexpr bool init_list()
|^
[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267 --- Comment #6 from Roger Sayle --- Sorry for the delay in replying/answering Jakub's questions/comments. Yes, using a define_insn_and_split in the backend fixes/works around the issue (and I agree your implementation/refinement in comment #5 is better than mine in comment #2), but I've a feeling that this approach isn't the ideal solution. Nothing about this split, is specific to these x86 instructions or even to the i386 backend. A more generic fix might be teach combine.cc that it can split parallels of two independent sets, with no inter dependencies, into two insns if the total cost of the two instructions is less than the original two, i.e. a 2 insn -> 2 insn combination. But then even this doesn't feel like the perfect approach... the reason combine doesn't already support 2->2 combinations is that they're not normally required, these types of problems are usually handled by GCSE or CSE or PRE (or ?). The pattern is insn1 defines REG1 to a complicated expression, that is live in several locations, so this instruction can't be eliminated. However, if the definition of REG1 is provided to insn2 that sets REG2, this second instruction can be significantly simplified. This feels like a classic (non-)constant propagation problem. I'm thinking perhaps want_to_gcse_p (or somewhere similar) could be tweaked. For people just joining the discussion (hopefully Jeff or a Richard): (set (REG:DI 1) (concat:DI (REG:SI 2) (REG:SI 3)) ... (set (REG:SI 4) (low_part (REG:DI 1)) can be simplified so that the second assignment becomes just: (set (REG:SI 4) (REG:SI 2)) and similarly for high_part vs. low_part. These don't even need to be in the same basic block. In actuality, "concat" is a large ugly expression, and high_part/low_part are actually SUBREGs (or could be TRUNCATE or SHIFT+TRUNCATE), but the theory should remain the same. I'm trying to figure out which pass (or cselib?) is normally responsible for handling this type of pseudo-reg propagation. But the define_insn_and_split certainly papers over the deficiency in the middle-end's RTL optimizers and fixes this (very) specific case/regression.
[Bug middle-end/113354] Regression/14: unable to find a register to spill on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #2 from Vladimir Makarov ---
Thank you for reporting this. The issue is not in the patch itself. The patch
simply triggered a hidden bug.
The insn in the question looks like
1657: {r3001:SI=r291:SI*r294:SI+r3002:SI;clobber r2788:SI;clobber r2390:SI;}
On the 1st subpass we choose alternative with the following constraints
(0) l (1) d (2) d (3) l (4) X (5) X {*mul_acc_si}
On the second subpass we choose alternative
(0) l (1) d (2) d (3) l (4) X (5) X {*mul_acc_si}
p2788 happened to get MD0 and it prevents p3001 to get MD0 too. p2788 can be
in any location for this alternative but LRA assignment subpass does not take
this into account.
I'll try to fix this hidden bug on the beginning of the next week.
[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #4 from Jakub Jelinek --- Will try to reproduce with trunk next (unfortunately due to the builtin trait changes the GCC 13 preprocessed sources can't be compiled with GCC 14).
[Bug tree-optimization/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #3 from Jakub Jelinek --- Created attachment 57058 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57058=edit CrtStuff.i.xz
[Bug tree-optimization/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #2 from Jakub Jelinek --- Created attachment 57057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57057=edit SloppyCRCMap.ii.xz
[Bug tree-optimization/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #1 from Jakub Jelinek --- Created attachment 57056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57056=edit Timer.ii.xz
[Bug tree-optimization/113359] [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Target Milestone|--- |13.3
[Bug tree-optimization/113359] New: [13 Regression] LTO miscompilation of ceph on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Bug ID: 113359
Summary: [13 Regression] LTO miscompilation of ceph on aarch64
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=2241339
when ceph is compiled with LTO on aarch64
_M_emplace_equal > > const,
Context*>&>
is changed by SRA to only store 64 + 32 bits into the std::pair rather than 64
+ 64 bits.
Reproducer:
./xg++ -B ./ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -Wall
-Wno-complain-wrong-lang -Werror=format-security -fstack-protector-strong
-mbranch-protection=standard -fasynchronous-unwind-tables
-fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-std=c++20 -fPIC -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc
-fno-builtin-free -fno-strict-aliasing -fsigned-char -Wtype-limits
-Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self
-Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers
-ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move
-Wstrict-null-sentinel -Woverloaded-virtual -fstack-protector-strong
-fdiagnostics-color=auto -c Timer.ii
./xg++ -B ./ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -Wall
-Wno-complain-wrong-lang -Werror=format-security -fstack-protector-strong
-mbranch-protection=standard -fasynchronous-unwind-tables
-fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-std=c++20 -fPIC -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc
-fno-builtin-free -fno-strict-aliasing -fsigned-char -Wtype-limits
-Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self
-Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers
-ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move
-Wstrict-null-sentinel -Woverloaded-virtual -fstack-protector-strong
-fdiagnostics-color=auto -c SloppyCRCMap.ii
./xg++ -B ./ -O2 -c CrtStuff.i
./xg++ -B ./ -flto=auto -shared -o out.so SloppyCRCMap.o Timer.o CrtStuff.o
-nostdlib
grep_cleanup() {
c++filt | grep -A16 '_M_emplace_equal:' | sed
's/[^:]*: *//'
}
diff -u <(aarch64-linux-gnu-objdump -d Timer.o | grep_cleanup)
<(aarch64-linux-gnu-objdump -d out.so | grep_cleanup)
which prints
--- /dev/fd/63 2024-01-12 19:24:37.317433462 +0100
+++ /dev/fd/62 2024-01-12 19:24:37.318433448 +0100
@@ -7,11 +7,11 @@
d2800600mov x0, #0x30 // #48
f90013f5str x21, [sp, #32]
aa0103f5mov x21, x1
- 9400bl 0
+ 97fff0bcbl 6ee0
aa0003f4mov x20, x0
f9400a62ldr x2, [x19, #16]
91002263add x3, x19, #0x8
f94002a7ldr x7, [x21]
f9001007str x7, [x0, #32]
- f94006a0ldr x0, [x21, #8]
- f9001680str x0, [x20, #40]
+ b9400aa1ldr w1, [x21, #8]
+ b9002801str w1, [x0, #40]
i.e. the -ffat-lto-objects non-LTO compilation stores 64-bit pointers at the
new returned pointer + 32 and + 40, while
LTO stores 64-bit pointer only to the former and 32-bit into the latter.
In *.cplxlower1 I still see
MEM[(struct pair *)_37 + 32B] = ISRA.253;
where
struct pair ISRA.253;
but sra has:
Created a replacement for ISRA.253 offset: 0, size: 64: SR.256D.22298
Created a replacement for ISRA.253 offset: 64, size: 32: SR.257D.22299
>From what I can see, that should be
std::multimap::value_type, i.e.
std::pair
[Bug libstdc++/113355] [14 Regression] libstdc++ tests leave directories which can't be removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113355 --- Comment #2 from Jonathan Wakely --- This isn't a regression though, it's always been that way.
[Bug libstdc++/113355] [14 Regression] libstdc++ tests leave directories which can't be removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113355 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-12 --- Comment #1 from Jonathan Wakely --- Those tests should clean up after themselves, so I think this happens when the test run is interrupted and the tests don't finish. I think we need a signal handler in make or dejagnu to remove them, or at least chmod them, in case the tests are interrupted with SIGINT or similar.
