[Bug libstdc++/120160] Implicitly import std if standard library header is included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120160 --- Comment #4 from Jonathan Wakely --- (In reply to Jiang An from comment #1) > `import std;` in every header looks too heavy to me. IMO it's undesired to > import std::cin and its friends from . If you're thinking about the global static initialization done for std::cout etc. that's no longer done in , at least for most targets. It's done once in libstdc++.so and so there's no cost to including .
[Bug c++/115645] [12/13/14 Regression] new S[1][1]() requires non-explicit default ctor since r11-3092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115645 --- Comment #11 from Richard Biener --- (In reply to Marek Polacek from comment #10) > I'm a little nervous about backporting this one. Fine - you know more about this than me ;)
[Bug tree-optimization/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 Sam James changed: What|Removed |Added Summary|[9/10/11/12/13/14/15|[12/13/14/15 Regression] |Regression] Switch |Switch expansion generates |expansion generates extra |extra compares with |compares with |-fno-jump-tables |-fno-jump-tables| Keywords||missed-optimization Known to fail||15.0, 9.1.0 Known to work||8.5.0 Target Milestone|--- |12.5 --- Comment #1 from Sam James --- (Summaries only track active branches, but you can use "known to work" and "known to fail" for older.)
[Bug rtl-optimization/120279] New: Missed DCE for __builtin_{clzg,ctzg} when bitshift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120279
Bug ID: 120279
Summary: Missed DCE for __builtin_{clzg,ctzg} when bitshift
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kaelfandrew at gmail dot com
Target Milestone: ---
Created attachment 61424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61424&action=edit
C code
f1() uses __builtin_ctzg() then __builtin_clzg() for returning ARG0 when it
could instead use __builtin_clzg() in f0() (Vice versa) with flags -O3
-march=icelake-client.
gcc -v
==
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/16
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include/g++-v16
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/16/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 16.0. p,
commit 05d9c70131be267bfe5b36e663acda8729da6456' --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-offload-defaulted
--enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp
--disable-libada --enable-cet --disable-systemtap
--disable-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
--disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1
--with-build-config='bootstrap-lto bootstrap-cet'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250423 (experimental)
e9a81addd5b7d018e173fa8d59aafc2f84e41d8b (Gentoo 16.0. p, commit
05d9c70131be267bfe5b36e663acda8729da6456)
[Bug fortran/120139] [15/16 Regression] -fc-prototypes emits incorrect type for arrays with variable extents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120139 --- Comment #1 from GCC Commits --- The master branch has been updated by Thomas Koenig : https://gcc.gnu.org/g:4f9c7b5258f2af89bba8e954c277981d2e2ee1ef commit r16-638-g4f9c7b5258f2af89bba8e954c277981d2e2ee1ef Author: Thomas Koenig Date: Wed May 14 20:11:48 2025 +0200 Fix explicit arrays with non-constant size for -fc-prototypes. gcc/fortran/ChangeLog: PR fortran/120139 * dump-parse-tree.cc (get_c_type_name): If no constant size of an array exists, output an asterisk.
[Bug tree-optimization/120278] New: [9/10/11/12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 Bug ID: 120278 Summary: [9/10/11/12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: selectstriker2 at protonmail dot com Target Milestone: --- Created attachment 61423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61423&action=edit Simple source file Starting with GCC9, switch expansion to decision tree changed and has extra comparison instructions that will only ever evaluate to false because the true case has already been eliminated above. This was noted when switching to the arm-none-eabi C compiler based on GCC9, and exists in the x86_64 C compiler as well. Godbolt example : https://godbolt.org/z/f1fzMhbEx gcc main.c -fno-jump-tables Correct in GCC8 .L10: cmpl $2, -4(%rbp) je .L2 cmpl $2, -4(%rbp) jg .L3 cmpl $0, -4(%rbp) je .L4 cmpl $1, -4(%rbp) je .L5 jmp .L6 .L3: cmpl $3, -4(%rbp) je .L7 cmpl $4, -4(%rbp) je .L8 jmp .L6 Extra/incorrect comparisons started in GCC9 .L9: cmpl $4, -4(%rbp) je .L2 cmpl $4, -4(%rbp) jg .L3 cmpl $3, -4(%rbp) je .L4 cmpl $3, -4(%rbp) jg .L3- already checked for ==4, >4, ==3 so >3 will always be false cmpl $2, -4(%rbp) je .L5 cmpl $2, -4(%rbp) jg .L3- already checked for ==4, >4, ==3, ==2 so >2 will always be false cmpl $0, -4(%rbp) je .L6 cmpl $1, -4(%rbp) je .L7 jmp .L3
[Bug fortran/120107] [15/16 regression] -fc-prototypes for ISO_FORTRAN_ENV generates duplicate typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120107 --- Comment #3 from GCC Commits --- The master branch has been updated by Thomas Koenig : https://gcc.gnu.org/g:fa0dff8e99e81bc7a3db1dc57d4fc340e0525b1d commit r16-637-gfa0dff8e99e81bc7a3db1dc57d4fc340e0525b1d Author: Thomas Koenig Date: Tue May 13 19:02:06 2025 +0200 Do not dump non-interoperable types with -fc-prototypes. gcc/fortran/ChangeLog: PR fortran/120107 * dump-parse-tree.cc (write_type): Do not dump non-interoperable types.
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-14 Status|UNCONFIRMED |WAITING --- Comment #3 from Andrew Pinski --- Can you provide an example which regress at -O1 or above? Since -O0 code generation is not something which might be fixed at all?
[Bug libstdc++/99832] std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832 --- Comment #6 from Jonathan Wakely --- The addition to c++config.h works need to be before os_defines.h is included. But as I said I'm comment 2, I don't think either of the suggestions in comment 1 works. IIRC the way glibc ended up doing the time_t transition provides no way for libstdc++ to detect what it needs to know (which is not whether time_t is 64 bits, but whether it has *changed* from 32 to 64 bits).
[Bug middle-end/120278] [12/13/14/15 Regression] Switch expansion generates extra compares with -fno-jump-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120278 Andrew Pinski changed: What|Removed |Added Keywords|missed-optimization | Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #4 from Andrew Pinski --- -O0 code generation changed with r9-395-geb63c01f65d475 ( https://inbox.sourceware.org/gcc-patches/4a6e1c28-6a18-0084-e602-57a0c259d...@suse.cz/ ) This was done on purpose to speed up the compile time. Again this is an only -O0 change.
[Bug libstdc++/99832] std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832 --- Comment #7 from Jonathan Wakely --- https://inbox.sourceware.org/libc-alpha/88fdef1f-66fc-48d1-a2a4-7e719711a...@linaro.org/ Maybe there is a way, I'll revisit this and look at what current glibc does.
[Bug c++/58091] Non-ambiguous member lookup rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Jonathan Wakely --- GCC is correct, and EDG, Clang and MSVC all agree.
[Bug libstdc++/120266] newly introduced problems when using lto'ed libstdc++-v3 in a static link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120266 --- Comment #5 from Jonathan Wakely --- I suspect the reason for new warnings is just that GCC got better at LTO, so started to see the conflicting (but ABI-compatible) definitions of the exception classes. Those conflicting definitions have been present since GCC 5.1
[Bug libstdc++/67990] compare() does not sort null characters in locale collation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67990 --- Comment #3 from Jonathan Wakely --- Ah yes, thanks! Since this is unlikely to get fixed in libstdc++ any time soon, and is permitted by POSIX locales, maybe we should just close this as WONTFIX.
[Bug c++/120267] incorrectly ambiguous lookup depending on base class order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120267 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2025-05-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug libstdc++/120266] newly introduced problems when using lto'ed libstdc++-v3 in a static link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120266 --- Comment #3 from Jonathan Wakely --- Building libstdc++ with LTO is not supported. If you want to do that, you get to keep the pieces when it breaks.
[Bug libstdc++/120266] newly introduced problems when using lto'ed libstdc++-v3 in a static link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120266 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > I suspect without a testcase it is going to be hard to reproduce this. No, it's entirely expected. The std::logic_error and std::runtime_error classes always use a reference counted string type even when std::string is a typedef for the non-reference counted std::__cxx11::basic_string. This is one of many reasons that building libstdc++ with LTO is not supported, and will probably break. I have some ideas for using a separate ref-counted string type in the exceptions, so that it's neither the COW std::basic_string nor the __cow_string kluge, but it's not a priority.
[Bug c++/120274] New: internal compiler error: in tsubst_expr, at cp/pt.cc:21618 since clang 10 using -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120274
Bug ID: 120274
Summary: internal compiler error: in tsubst_expr, at
cp/pt.cc:21618 since clang 10 using -std=c++20
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
It is similar to #117325, but that bug was tested on godbolt and just happened
in version 14.1, not in trunk.
```
#include
#include
#include
using namespace std;
template
void reverse_collection(Container &&r)
{
auto end = r.cend();
reverse_collection(forward_iterator(end));
}
int main()
{
vector v{1};
reverse_collection(v);
}
```
```
:9:55: internal compiler error: in tsubst_expr, at cp/pt.cc:21618
9 | reverse_collection(forward_iterator(end));
|~~~^
0x293fa35 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x295d7a6 internal_error(char const*, ...)
???:0
0xada636 fancy_abort(char const*, int, char const*)
???:0
0xd291fd instantiate_decl(tree_node*, bool, bool)
???:0
0xd63812 instantiate_pending_templates(int)
???:0
0xbe8489 c_parse_final_cleanups()
???:0
0xe612c8 c_common_parse_file()
???:0
```
To quickly reproduce:
https://godbolt.org/z/1v7589evz
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 --- Comment #10 from GCC Commits --- The releases/gcc-14 branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:6b1a99c3e2cf0fb858ad42b19c6834f7593f091d commit r14-11775-g6b1a99c3e2cf0fb858ad42b19c6834f7593f091d Author: Nathaniel Shead Date: Thu May 8 23:06:13 2025 +1000 c++/modules: Fix handling of -fdeclone-ctor-dtor with explicit instantiations [PR120125] The attached testcase ICEs in maybe_thunk_body because we haven't created a node in the cgraph for an imported explicit instantiation yet. We in fact really shouldn't be emitting calls at all, since an imported explicit instantiation always exists in the TU we imported it from. But the required logic for that doesn't exist in this branch, so we'll just xfail the relevant check. PR c++/120125 gcc/cp/ChangeLog: * optimize.cc (maybe_thunk_body): Don't assume 'fn' has a cgraph node created. gcc/testsuite/ChangeLog: * g++.dg/modules/clone-4_a.C: New test. * g++.dg/modules/clone-4_b.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill
[Bug fortran/120225] [F2023] Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120225 --- Comment #3 from GCC Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:aac78fde6aa6ae829679355bc2a65bcadd834e6f commit r16-608-gaac78fde6aa6ae829679355bc2a65bcadd834e6f Author: Tobias Burnus Date: Wed May 14 09:18:09 2025 +0200 Fortran: Fix mpfr_tanu use in gfc_simplify_cotand with mpfr 4.2.0+ [PR120225] Fix commit r16-607-gc91c226762b422. gcc/fortran/ChangeLog: PR fortran/120225 * simplify.cc (gfc_simplify_cotand): Fix used argument in mpfr_tanu call.
[Bug c++/120272] [13/14/15/16 Regression] ICE in get_local_decls, at cp/name-lookup.c:4594 since 13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120272
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords||needs-bisection
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-05-14
--- Comment #1 from Andrew Pinski ---
Reduced to just:
```
template
class g {};
template
void g::f(concept1 auto)
{}
```
[Bug libstdc++/120266] newly introduced problems when using lto'ed libstdc++-v3 in a static link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120266 --- Comment #2 from Quentin Boswank --- Toolchain is build under https://github.com/QBos07/CP-dockercross and distributed as a docker image under ghcr.io/qbos07/cp-dockercross (build log under /toolchain/build.log.bz2) the app in question is https://github.com/ClasspadDev/yal wich has has devcontainers and ci configured
[Bug c++/120272] [13/14/15/16 Regression] ICE in get_local_decls, at cp/name-lookup.c:4594 since 13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120272 Andrew Pinski changed: What|Removed |Added Known to work||13.2.0 Summary|ICE in get_local_decls, at |[13/14/15/16 Regression] |cp/name-lookup.c:4594 since |ICE in get_local_decls, at |13.3|cp/name-lookup.c:4594 since ||13.3 Target Milestone|--- |13.4 Known to fail||13.3.0, 14.1.0
[Bug fortran/120225] [F2023] Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120225 --- Comment #1 from GCC Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c91c226762b422c3c310227e26f9390f93fe9f4d commit r16-607-gc91c226762b422c3c310227e26f9390f93fe9f4d Author: Tobias Burnus Date: Wed May 14 09:12:13 2025 +0200 Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR120225] As MPFR 4.2.0 added, support for degree trigonometric functions by via the mpfr_...u functions (for u = 360), it makes sense to use them if available. If MPFR is older, the current implementation is used as fallback. PR fortran/120225 gcc/fortran/ChangeLog: * simplify.cc: Include "trigd_fe.inc" only with MPFR < 4.2.0. (rad2deg, rad2deg): Only define if MPFR < 4.2.0. (gfc_simplify_acosd, gfc_simplify_asind, gfc_simplify_atand, gfc_simplify_atan2d, gfc_simplify_cosd, gfc_simplify_tand, gfc_simplify_cotand): Use mpfr_...u functions with MPFR >= 4.2.0.
[Bug c++/120275] New: ICE in write_type at cp/mangle.cc:2687 when using decltype(auto) with initializer list since 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120275
Bug ID: 120275
Summary: ICE in write_type at cp/mangle.cc:2687 when using
decltype(auto) with initializer list since 11.3
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
ICE with decltype(auto) in write_type at cp/mangle.cc:2687. It might b related
with issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120129, as it happens
since 11.3 also, but stack is totally different and internal error arises in a
different location:
```
#include
int main()
{
decltype(auto) values = {1, 2, 3, 4};
values.size()
}
```
```
opt/compiler-explorer/gcc-trunk-20250514/include/c++/16.0.0/initializer_list:71:7:
internal compiler error: in write_type, at cp/mangle.cc:2687
71 | size() const noexcept { return _M_len; }
| ^~~~
0x293fa35 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x295d7a6 internal_error(char const*, ...)
???:0
0xada636 fancy_abort(char const*, int, char const*)
???:0
0xc28879 mangle_decl(tree_node*)
???:0
0x17df8e5 decl_assembler_name(tree_node*)
???:0
0xf38d41 symbol_table::finalize_compilation_unit()
???:0
```
In previous versions (from 11.3 until 14.2), ICE was hidden by
"/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/initializer_list:71:
confused by earlier errors, bailing out", in trunk it gives the stack:
https://godbolt.org/z/5jzTsE9r1
[Bug middle-end/120276] [16 Regression] ICE in partial_subreg_p with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120276 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to fail||16.0 Target Milestone|--- |16.0 Known to work||15.1.0
[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #24 from Levi Zim ---
(In reply to Sam James from comment #23)
> (In reply to Levi Zim from comment #11)
> > It comes with a similar pattern that .gnu.lto_.jmpfuncs.1 is the most
> > different section ignoring offset differences and lto opts.
>
> ... then maybe related to PR119977 (would need the lto-dump -list -objects
> diff to be sure, see what I did over there).
Thanks. For this bug the size of .gnu.lto_.decls.1 is same but
.gnu.lto_.jmpfuncs.1 differs.
stage2-gcc/lto-dump -demangle -list -objects stage2-gcc/builtins.o >
stage2.ltodump
stage3-gcc/lto-dump -demangle -list -objects stage3-gcc/builtins.o >
stage3.ltodump
echo "Old size: $(cat stage2.ltodump | grep .gnu.lto_.decls.1 | awk -F' '
'{print $3}')"
echo "New size: $(cat stage3.ltodump | grep .gnu.lto_.decls.1 | awk -F' '
'{print $3}')"
Old size: 237166
New size: 237166
cat stage2.ltodump | tail +6 | sed '/^Type/Q' | sed 's/^[ \t]*//' | cut -d ' '
-f3- | awk '{print $3 "\t" $2}' > stage2.sections
cat stage3.ltodump | tail +6 | sed '/^Type/Q' | sed 's/^[ \t]*//' | cut -d ' '
-f3- | awk '{print $3 "\t" $2}' > stage3.sections
git diff --no-index stage{2,3}.sections
diff --git a/stage2.sections b/stage3.sections
index cd82f3d..7b56c8e 100644
--- a/stage2.sections
+++ b/stage3.sections
@@ -3,7 +3,7 @@
.gnu.lto_.icf.17366
.gnu.lto_.ipa_sra.16364
.gnu.lto_.inline.1 26107
-.gnu.lto_.jmpfuncs.1 19482
+.gnu.lto_.jmpfuncs.1 19469
.gnu.lto_.pureconst.1 882
.gnu.lto_.ipa_modref.1 3771
.gnu.lto_.lto.18
@@ -358,4 +358,4 @@
.gnu.lto_.decls.1 237166
.gnu.lto_.symtab.1 36223
.gnu.lto_.ext_symtab.1 1115
-.gnu.lto_.opts 331
+.gnu.lto_.opts 330
../gcc14/contrib/compare-lto -p stage{2,3}-gcc/builtins.o
stage2-gcc/builtins.o stage3-gcc/builtins.o differ: byte 41, line 1
stripping off LTO option section, then retrying
stage2-gcc/builtins.o.stripped stage3-gcc/builtins.o.stripped differ: byte
41, line 1
preserving stage2-gcc/builtins.o.stripped stage3-gcc/builtins.o.stripped
And it seems that after some packaging changes(new gcc14 package with reduced
features compared to gcc:
https://gitlab.archlinux.org/archlinux/packaging/packages/gcc14/-/blob/main/PKGBUILD).
This bug always reproduces even if I revert the previously bisected commit :/
[Bug tree-optimization/120283] New: `Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 -+ C1` gimple depends on single use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120283
Bug ID: 120283
Summary: `Transform comparisons of the form X +- C1 CMP C2 to X
CMP C2 -+ C1` gimple depends on single use
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 120206
Target Milestone: ---
Forwprop for comparisons proping uses generic rather than gimple so it will
cause to ignore single use in many cases.
So in this case of this pattern:
```
/* Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 -+ C1. */
(for cmp (eq ne)
(for op (plus minus)
rop (minus plus)
(simplify
(cmp (op@3 @0 INTEGER_CST@1) INTEGER_CST@2)
(if (!TREE_OVERFLOW (@1) && !TREE_OVERFLOW (@2)
&& !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@0))
&& !TYPE_OVERFLOW_TRAPS (TREE_TYPE (@0))
&& !TYPE_SATURATING (TREE_TYPE (@0)))
(with { tree res = int_const_binop (rop, @2, @1); }
(if (TREE_OVERFLOW (res)
&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
{ constant_boolean_node (cmp == NE_EXPR, type); }
(if (single_use (@3))
(cmp @0 { TREE_OVERFLOW (res)
? drop_tree_overflow (res) : res; }
```
forwprop ignores the single use there as it does combining into generic and
then uses generic to do the simplification.
I am thinking single use is not important here after all and has been ignored
anyways.
The pattern with single use was added with r7-502-ga8b85ce9e2bffc.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120206
[Bug 120206] Removal of
forward_propagate_into_gimple_cond/forward_propagate_into_comparison
[Bug tree-optimization/120283] `Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 -+ C1` gimple depends on single use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120283 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-15 Status|UNCONFIRMED |ASSIGNED
[Bug c++/120282] New: -Warray-bounds triggered incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120282 Bug ID: 120282 Summary: -Warray-bounds triggered incorrectly Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dominick.allen1989 at gmail dot com Target Milestone: --- Created attachment 61426 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61426&action=edit preprocessed file after cvise reduction and gcc info I could not make a minimal replication of this without putting my original code through cvise. I find the cvise output hard to understand, so I am not sure how valuable it is. The bug is triggered with `-std=c++20 -O3 -pthread -Werror=array-bounds`, but adding `--coverage -fsanitize=address,undefined` makes it go away. In the original code. I can provide additional context if desired, but it is not a minimal case. System information: gcc (Gentoo 14.2.1_p20241221 p7) 14.2.1 20241221 sys-devel/gcc-14.2.1_p20241221:14::gentoo USE="cet (cxx) (default-stack-clash-protection) (default-znow) fortran jit (multilib) nls openmp (pie) sanitize ssp zstd -ada (-custom-cflags) -d -debug -doc (-fixed-point) -go -graphite -hardened (-ieee-long-double) (-libssp) -lto -modula2 -objc -objc++ -objc-gc (-pch) -pgo -rust -systemtap -test (-time64) -valgrind -vanilla -vtv"
[Bug libstdc++/120266] newly introduced problems when using lto'ed libstdc++-v3 in a static link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120266 Oleg Endo changed: What|Removed |Added Resolution|INVALID |--- Ever confirmed|0 |1 Status|RESOLVED|NEW Last reconfirmed||2025-05-15 --- Comment #8 from Oleg Endo --- (In reply to Jonathan Wakely from comment #4) > > This is one of many reasons that building libstdc++ with LTO is not > supported, and will probably break. > > I have some ideas for using a separate ref-counted string type in the > exceptions, so that it's neither the COW std::basic_string nor the > __cow_string kluge, but it's not a priority. Since this is a known deficit, I'd propose to leave this one open as a feature request. Being able to use LTO across _all_ libs/modules that go into a program can be quite useful in embedded/bare-metal environments. So I think it's a valid request. Just not supported at the moment.
[Bug ipa/120098] [16 regression] g++.dg/lto/devirt-23 FAILs since r16-372-g064cac730f88dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120098 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #3 from Hans-Peter Nilsson --- ...and cris-elf, so likely everywhere. Any relation to PR60674 (XPASS: g++.dg/ipa/devirt-23.C), besides using the same source-file?
[Bug tree-optimization/117287] [13 Regression] assume attribute related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287 --- Comment #13 from GCC Commits --- The releases/gcc-13 branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:dce408e28c416f3a34f487e4f8bb2a1e1e586c69 commit r13-9657-gdce408e28c416f3a34f487e4f8bb2a1e1e586c69 Author: Andrew MacLeod Date: Thu Mar 27 10:51:16 2025 -0400 Backport new assume implementation and cache. Rework the assume pass to work properly and fail conservatively when it does. Also move it to its own file. PR tree-optimization/117287 gcc/ * Makefile.in (IBJS): Add tree-assume.o * gimple-range-fold.cc (class fur_edge): Relocate to... * gimple-range-fold.h (class fur_edge): Here. * gimple-range.cc (assume_query::assume_range_p): Remove. (assume_query::range_of_expr): Remove. (assume_query::assume_query): Move to tree-assume.cc. (assume_query::~assume_query): Remove. (assume_query::calculate_op): Move to tree-assume.cc. (assume_query::calculate_phi): Likewise. (assume_query::check_taken_edge): Remove. (assume_query::calculate_stmt): Move to tree-assume.cc. (assume_query::dump): Remove. * gimple-range.h (class assume_query): Move to tree-assume.cc * tree-assume.cc: New * tree-vrp.cc (struct pass_data_assumptions): Move to tree-assume.cc. (class pass_assumptions): Likewise. (make_pass_assumptions): Likewise. gcc/testsuite/ * g++.dg/cpp23/pr117287-attr.C: New.
[Bug tree-optimization/117287] [13 Regression] assume attribute related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #14 from Andrew Macleod --- fix in gcc 13 onward now.
[Bug libstdc++/120266] libstdc++ doesn't support LTO for static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120266 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #9 from Sam James --- Dupe. *** This bug has been marked as a duplicate of bug 108630 ***
[Bug libstdc++/108630] build failure in libstdc++ with LTO enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630 Sam James changed: What|Removed |Added CC||qubos at outlook dot de --- Comment #7 from Sam James --- *** Bug 120266 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/120283] `Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 -+ C1` gimple depends on single use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120283 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I forgot to say this comes from gcc.dg/tree-ssa/vrp89.c and gcc.dg/tree-ssa/vrp93.c .
[Bug tree-optimization/120280] ABS < 0 is not optimized to false by match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120280 --- Comment #3 from Andrew Pinski --- The full list of failures due to this missing optimization: gcc.dg/tree-ssa/vrp12.c gcc.dg/tree-ssa/vrp60.c gcc.dg/tree-ssa/pr20139.c
[Bug tree-optimization/120283] `Transform comparisons of the form X +- C1 CMP C2 to X CMP C2 -+ C1` gimple depends on single use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120283 --- Comment #3 from Andrew Pinski --- Seems like many of the single use with respect to comparisons need to be all relooked into as they are mostly ignored for forwprop in many cases.
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 Sam James changed: What|Removed |Added CC||ncahill_alt at yahoo dot com --- Comment #16 from Sam James --- *** Bug 51859 has been marked as a duplicate of this bug. ***
[Bug lto/51859] Linker option effects not reflected in symbol resolution file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51859 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Sam James --- This had a few fixes over the years but definitely works now with Binutils 2.44. *** This bug has been marked as a duplicate of bug 88643 ***
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 --- Comment #8 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:d787bc4fd372298e9ed5b11cb3050fd3707070f6 commit r16-613-gd787bc4fd372298e9ed5b11cb3050fd3707070f6 Author: Nathaniel Shead Date: Thu May 8 23:06:13 2025 +1000 c++/modules: Fix handling of -fdeclone-ctor-dtor with explicit instantiations [PR120125] The attached testcase ICEs in maybe_thunk_body because we haven't created a node in the cgraph for an imported explicit instantiation yet. We in fact really shouldn't be emitting calls at all, since an imported explicit instantiation always exists in the TU we imported it from. So this patch adjusts DECL_NOT_REALLY_EXTERN handling to account for this. PR c++/120125 gcc/cp/ChangeLog: * module.cc (trees_out::write_function_def): Only set DECL_NOT_REALLY_EXTERN if the importer might need to emit it. * optimize.cc (maybe_thunk_body): Don't assume 'fn' has a cgraph node created. gcc/testsuite/ChangeLog: * g++.dg/modules/clone-4_a.C: New test. * g++.dg/modules/clone-4_b.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill
[Bug c++/119864] [15/16 Regression][modules] ICE with -fmodules and omp reduction of UDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119864 --- Comment #7 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:79b7e37ea3fbbc43958190f69f6da3be3d809c9c commit r16-612-g79b7e37ea3fbbc43958190f69f6da3be3d809c9c Author: Nathaniel Shead Date: Mon Apr 21 20:40:29 2025 +1000 c++: Fix OpenMP support with C++20 modules [PR119864] In r15-2799-gf1bfba3a9b3f31, a new kind of global constructor was added. Unfortunately this broke C++20 modules, as both the host and target constructors were given the same mangled name. This patch ensures that only the host constructor gets the module name mangling for now, and stops forcing the creation of the target constructor even when no such initialization is required. PR c++/119864 gcc/cp/ChangeLog: * decl2.cc (start_objects): Only use module initialized for host. (c_parse_final_cleanups): Don't always create an OMP offload init function in modules. gcc/testsuite/ChangeLog: * g++.dg/modules/openmp-1.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 --- Comment #9 from GCC Commits --- The releases/gcc-15 branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:6dfc5d1fc86fe6aaed6e7c476286f7a5f0ffc867 commit r15-9681-g6dfc5d1fc86fe6aaed6e7c476286f7a5f0ffc867 Author: Nathaniel Shead Date: Thu May 8 23:06:13 2025 +1000 c++/modules: Fix handling of -fdeclone-ctor-dtor with explicit instantiations [PR120125] The attached testcase ICEs in maybe_thunk_body because we haven't created a node in the cgraph for an imported explicit instantiation yet. We in fact really shouldn't be emitting calls at all, since an imported explicit instantiation always exists in the TU we imported it from. So this patch adjusts DECL_NOT_REALLY_EXTERN handling to account for this. PR c++/120125 gcc/cp/ChangeLog: * module.cc (trees_out::write_function_def): Only set DECL_NOT_REALLY_EXTERN if the importer might need to emit it. * optimize.cc (maybe_thunk_body): Don't assume 'fn' has a cgraph node created. gcc/testsuite/ChangeLog: * g++.dg/modules/clone-4_a.C: New test. * g++.dg/modules/clone-4_b.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill (cherry picked from commit d787bc4fd372298e9ed5b11cb3050fd3707070f6)
[Bug c++/119864] [15/16 Regression][modules] ICE with -fmodules and omp reduction of UDT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119864 --- Comment #8 from GCC Commits --- The releases/gcc-15 branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:53690a84a35b905403126be66210d21e89f53ac6 commit r15-9680-g53690a84a35b905403126be66210d21e89f53ac6 Author: Nathaniel Shead Date: Mon Apr 21 20:40:29 2025 +1000 c++: Fix OpenMP support with C++20 modules [PR119864] In r15-2799-gf1bfba3a9b3f31, a new kind of global constructor was added. Unfortunately this broke C++20 modules, as both the host and target constructors were given the same mangled name. This patch ensures that only the host constructor gets the module name mangling for now, and stops forcing the creation of the target constructor even when no such initialization is required. PR c++/119864 gcc/cp/ChangeLog: * decl2.cc (start_objects): Only use module initialized for host. (c_parse_final_cleanups): Don't always create an OMP offload init function in modules. gcc/testsuite/ChangeLog: * g++.dg/modules/openmp-1.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill (cherry picked from commit 79b7e37ea3fbbc43958190f69f6da3be3d809c9c)
[Bug c++/120273] [15/16 regression] ICE when building corral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 Sam James changed: What|Removed |Added Target Milestone|--- |15.2
[Bug c++/120273] [15/16 regression] ICE when building corral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 --- Comment #2 from Sam James --- The strange "in pp_string, at pretty-print.cc:2655" is not a copy/paste error, btw.
[Bug c++/120273] New: [15/16 regression] ICE when building corral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273
Bug ID: 120273
Summary: [15/16 regression] ICE when building corral
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: c++-coroutines, ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Originally reported downstream in Gentoo at https://bugs.gentoo.org/955934 when
building 'corral'. The user reported it with GCC 14 but I can't reproduce that
yet.
What they hit is:
```
[1/2] Building CXX object CMakeFiles/corral_basic_test.dir/test/basic_test.cc.o
FAILED: CMakeFiles/corral_basic_test.dir/test/basic_test.cc.o
/usr/bin/x86_64-pc-linux-gnu-g++ -DCATCH_CONFIG_MAIN
-I/var/tmp/portage/dev-cpp/corral-1.0_pre20250424/work/corral-f1fc7ab37f9b0f4a8d4d611d15f92f1e89bebd27
-O2 -pipe -march=x86-64-v3 -ggdb3 -std=c++20 -MD -MT
CMakeFiles/corral_basic_test.dir/test/basic_test.cc.o -MF
CMakeFiles/corral_basic_test.dir/test/basic_test.cc.o.d -o
CMakeFiles/corral_basic_test.dir/test/basic_test.cc.o -c
/var/tmp/portage/dev-cpp/corral-1.0_pre20250424/work/corral-f1fc7ab37f9b0f4a8d4d611d15f92f1e89bebd27/test/basic_test.cc
In file included from
/var/tmp/portage/dev-cpp/corral-1.0_pre20250424/work/corral-f1fc7ab37f9b0f4a8d4d611d15f92f1e89bebd27/test/../corral/corral.h:30,
from
/var/tmp/portage/dev-cpp/corral-1.0_pre20250424/work/corral-f1fc7ab37f9b0f4a8d4d611d15f92f1e89bebd27/test/basic_test.cc:36:
/var/tmp/portage/dev-cpp/corral-1.0_pre20250424/work/corral-f1fc7ab37f9b0f4a8d4d611d15f92f1e89bebd27/test/../corral/Nursery.h:
I
n function ‘void
corral::BasicNursery::makePromise
({anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test::*)(TestEventLoop&,
int),
{anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test*,
std::reference_wrapper, int>(corral::Task
({anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test::*)(TestEventLoop&,
int),
{anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test*,
std::reference_wrapper, int)::
({anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test::*)(TestEventLoop&,
int), auto:62, auto:63
...)>::operator()(corral::BasicNursery::makePromise
({anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test::*)(TestEventLoop&,
int),
{anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test*,
std::reference_wrapper, int>(corral::Task
({anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test::*)(TestEventLoop&,
int),
{anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test*,
std::reference_wrapper, int)::
({anonymous}::test_body_133(test_body_133(TestEventLoop&)::_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.Frame*)::Test::*)(TestEventLoop&,
int), auto:62, auto:63
...)>::_ZZN6corral12BasicNurseryINS_13UseExceptionsEE11makePromiseIMZN12_GLOBAL__N_113test_body_133EPZNS4_L13test_body_133ER13TestEventLoopE56_ZN12_GLOBAL__N_1L13test_body_133ER13TestEventLoop.FrameE4TestFNS_4TaskIvEES6_iEJPS9_St17reference_wrapperIS5_EiEEEPNS_6detail7PromiseIvEET_DpT0_ENKUlSD_SL_SN_E_clISE_JSG_iEEESB_SD_SL_SN_.Frame*)’:
/var/tmp/portage/dev-cpp/corral-1.0_pre20250424/work/corral-f1fc7ab37f9b0f4a8d4d611d15f92f1e89bebd27/test/../corral/Nursery.h:795:43:
internal compiler error: in gimple_add_tmp_var, at gimplify.cc:802
795 | co_await (obj->*c)(std::move(a)...);
| ~^
0x5612b3cd91d2 gimple_add_tmp_var(tree_node*)
/usr/src/debug/sys-devel/gcc-14.2.1_p20241221/gcc-14-20241221/gcc/gimplify.cc:802
0x5612b4d32277 gimplify_target_expr
/usr/src/debug/sys-devel/gcc-14.2.1_p20241221/gcc-14-20241221/gcc/gimplify.cc:7493
0x5612b4d32277 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-14.2.1_p20241221/gcc-14-20241221/gcc/gimplify.cc:18289
0x5612b4d3180a gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-14.2.1_p20241221/gcc-14-20241221/gcc/gimplify.cc:18614
0x5612b4d3163f gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/usr/src/debug/sys-devel/gcc-14.2.1_p20241221/gcc-14-20241221/gcc/gimplify.cc:18013
0x5612b4d3180a gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
/u
[Bug c++/120273] [15/16 regression] ICE when building corral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 --- Comment #1 from Sam James --- Created attachment 61422 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61422&action=edit z.ii
[Bug c++/120273] [15/16 regression] ICE when building corral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Are you sure it is valid code because the ice is while trying to print out > an error message. Actually it is while printing out the ice. >From splay_tree_splay
[Bug c++/120273] [15/16 regression] ICE when building corral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 --- Comment #4 from Sam James --- (In reply to Andrew Pinski from comment #3) > Are you sure it is valid code because the ice is while trying to print out > an error message. Absolutely not sure ;) With 14, it hangs.
[Bug c++/120273] [15/16 regression] ICE when building corral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120273 --- Comment #3 from Andrew Pinski --- Are you sure it is valid code because the ice is while trying to print out an error message.
[Bug libstdc++/119125] [C++26] Implement P2548R6 copyable_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119125 --- Comment #1 from GCC Commits --- The master branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:708d40ff109c6e49d02b684a368571722a160af8 commit r16-617-g708d40ff109c6e49d02b684a368571722a160af8 Author: Tomasz KamiÅski Date: Thu May 8 08:08:43 2025 +0200 libstdc++: Avoid double indirection in move_only_function when possible [PR119125] Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the generic move_only_function(_Fn&&) constructor, such that when _Fn refers to selected move_only_function instantiations, the ownership of the target object is directly transfered to constructor object. This avoid cost of double indirection in this situation. We apply this also in C++23 mode. We also fix handling of self assignments, to match behavior required by standard, due use of copy and swap idiom. An instantiations MF1 of move_only_function can transfer target of another instantiation MF2, if it can be constructed via usual rules (__is_callable_from<_MF2>), and their invoker are convertible (__is_invoker_convertible()), i.e.: * MF1 is less noexcept than MF2, * return types are the same after stripping cv-quals, * adujsted parameters type are the same (__poly::_param_t), i.e. param of types T and T&& are compatible for non-trivially copyable objects. Compatiblity of cv ref qualification is checked via __is_callable_from<_MF2>. To achieve above the generation of _M_invoke functions is moved to _Invoker class templates, that only depends on noexcept, return type and adjusted parameter of the signature. To make the invoker signature compatible between const and mutable qualified signatures, we always accept _Storage as const& and perform a const_cast for locally stored object. This approach guarantees that we never strip const from const object. Another benefit of this approach is that move_only_function and move_only_function use same funciton pointer, which should reduce binary size. The _Storage and _Manager functionality was also extracted and adjusted from _Mofunc_base, in preparation for implementation for copyable_function and function_ref. The _Storage was adjusted to store functions pointers as void(*)(). The manage function, now accepts _Op enum parameter, and supports additional operations: * _Op::_Address stores address of target object in destination * _Op::_Copy, when enabled, copies from source to destination Furthermore, we provide a type-independent mamange functions for handling all: * function pointer types * trivially copyable object stored locally. Similary as in case of invoker, we always pass source as const (for copy), and cast away constness in case of move operations, where we know that source is mutable. Finally, the new helpers are defined in __polyfunc internal namespace. PR libstdc++/119125 libstdc++-v3/ChangeLog: * include/bits/mofunc_impl.h: (std::move_only_function): Adjusted for changes in bits/move_only_function.h (move_only_function::move_only_function(_Fn&&)): Special case move_only_functions with same invoker. (move_only_function::operator=(move_only_function&&)): Handle self assigment. * include/bits/move_only_function.h (__polyfunc::_Ptrs) (__polyfunc::_Storage): Refactored from _Mo_func::_Storage. (__polyfunc::__param_t): Moved from move_only_function::__param_t. (__polyfunc::_Base_invoker, __polyfunc::_Invoke): Refactored from move_only_function::_S_invoke. (__polyfunc::_Manager): Refactored from _Mo_func::_S_manager. (std::_Mofunc_base): Moved into __polyfunc::_Mo_base with parts extracted to __polyfunc::_Storage and __polyfunc::_Manager. (__polyfunc::__deref_as, __polyfunc::__invoker_of) (__polyfunc::__base_of, __polyfunc::__is_invoker_convertible): Define. (std::__is_move_only_function_v): Renamed to __is_polymorphic_function_v. (std::__is_polymorphic_function_v): Renamed from __is_move_only_function_v. * testsuite/20_util/move_only_function/call.cc: Test for functions pointers. * testsuite/20_util/move_only_function/conv.cc: New test. * testsuite/20_util/move_only_function/move.cc: Tests for self assigment. Reviewed-by: Jonathan Wakely Signed-off-by: Tomasz KamiÅski
[Bug c/120277] New: Crash at -O2: in upper_bound, at value-range.h:1181
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120277
Bug ID: 120277
Summary: Crash at -O2: in upper_bound, at value-range.h:1181
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
This code crashes at -O2:
int a, b;
int c(int d, long e) {
switch (d) {
case 129:
a = 1;
case 128:
break;
default:
return 1;
}
*(int *)e = 0;
}
void f(int d, long e) { c(d, e); }
void g() {
int h = b * sizeof(int);
f(h + 7, h);
}
void main() {}
Compiler Explorer: https://godbolt.org/z/9f9jcon4q
Crash:
:18:1: internal compiler error: in upper_bound, at value-range.h:1181
18 | void main() {}
| ^~~~
Backtrace:
0x2618675 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x26363e6 internal_error(char const*, ...)
???:0
0x9f3274 fancy_abort(char const*, int, char const*)
???:0
0x232440f fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
???:0
0x2324d12 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
???:0
0x230d643 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
???:0
0x14f75b3 range_query::value_of_stmt(gimple*, tree_node*)
???:0
0x1361117 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
???:0
0x22af8f7 dom_walker::walk(basic_block_def*)
???:0
0x136007b substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
???:0
0x14bc58e execute_ranger_vrp(function*, bool)
???:0
Bisected to
https://github.com/gcc-mirror/gcc/commit/c40a4cc2d943d8572a62f21d3eb1d4171e51d5ac
[Bug libstdc++/119125] [C++26] Implement P2548R6 copyable_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119125 --- Comment #2 from GCC Commits --- The master branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:0e93f7cd4ed0cf6bcfda90ed4dcad51a1f65b4b6 commit r16-618-g0e93f7cd4ed0cf6bcfda90ed4dcad51a1f65b4b6 Author: Tomasz KamiÅski Date: Mon May 12 10:01:22 2025 +0200 libstdc++: Implement C++26 copyable_function [PR119125] This patch implements C++26 copyable_function as specified in P2548R6. It also implements LWG 4255 that adjust move_only_function so constructing from empty copyable_function, produces empty functor. This falls from existing checks, after specializing __is_polymorphic_function_v for copyable_function specializations. For compatible invoker signatures, the move_only_function may be constructed from copyable_funciton without double indirection. To achieve that we derive _Cpy_base from _Mo_base, and specialize __is_polymorphic_function_v for copyable_function. Similary copyable_functions with compatible signatures can be converted without double indirection. As we starting to use _Op::_Copy operation from the _M_manage function, invocations of that functions may now throw exceptions, so noexcept needs to be removed from the signature of stored _M_manage pointers. This also affects operations in _Mo_base, however we already wrap _M_manage invocations in noexcept member functions (_M_move, _M_destroy, swap). PR libstdc++/119125 libstdc++-v3/ChangeLog: * doc/doxygen/stdheader.cc: Addded cpyfunc_impl.h header. * include/Makefile.am: Add bits cpyfunc_impl.h. * include/Makefile.in: Add bits cpyfunc_impl.h. * include/bits/cpyfunc_impl.h: New file. * include/bits/mofunc_impl.h: Mention LWG 4255. * include/bits/move_only_function.h: Update header description and change guard to also check __glibcxx_copyable_function. (_Manager::_Func): Remove noexcept. (std::__is_polymorphic_function_v>) (__variant::_Never_valueless_alt>) (move_only_function) [__glibcxx_move_only_function]: Adjust guard. (std::__is_polymorphic_function_v>) (__variant::_Never_valueless_alt>) (__polyfunc::_Cpy_base, std::copyable_function) [__glibcxx_copyable_function]: Define. * include/bits/version.def: Define copyable_function. * include/bits/version.h: Regenerate. * include/std/functional: Define __cpp_lib_copyable_function. * src/c++23/std.cc.in (copyable_function) [__cpp_lib_copyable_function]: Export. * testsuite/20_util/copyable_function/call.cc: New test based on move_only_function tests. * testsuite/20_util/copyable_function/cons.cc: New test based on move_only_function tests. * testsuite/20_util/copyable_function/conv.cc: New test based on move_only_function tests. * testsuite/20_util/copyable_function/copy.cc: New test. * testsuite/20_util/copyable_function/move.cc: New test based on move_only_function tests. Reviewed-by: Jonathan Wakely Signed-off-by: Tomasz KamiÅski
[Bug c++/119844] Incomplete types are displayed after the import module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119844 --- Comment #4 from Nathaniel Shead --- (In reply to printfne from comment #3) > Thank you for the solution you proposed. It is indeed very useful. Besides, > I want to know if the C++ standard has any regulations on the symbols > exported in the module? For example, make them the same as those defined in > the cpp file? I'm not entirely sure what you're asking, sorry! But yes, generally if you forward declare and export an entity in the module, when defining it in a module implementation unit you must provide a compatible declaration, as with #includes.
[Bug libstdc++/120160] Implicitly import std if standard library header is included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120160 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #3 from Nathaniel Shead --- (In reply to Jiang An from comment #1) > `import std;` in every header looks too heavy to me. IMO it's undesired to > import std::cin and its friends from . FWIW, I'm not sure I necessarily agree: 'import std;' is effectively free (it takes less than 0.01 seconds per TU on my machine) if '-fmodule-lazy' is in effect, as it is by default. Yes, it's potentially a bit surprising for other names to be exported as well, but that is already the case to a lesser or greater extent due to the nature of the headers. (In reply to m.cencora from comment #2) > I think better option for aiding migration to modules world is to provide > something similar to MSVC /translateIncludes option as that would work in > case of all code, and not just standard library headers. > > https://learn.microsoft.com/en-us/cpp/build/reference/ > translateinclude?view=msvc-170 GCC always performs automatic include translation for header units, if the module mapper provides an eligible CMI (and doesn't disable the mapping). You can use https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-flang-info-include-translate to get the compiler to dump a note every time it does this. One downside of this is that this will likely not be as performant for standard library headers as replacing with 'import std', as depending on how the standard library header CMIs are built the compiler will probably have to do a fair amount of name deduplication anyway, which is relatively expensive. It's definitely better than nothing though!
[Bug target/120215] [16 Regression] FAIL: gcc.target/i386/pr78794.c scan-assembler pandn by r16-517-g993aa0bd28722c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120215 --- Comment #2 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:f0d36c822c8b0918583c6bc3b1db01f2bb7f226b commit r16-619-gf0d36c822c8b0918583c6bc3b1db01f2bb7f226b Author: liuhongt Date: Tue Dec 17 22:32:31 2024 -0800 Consider frequency in cost estimation when converting scalar to vector. n some benchmark, I notice stv failed due to cost unprofitable, but the igain is inside the loop, but sse<->integer conversion is outside the loop, current cost model doesn't consider the frequency of those gain/cost. The patch weights those cost with frequency. gcc/ChangeLog: PR target/120215 * config/i386/i386-features.cc (scalar_chain::mark_dual_mode_def): Weight cost of integer<->sse move with bb frequency when it's optimized_for_speed_p. (general_scalar_chain::compute_convert_gain): Ditto, and adjust function prototype to return true/false when cost model is profitable or not. (timode_scalar_chain::compute_convert_gain): Ditto. (convert_scalars_to_vector): Adjust after the upper two function prototype are changed. * config/i386/i386-features.h (class scalar_chain): Change n_integer_to_sse/n_sse_to_integer to cost_sse_integer, and add weighted_cost_sse_integer. (class general_scalar_chain): Adjust prototype to return bool intead of int. (class timode_scalar_chain): Ditto.
[Bug target/120215] [16 Regression] FAIL: gcc.target/i386/pr78794.c scan-assembler pandn by r16-517-g993aa0bd28722c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120215 Hongtao Liu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hongtao Liu --- Fixed.
[Bug libstdc++/119125] [C++26] Implement P2548R6 copyable_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119125 Tomasz Kamiński changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |16.0 --- Comment #4 from Tomasz Kamiński --- Implemented in GCC 16.
[Bug libstdc++/119125] [C++26] Implement P2548R6 copyable_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119125 --- Comment #3 from GCC Commits --- The master branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:d9055d010475fa1c624d6036881eee9c37034b21 commit r16-620-gd9055d010475fa1c624d6036881eee9c37034b21 Author: Tomasz KamiÅski Date: Mon May 12 11:06:34 2025 +0200 libstdc++: Renamed bits/move_only_function.h to bits/funcwrap.h [PR119125] The file now includes copyable_function in addition to move_only_function. PR libstdc++/119125 libstdc++-v3/ChangeLog: * include/bits/move_only_function.h: Move to... * include/bits/funcwrap.h: ...here. * doc/doxygen/stdheader.cc (init_map): Replaced move_only_function.h with funcwrap.h, and changed include guard to use feature test macro. Move bits/version.h include before others. * include/Makefile.am: Likewise. * include/Makefile.in: Likewise. * include/std/functional: Likewise. Reviewed-by: Patrick Palka Reviewed-by: Jonathan Wakely Signed-off-by: Tomasz KamiÅski
[Bug libstdc++/120266] newly introduced problems when using lto'ed libstdc++-v3 in a static link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120266 --- Comment #6 from Quentin Boswank --- Why does LTO even exists when I can use it to its full potential. I might not use it like this. /rant
[Bug libstdc++/110339] Implement C++26 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 Bug 110339 depends on bug 119125, which changed state. Bug 119125 Summary: [C++26] Implement P2548R6 copyable_function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119125 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/120277] [16 Regression] Crash at -O2: in upper_bound, at value-range.h:1181
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120277 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Last reconfirmed||2025-05-14 Summary|Crash at -O2: in|[16 Regression] Crash at |upper_bound, at |-O2: in upper_bound, at |value-range.h:1181 |value-range.h:1181 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |16.0 Component|c |tree-optimization --- Comment #1 from Richard Biener --- Confirmed, quite recent regression.
[Bug libstdc++/120259] Using Incomplete&& as argument in invoke_r/move_only_function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120259 --- Comment #1 from Tomasz Kamiński --- We should use _Arg&& in is_invokable checks here: ``` template constexpr enable_if_t, _Res> __invoke_r(_Callable&& __fn, _Args&&... __args) noexcept(is_nothrow_invocable_r_v<_Res, _Callable, _Args...>); ```
[Bug c++/118775] [12/13/14 Regression] ICE in tree_to_uhwi with unique_ptr and addresss of var converted to an integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118775 --- Comment #9 from Marek Polacek --- On it now.
[Bug libstdc++/117905] PSTL algos in require copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117905 --- Comment #3 from Jonathan Wakely --- As noted at https://github.com/oneapi-src/oneDPL/issues/1955 the standard has some defects regarding the requirements for these numeric algos. It's necessary to assume some additional requirements such as Cpp17MoveAssignable, as proposed in https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0571r2.html
[Bug fortran/120225] [F2023] Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120225 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tobias Burnus --- FIXED in GCC 16 mainline. Crossref: * PR120237 - update /intrastructure + contrib/download_prerequisites to 4.2.x * PR113152 - for sinpi (etc.; half-cycle trigonometric functions)
[Bug fortran/120225] [F2023] Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120225 Sam James changed: What|Removed |Added Target Milestone|--- |16.0
[Bug tree-optimization/120268] Missed removing loop of setting zero when dereference pointer (memset) at -O3 -fallow-store-data-races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120268 --- Comment #3 from Richard Biener --- phiopt, where CSELIM is done might be the place to put this into. We might want to try simplifying the COND_EXPR ptr[i] != 0 ? 0 : ptr[i].
[Bug c++/120272] [13/14/15/16 Regression] ICE in get_local_decls, at cp/name-lookup.c:4594 since 13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120272 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/120276] New: [16 Regression] ICE in partial_subreg_p with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120276
Bug ID: 120276
Summary: [16 Regression] ICE in partial_subreg_p with SVE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: aarch64-sve, ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
int a;
char b[1];
int c[18];
void d(char *);
void e() {
int f;
char *g;
a = 0;
for (; a < 18; a++) {
int h = f = 0;
for (; f < 4; f++) {
g[a * 4 + f] = c[a] >> h;
h += 8;
}
}
d(b);
}
ICEs on aarch64 with e.g. -O3 -march=armv8.2-a+sve
during RTL pass: cprop_hardreg
ice.c: In function ‘e’:
ice.c:17:1: internal compiler error: in partial_subreg_p, at rtl.h:3203
17 | }
| ^
0x239032b internal_error(char const*, ...)
$SRC/gcc/diagnostic-global-context.cc:517
0x8282ff fancy_abort(char const*, int, char const*)
$SRC/gcc/diagnostic.cc:1815
0x806df3 partial_subreg_p(machine_mode, machine_mode)
$SRC/gcc/rtl.h:3203
0xf8e807 partial_subreg_p(machine_mode, machine_mode)
$SRC/gcc/poly-int.h:1365
0xf8e807 copy_value
$SRC/gcc/regcprop.cc:374
0xf8eff3 copyprop_hardreg_forward_1
$SRC/gcc/regcprop.cc:1153
0xf8f9d3 execute
$SRC/gcc/regcprop.cc:1423
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++/119246] Result basic_format_arg::check_dynamic_spec is incorrect for extended floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119246 --- Comment #3 from GCC Commits --- The master branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:9c9a7316adb99693e237164908893a78b86ba000 commit r16-616-g9c9a7316adb99693e237164908893a78b86ba000 Author: Tomasz KamiÅski Date: Wed Apr 30 10:37:48 2025 +0200 libstdc++: Preserve the argument type in basic_format_args [PR119246] This commits adjust the way how the arguments are stored in the _Arg_value (and thus basic_format_args), by preserving the types of fixed width floating-point types, that were previously converted to float, double, long double. The _Arg_value union now contains alternatives with std::bfloat16_t, std::float16_t, std::float32_t, std::float64_t that use pre-existing _Arg_bf16, _Arg_f16, _Arg_f32, _Arg_f32 argument types. This does not affect formatting, as specialization of formatters for fixed width floating-point types formats them by casting to the corresponding standard floating point type. For the 128bit floating we need to handle the ppc64 architecture, (_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT) for which the long double may (per TU basis) designate either __ibm128 and __ieee128 type, we need to store both types in the _Arg_value and have two _Arg_types (_Arg_ibm128, _Arg_ieee128). On other architectures we use extra enumerator value to store __float128, that is different from long double and _Float128. This is consistent with ppc64, for which __float128, if present, is same type as __ieee128. We use _Arg_float128 _M_float128 names that deviate from _Arg_fN naming scheme, to emphasize that this flag is not used for std::float128_t (_Float128) type, that is consistenly formatted via handle. The __format::__float128_t type is renamed to __format::__flt128_t, to mitigate visual confusion between this type and __float128. We also introduce __bflt16_t typedef instead of using of decltype. We add new alternative for the _Arg_value and allow them to be accessed via _S_get, when the types are available. However, we produce and handle corresponding _Arg_type, only when we can format them. See also r14-3329-g27d0cfcb2b33de. The formatter<_Float128, _CharT> that formats via __format::__flt128_t is always provided, when type is available. It is still correct when __format::__flt128_t is _Float128. We also provide formatter<__float128, _CharT> that formats via __flt128_t. As this type may be disabled (-mno-float128), extra care needs to be taken, for situation when __float128 is same as long double. If the formatter would be defined in such case, the formatter would be generated from different specializations, and have different mangling: * formatter<__float128, _CharT> if __float128 is present, * formatter<__format::__formattable_float, _CharT> otherwise. To best of my knowledge this happens only on ppc64 for __ieee128 and __float128, so the formatter is not defined in this case. static_assert is added to detect other configurations like that. In such case we should replace it with constraint. PR libstdc++/119246 libstdc++-v3/ChangeLog: * include/std/format (__format::__bflt16_t): Define. (_GLIBCXX_FORMAT_F128): Separate value for cases where _Float128 is used. (__format::__float128_t): Renamed to __format::__flt128_t. (std::formatter<_Float128, _CharT>): Define always if there is formattable 128bit float. (std::formatter<__float128, _CharT>): Define. (_Arg_type::_Arg_f128): Rename to _Arg_float128 and adjust value. (_Arg_type::_Arg_ibm128): Change value to _Arg_ldbl. (_Arg_type::_Arg_ieee128): Define as alias to _Arg_float128. (_Arg_value::_M_f128): Replaced with _M_ieee128 and _M_float128. (_Arg_value::_M_ieee128, _Arg_value::_M_float128) (_Arg_value::_M_bf16, _Arg_value::_M_f16, _Arg_value::_M_f32) (_Arg_value::_M_f64): Define. (_Arg_value::_S_get, basic_format_arg::_S_to_enum): Handle __bflt16, _Float16, _Float32, _Float64, and __float128 types. (basic_format_arg::_S_to_arg_type): Preserve _bflt16, _Float16, _Float32, _Float64 and __float128 types. (basic_format_arg::_M_visit): Handle _Arg_float128, _Arg_ieee128, _Arg_b16, _Arg_f16, _Arg_f32, _Arg_f64. * testsuite/std/format/arguments/args.cc: Updated to illustrate that extended floating point types use handles now. Added test for __float128. * testsuite/std/format/parse_ctx.cc: Extended test to cover class to check_dynamic_spec with floating point types and handles. Reviewed-by: Jonathan Wakely Signed-off-by: Tomasz KamiÅski
[Bug c++/118245] [14 Regression] ICE: in convert_nontype_argument, Passing a lambda as a template argument and base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118245 --- Comment #12 from Nathaniel Shead --- (In reply to Richard Biener from comment #11) > (In reply to Nathaniel Shead from comment #10) > > This is fixed for GCC 15. Unfortunately this patch isn't appropriate for > > backporting as it will cause ABI changes without also backporting the fix > > for PR107741 (r15-7147-g685c458fb4775c). > > > > Instead I'll probably end up reverting the changes to parser.cc in > > r14-9232-g3685fae23bb008 since the modules testcases are less important, > > unless I can find a way to fix it while keeping the existing ABI behaviour. > > Did you get to this? Ah no, I'd forgotten. I've just sent https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683617.html with a candidate patch for the reversion.
[Bug libstdc++/119246] Result basic_format_arg::check_dynamic_spec is incorrect for extended floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119246 Tomasz Kamiński changed: What|Removed |Added Target Milestone|--- |16.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tomasz Kamiński --- Fixed in gcc 16.
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Bug 88322 depends on bug 119246, which changed state. Bug 119246 Summary: Result basic_format_arg::check_dynamic_spec is incorrect for extended floating point types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119246 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/111814] [SH] __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814 --- Comment #11 from Oleg Endo --- Is there anything that needs to be addressed for this one?
[Bug tree-optimization/111873] [12/13/14/15/16 Regression] runtime Segmentation fault with '-O3 -fno-code-hoisting -fno-early-inlining -fno-tree-fre -fno-tree-pre' since r12-434-g93f8cb4965cebe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111873 --- Comment #18 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:9d039eff453f777c58642ff16178c1ce2a4be6ab commit r16-614-g9d039eff453f777c58642ff16178c1ce2a4be6ab Author: Martin Jambor Date: Wed May 14 12:08:24 2025 +0200 tree-sra: Do not create stores into const aggregates (PR111873) This patch fixes (hopefully the) one remaining place where gimple SRA was still creating a load into const aggregates. It occurs when there is a replacement for a load but that replacement is not type compatible - typically because it is a single field structure. I have used testcases from duplicates because the original test-case no longer reproduces for me. gcc/ChangeLog: 2025-05-13 Martin Jambor PR tree-optimization/111873 * tree-sra.cc (sra_modify_expr): When processing a load which has a type-incompatible replacement, do not store the contents of the replacement into the original aggregate when that aggregate is const. gcc/testsuite/ChangeLog: 2025-05-13 Martin Jambor * gcc.dg/ipa/pr120044-1.c: New test. * gcc.dg/ipa/pr120044-2.c: Likewise. * gcc.dg/tree-ssa/pr114864.c: Likewise.
[Bug middle-end/120276] [16 Regression] ICE in partial_subreg_p with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120276 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||jschmitz at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- Bisection points to g:210d06502f22964c7214586c54f8eb54a6965bfd
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 120125, which changed state. Bug 120125 Summary: [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 Nathaniel Shead changed: What|Removed |Added Target Milestone|15.0|15.2 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nathaniel Shead --- Fixed on 15.2 and trunk, and ensured this keeps working for 14.3; thanks for the report!
[Bug middle-end/120276] [16 Regression] ICE in partial_subreg_p with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120276 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Had a quick look. The ICE through regcprop comes in partial_subreg_p: /* Modes involved in a subreg must be ordered. In particular, we must always know at compile time whether the subreg is paradoxical. */ poly_int64 outer_prec = GET_MODE_PRECISION (outermode); poly_int64 inner_prec = GET_MODE_PRECISION (innermode); gcc_checking_assert (ordered_p (outer_prec, inner_prec)); Where the two modes are VNx4QI and V8QI. The regcprop code that calls this is: /* If a narrower value is copied using wider mode, the upper bits are undefined (could be e.g. a former paradoxical subreg). Signal in that case we've only copied value using the narrower mode. Consider: (set (reg:DI r14) (mem:DI ...)) (set (reg:QI si) (reg:QI r14)) (set (reg:DI bp) (reg:DI r14)) (set (reg:DI r14) (const_int ...)) (set (reg:DI dx) (reg:DI si)) (set (reg:DI si) (const_int ...)) (set (reg:DI dx) (reg:DI bp)) The last set is not redundant, while the low 8 bits of dx are already equal to low 8 bits of bp, the other bits are undefined. */ else if (partial_subreg_p (vd->e[sr].mode, GET_MODE (src))) I'm not super familiar with that pass, but could it be that we need another check on the modes before calling partial_subreg_p here or maybe do some other comparison between the modes?
[Bug c++/118775] [12/13/14 Regression] ICE in tree_to_uhwi with unique_ptr and addresss of var converted to an integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118775 --- Comment #10 from GCC Commits --- The releases/gcc-14 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:97121b135530b15bc7d1b9e24daa566d9b0473b0 commit r14-11776-g97121b135530b15bc7d1b9e24daa566d9b0473b0 Author: Marek Polacek Date: Tue Feb 11 15:43:40 2025 -0500 c++: ICE with operator new[] in constexpr [PR118775] Here we ICE since r11-7740 because we no longer say that (long)&a (where a is a global var) is non_constant_p. So VERIFY_CONSTANT does not return and we crash on tree_to_uhwi. We should check tree_fits_uhwi_p before calling tree_to_uhwi. PR c++/118775 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_call_expression): Check tree_fits_uhwi_p. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constexpr-new24.C: New test. * g++.dg/cpp2a/constexpr-new25.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit aa55a6a30bc4778938af42dac9b624cf67fa4698)
[Bug c++/119303] [12/13/14 Regression] ICE: error reporting routines re-entered. in warning_at (diagnostic-global-context.cc:185)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119303
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:9ce96b683a40a12299c1d0e02727e747c00ad883
commit r14-11777-g9ce96b683a40a12299c1d0e02727e747c00ad883
Author: Marek Polacek
Date: Wed May 14 10:34:44 2025 -0400
c++: fix reporting routines re-entered [PR119303]
We crash while we call warning_at ("inline function used but never
defined")
since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
... -> c_common_truthvalue_conversion -> warning_at ("enum constant in
boolean
context")
cp_truthvalue_conversion correctly gets complain=0 but it calls
c_common_truthvalue_conversion from c-family which doesn't have
a similar parameter.
We can fix this by tweaking diagnostic_context::report_diagnostic to
check for recursion after checking if the diagnostic was enabled.
PR c++/116960
PR c++/119303
gcc/ChangeLog:
* diagnostic.cc (diagnostic_context::report_diagnostic): Check for
non-zero m_lock later, after checking diagnostic_enabled.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval26.C: New test.
* g++.dg/warn/undefined2.C: New test.
Reviewed-by: Jason Merrill
[Bug c++/116960] ICE: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116960
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:9ce96b683a40a12299c1d0e02727e747c00ad883
commit r14-11777-g9ce96b683a40a12299c1d0e02727e747c00ad883
Author: Marek Polacek
Date: Wed May 14 10:34:44 2025 -0400
c++: fix reporting routines re-entered [PR119303]
We crash while we call warning_at ("inline function used but never
defined")
since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
... -> c_common_truthvalue_conversion -> warning_at ("enum constant in
boolean
context")
cp_truthvalue_conversion correctly gets complain=0 but it calls
c_common_truthvalue_conversion from c-family which doesn't have
a similar parameter.
We can fix this by tweaking diagnostic_context::report_diagnostic to
check for recursion after checking if the diagnostic was enabled.
PR c++/116960
PR c++/119303
gcc/ChangeLog:
* diagnostic.cc (diagnostic_context::report_diagnostic): Check for
non-zero m_lock later, after checking diagnostic_enabled.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval26.C: New test.
* g++.dg/warn/undefined2.C: New test.
Reviewed-by: Jason Merrill
[Bug c++/117778] [14 Regression] ICE maybe_add_lambda_conv_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117778
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:52202e42919d0d95c13889bed9e69b954e4376af
commit r14-11778-g52202e42919d0d95c13889bed9e69b954e4376af
Author: Marek Polacek
Date: Wed Jan 29 15:58:38 2025 -0500
c++: auto in trailing-return-type in parameter [PR117778]
This PR describes a few issues, both ICE and rejects-valid, but
ultimately the problem is that we don't properly synthesize the
second auto in:
int
g (auto fp() -> auto)
{
return fp ();
}
since r12-5860, which disabled auto_is_implicit_function_template_parm_p
in cp_parser_parameter_declaration after parsing the decl-specifier-seq.
If there is no trailing auto, there is no problem.
So we have to make sure auto_is_implicit_function_template_parm_p is
properly set when parsing the trailing auto. A complication is that
one can write:
auto f (auto fp(auto fp2() -> auto) -> auto) -> auto;
~~~
where only the underlined auto should be synthesized. So when we
parse a parameter-declaration-clause inside another
parameter-declaration-clause, we should not enable the flag. We
have no flags to keep track of such nesting, but I think I can walk
current_binding_level to see if we find ourselves in such an unlikely
scenario.
PR c++/117778
gcc/cp/ChangeLog:
* parser.cc (cp_parser_late_return_type_opt): Maybe override
auto_is_implicit_function_template_parm_p.
(cp_parser_parameter_declaration): Move a make_temp_override below.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/lambda-generic-117778.C: New test.
* g++.dg/cpp2a/abbrev-fn2.C: New test.
* g++.dg/cpp2a/abbrev-fn3.C: New test.
Reviewed-by: Jason Merrill
(cherry picked from commit e6e40cb7459c9b21b291fe28e46cd4ebcd924dff)
[Bug c++/117778] [14 Regression] ICE maybe_add_lambda_conv_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117778 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Marek Polacek --- Fixed.
[Bug c++/117501] [14 Regression] Consteval constructor does not initialize the variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117501 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Marek Polacek --- Fixed.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 117501, which changed state. Bug 117501 Summary: [14 Regression] Consteval constructor does not initialize the variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117501 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/116379] [12/13/14 Regression] Type deduction error on decltype(auto) of parenthesized non-static data member since r12-5778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116379
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:c11cb308c1e2aae427d6f32a1144ae8907dc2649
commit r14-11780-gc11cb308c1e2aae427d6f32a1144ae8907dc2649
Author: Marek Polacek
Date: Wed May 14 10:40:54 2025 -0400
c++: fix propagating REF_PARENTHESIZED_P [PR116379]
Here we have:
template
struct X{
T val;
decltype(auto) value(){
return (val);
}
};
where the return type of value should be 'int &' since '(val)' is an
expression, not a name, and decltype(auto) performs the type deduction
using the decltype rules.
The problem is that we weren't propagating REF_PARENTHESIZED_P
correctly: the return value of finish_non_static_data_member in this
test was a REFERENCE_REF_P, so we didn't set the flag. We should
use force_paren_expr like below.
PR c++/116379
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr) : Use force_paren_expr to set
REF_PARENTHESIZED_P.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/decltype-auto9.C: New test.
Reviewed-by: Jason Merrill
[Bug libstdc++/120266] newly introduced problems when using lto'ed libstdc++-v3 in a static link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120266 --- Comment #7 from Jonathan Wakely --- You can use it for all your own code, and and other libraries you rely on, you just can't build libstdc++.a with LTO. Last I heard, the same is true for glibc. But sure, if you think it's not worth using it if it can't be used on every part of the whole program, don't use it. In fact, maybe you should just use -O0 for everything. Why bother optimizing at all.
[Bug target/110812] Check availability of builtins at expand time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812 --- Comment #10 from Andreas Schwab --- That doesn't fix anything. https://build.opensuse.org/project/monitor/home:Andreas_Schwab:riscv:gcc
[Bug c/112556] Null pointer constants with enumeration type are not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112556 --- Comment #11 from GCC Commits --- The releases/gcc-14 branch has been updated by Sam James : https://gcc.gnu.org/g:05db28033e4377466bb19f317e67ed91b92fd4a9 commit r14-11782-g05db28033e4377466bb19f317e67ed91b92fd4a9 Author: Joseph Myers Date: Mon Nov 18 22:24:48 2024 + c: Allow bool and enum null pointer constants [PR112556] As reported in bug 112556, GCC wrongly rejects conversion of null pointer constants with bool or enum type to pointers in convert_for_assignment (assignment, initialization, argument passing, return). Fix the code there to allow BOOLEAN_TYPE and ENUMERAL_TYPE; it already allowed INTEGER_TYPE and BITINT_TYPE. This bug (together with -std=gnu23 meaning false has type bool rather than int) has in turn resulted in people thinking they need to fix code using false as a null pointer constant for C23 compatibility. While such a usage is certainly questionable, it has nothing to do with C23 compatibility and the right place for warnings about such usage is -Wzero-as-null-pointer-constant. I think it would be appropriate to extend -Wzero-as-null-pointer-constant to cover BOOLEAN_TYPE, ENUMERAL_TYPE and BITINT_TYPE (in all the various contexts in which that option generates warnings), though this patch doesn't do anything about that option. Bootstrapped with no regressions for x86-64-pc-linux-gnu. PR c/112556 gcc/c/ * c-typeck.cc (convert_for_assignment): Allow conversion of ENUMERAL_TYPE and BOOLEAN_TYPE null pointer constants to pointers. gcc/testsuite/ * gcc.dg/c11-null-pointer-constant-1.c, gcc.dg/c23-null-pointer-constant-1.c: New tests. (cherry picked from commit 3d525fce70fa0ffa0b22af6e213643e1ceca5ab5)
[Bug tree-optimization/120206] Removal of forward_propagate_into_gimple_cond/forward_propagate_into_comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120206
--- Comment #4 from Andrew Pinski ---
With this patch (and the match part of the patch attached):
```
[apinski@xeond2 gcc]$ git diff
diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
index 3187314390f..741d62135ac 100644
--- a/gcc/tree-ssa-forwprop.cc
+++ b/gcc/tree-ssa-forwprop.cc
@@ -523,6 +523,7 @@ forward_propagate_into_comparison (gimple_stmt_iterator
*gsi)
type, rhs1, rhs2);
if (tmp && useless_type_conversion_p (type, TREE_TYPE (tmp)))
{
+ gcc_unreachable ();
gimple_assign_set_rhs_from_tree (gsi, tmp);
fold_stmt (gsi);
update_stmt (gsi_stmt (*gsi));
@@ -560,6 +561,7 @@ forward_propagate_into_gimple_cond (gcond *stmt)
if (tmp
&& is_gimple_condexpr_for_cond (tmp))
{
+ gcc_unreachable ();
if (dump_file)
{
fprintf (dump_file, " Replaced '");
```
We get these failures:
```
FAIL: gcc.dg/tree-ssa/asmgoto-1.c (internal compiler error: in
forward_propagate_into_gimple_cond, at tree-ssa-forwprop.cc:564)
FAIL: gcc.dg/tree-ssa/asmgoto-1.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/log_exp.c (internal compiler error: in
forward_propagate_into_gimple_cond, at tree-ssa-forwprop.cc:564)
FAIL: gcc.dg/tree-ssa/log_exp.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/operand-equal-2.c (internal compiler error: in
forward_propagate_into_comparison, at tree-ssa-forwprop.cc:526)
FAIL: gcc.dg/tree-ssa/operand-equal-2.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/pr20139.c (internal compiler error: in
forward_propagate_into_gimple_cond, at tree-ssa-forwprop.cc:564)
FAIL: gcc.dg/tree-ssa/pr20139.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/pr81627.c scan-tree-dump-times pcom "Store-stores chain"
1
FAIL: gcc.dg/tree-ssa/ranger-threader-3.c (internal compiler error: in
forward_propagate_into_comparison, at tree-ssa-forwprop.cc:526)
FAIL: gcc.dg/tree-ssa/ranger-threader-3.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/split-path-3.c (internal compiler error: in
forward_propagate_into_comparison, at tree-ssa-forwprop.cc:526)
FAIL: gcc.dg/tree-ssa/split-path-3.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ssa-dom-thread-14.c (internal compiler error: in
forward_propagate_into_comparison, at tree-ssa-forwprop.cc:526)
FAIL: gcc.dg/tree-ssa/ssa-dom-thread-14.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ssa-sink-18.c (internal compiler error: in
forward_propagate_into_gimple_cond, at tree-ssa-forwprop.cc:564)
FAIL: gcc.dg/tree-ssa/ssa-sink-18.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/vrp12.c (internal compiler error: in
forward_propagate_into_gimple_cond, at tree-ssa-forwprop.cc:564)
FAIL: gcc.dg/tree-ssa/vrp12.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/vrp60.c (internal compiler error: in
forward_propagate_into_gimple_cond, at tree-ssa-forwprop.cc:564)
FAIL: gcc.dg/tree-ssa/vrp60.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/vrp89.c (internal compiler error: in
forward_propagate_into_gimple_cond, at tree-ssa-forwprop.cc:564)
FAIL: gcc.dg/tree-ssa/vrp89.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/vrp93.c (internal compiler error: in
forward_propagate_into_gimple_cond, at tree-ssa-forwprop.cc:564)
FAIL: gcc.dg/tree-ssa/vrp93.c (test for excess errors)
```
gcc.dg/tree-ssa/vrp12.c:
`ABS < 0` not being folded by gimple.
I will have to look at each other one seperately maybe tomorrow.
[Bug tree-optimization/120280] New: ABS < 0 is not optimized to false by match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120280
Bug ID: 120280
Summary: ABS < 0 is not optimized to false by match
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 120206
Target Milestone: ---
Take:
```
int g(int);
int f(int a)
{
int b = __builtin_abs (a);
return g(b < 0);
}
```
This should have been optimized in CCP1 to just `return g(0);` But it is not
until forwprop1 we are able to optimize it (using fold rather than match):
```
gimple_simplified to _2 = 0;
Removing dead stmt:_1 = 0;
Removing dead stmt:_2 = 0;
```
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120206
[Bug 120206] Removal of
forward_propagate_into_gimple_cond/forward_propagate_into_comparison
[Bug tree-optimization/120280] ABS < 0 is not optimized to false by match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120280 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-14 Version|14.0|16.0 --- Comment #1 from Andrew Pinski --- Noticed via PR 120206 (gcc.dg/tree-ssa/vrp12.c).
[Bug fortran/85750] [12/13/14/15/16 Regression] Default initialization of derived type array missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85750 anlauf at gcc dot gnu.org changed: What|Removed |Added CC|anlauf at gmx dot de |anlauf at gcc dot gnu.org --- Comment #13 from anlauf at gcc dot gnu.org --- I have a candidate patch that slightly rearranges the logic when the default initialization is applied. It is currently regtesting, but it is already clear that there will be a couple of testcases that need adjusting the patterns of tree-dump scans (mostly: __builtin_malloc), and removal of some bogus warnings.
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 --- Comment #18 from James K. Lowden --- The logic slated for obliteration is in symbol_declaratives_add() and anything associated with it. That was the old way -- now weeks and weeks outdated -- to move declarative descriptors to the library. It was eliminated because it was too embarrassing to document. Chalk up one for documentation. That code creates a COBOL variable based on a host array. It's totally portable if host == target. :-/ And, yes, padding bytes will be copied and will be different from time to time, that being their Heisenberg nature. The good news is that the created variable is no longer used by the library. What remains is to remove it from the compiler. That's not hard, but is harder than it looks. The new logic relies on a target array, and does not copy structures or their padding bytes. How soon the cleanup is finished depends on what gets done first, but by end of May is a safe bet.
[Bug testsuite/120251] cobol tests depend on locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120251 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org --- Comment #2 from James K. Lowden --- These tests have output that depends on locale. That is as it should be: "Hur mår du?" is represented using different bytes in different encodings, and the best indication we have of the "right" encoding is the current locale. What to do about the test? Since the test output is in UTF-8, my preference would be to ensure the test runs with LANG=C.UTF-8 in the environment. We could also skip the test if the current environment isn't UTF-8. For tests that aren't specifically about DISPLAY, we could also change the test not to depend on the output of a DISPLAY statement. I haven't tried to figure out how to set the locale for a test. I thought I'd start by asking what is wanted.
[Bug c++/120281] New: -Warray-bounds produces an incorrect warning when compiled with -O3 and --coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120281
Bug ID: 120281
Summary: -Warray-bounds produces an incorrect warning when
compiled with -O3 and --coverage
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominick.allen1989 at gmail dot com
Target Milestone: ---
Created attachment 61425
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61425&action=edit
Original bug.cpp, preprocessed file, and cvise reduction of preprocessed fille.
I encountered this on gentoo, on AMD64, with gcc 14.2. I have included
additional details about my version of gcc at the bottom of this post.
I have attached report.tar.gz, which provides bug.cpp (what I consider a
minimal reproducing example), bug.ii.orig which is a preprocessed version of
bug.cpp, bug.ii which is the output of cvise having run the reduce.sh script
also present in the archive. The gcc_info.txt file provides the output of the
command `g++ -v -save-temps -std=c++20 -Werror -Warray-bounds -O3 --coverage
bug.cpp 2>&1 | tee gcc_info.txt`. I have also included the file outputs from
that command, a-bug.ii and a-bug.s.
When compiling my original minimal case (https://godbolt.org/z/4Mb795ch3), I
get the following error when using -std=c++20 -O3 -Werror -Warray-bounds
--coverage.
```
libfud@localhost ~/Documents/bug_reports/cstr_warray_bounds $ make
g++ bug.cpp -std=c++20 -Werror -Warray-bounds -O3 --coverage -o bug
In function ‘constexpr Result
cStringLengthImpl(const T*, size_t) [with T = char]’,
inlined from ‘constexpr Result
cStringLength(const char*, size_t)’ at bug.cpp:141:44,
inlined from ‘constexpr Result
cStringLength(const char*)’ at bug.cpp:146:47,
inlined from ‘int main()’ at bug.cpp:150:20:
bug.cpp:132:12: error: array subscript -2 is outside array bounds of ‘const
char [2]’ [-Werror=array-bounds=]
132 | if (str[size] != 0 && size == maxLength) {
| ~~~^
cc1plus: all warnings being treated as errors
make: *** [Makefile:5: bug] Error 1
```
Removing the --coverage flag, or uncommenting lines 124 and 130 in the attached
bug.cpp, makes the warning go away. This behavior is also replicable on godbolt
with (all x86-64) gcc 15.1, gcc 13.3, and gcc 12.4. It does not happen with gcc
11.4.
System information:
gcc (Gentoo 14.2.1_p20241221 p7) 14.2.1 20241221
sys-devel/gcc-14.2.1_p20241221:14::gentoo USE="cet (cxx)
(default-stack-clash-protection) (default-znow) fortran jit (multilib) nls
openmp (pie) sanitize ssp zstd -ada (-custom-cflags) -d -debug -doc
(-fixed-point) -go -graphite -hardened (-ieee-long-double) (-libssp) -lto
-modula2 -objc -objc++ -objc-gc (-pch) -pgo -rust -systemtap -test (-time64)
-valgrind -vanilla -vtv"
