[Bug tree-optimization/118430] [14 Regression] tail call vs IPA-VRP return value range with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430 Jakub Jelinek changed: What|Removed |Added Summary|[14/15 Regression] tail |[14 Regression] tail call |call vs IPA-VRP return |vs IPA-VRP return value |value range with constant |range with constant value |value | --- Comment #14 from Jakub Jelinek --- Fixed on the trunk. Not sure about the backport, it is less important in 14 because there is no musttail and the patch is a new optimization which can e.g. introduce tail calls where they weren't before.
[Bug tree-optimization/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505 --- Comment #8 from Dhruv Chawla --- (In reply to Andrew Pinski from comment #7) > I do have to wonder if splitting the path here helps because the condition > (a[i] > 0.) Is predictable. > > I can't think it would be predictable but maybe on accident the predictor > get it right 50% of the time, we can keep the pipeline full. > > I have to think of a good heuristic for that too. I think you're right, looking at the initialization code in common.c:415 shows that "a" is always set to positive numbers, so I think only one path is ever taken.
[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494 --- Comment #15 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ea1deefe54ea1c5182bfa179abf36469c9ec6974 commit r15-6945-gea1deefe54ea1c5182bfa179abf36469c9ec6974 Author: Richard Biener Date: Wed Jan 15 14:31:57 2025 +0100 tree-optimization/115494 - PRE PHI translation and ranges When we PHI translate dependent expressions we keep SSA defs in place of the translated expression in case the expression itself did not change even though it's context did and thus the validity of ranges associated with it. That eventually leads to simplification errors given we violate the precondition that used SSA defs fed to vn_valueize are valid to use (including their associated ranges). The following makes sure to replace those with new representatives always, not only when the dependent expression translation changed it. The fix was originally discovered by Michael Morin. PR tree-optimization/115494 * tree-ssa-pre.cc (phi_translate_1): Always generate a representative for translated dependent expressions. * gcc.dg/torture/pr115494.c: New testcase. Co-Authored-By: Mikael Morin
[Bug tree-optimization/115494] [14 Regression] wrong code at -O{2, 3} on x86_64-linux-gnu since r14-3485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Summary|[14/15 Regression] wrong|[14 Regression] wrong code
|code at -O{2,3} on |at -O{2,3} on
|x86_64-linux-gnu since |x86_64-linux-gnu since
|r14-3485|r14-3485
--- Comment #16 from Richard Biener ---
Fixed for GCC 15, I'm not sure how far to backport - I'm watching for fallout.
[Bug c++/118507] New: Erroneous 'invalid use of qualified-name' for member function defined with 'typedef' in a friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118507
Bug ID: 118507
Summary: Erroneous 'invalid use of qualified-name' for member
function defined with 'typedef' in a friend
declaration
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
The following code fails in the process of name lookup:
~~~
typedef void X();
class a
{
public:
X x;
};
class b
{
friend X a::x;
};
~~~
GCC rejects it with:
~~~
:10:13: error: invalid use of qualified-name 'a::x'
10 |friend X a::x;
| ^
~~~
Note that clang, MSVC and EDG can normally accept it:
https://godbolt.org/z/WvKaKbM33
[Bug c++/118509] Front-end produced uninitialized memory reference when compiling Nektar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509 Andrew Pinski changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |15.0 Keywords||needs-reduction, wrong-code
[Bug c++/118509] [14/15 regression] Front-end produced uninitialized memory reference when compiling Nektar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509 Andrew Pinski changed: What|Removed |Added Known to work||14.2.0 Summary|Front-end produced |[14/15 regression] |uninitialized memory|Front-end produced |reference when compiling|uninitialized memory |Nektar |reference when compiling ||Nektar Target Milestone|15.0|14.4 Known to fail||14.2.1, 15.0
[Bug c++/118509] [14/15 regression] Front-end produced uninitialized memory reference when compiling Nektar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509 Andrew Pinski changed: What|Removed |Added Target Milestone|14.4|14.3
[Bug c++/118509] [14/15 regression] Front-end produced uninitialized memory reference when compiling Nektar since r15-4595-gb25d3201b6338d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509 Sam James changed: What|Removed |Added Summary|[14/15 regression] |[14/15 regression] |Front-end produced |Front-end produced |uninitialized memory|uninitialized memory |reference when compiling|reference when compiling |Nektar |Nektar since ||r15-4595-gb25d3201b6338d CC||jakub at gcc dot gnu.org --- Comment #1 from Sam James --- (In reply to Di Zhao from comment #0) > The bug is exposed after commit b25d3201 (gcc-15), r15-4595-gb25d3201b6338d
[Bug target/118510] New: [15 Regression][x86] ICE in extract_insn, at recog.cc:2869 with -mapxf since r15-5635-g1ff69000b50e8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118510
Bug ID: 118510
Summary: [15 Regression][x86] ICE in extract_insn, at
recog.cc:2869 with -mapxf since
r15-5635-g1ff69000b50e8a
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at gcc dot gnu.org
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: x86_64
Compiling reduced testcase gcc.dg/ipa/20040703-wpa.c results in ICE since
r15-5635-g1ff69000b50e8a.
$ cat 20040703-wpa.c
typedef struct cpp_num cpp_num;
struct cpp_num {
int high;
unsigned low;
int overflow;
};
int num_rshift_n;
cpp_num num_lshift(cpp_num num) {
num.low = num.low >> num_rshift_n | num.high << (32 - num_rshift_n);
return num;
}
$ gcc 20040703-wpa.c -mapxf -O2
20040703-wpa.c: In function ‘num_lshift’:
20040703-wpa.c:11:1: error: unrecognizable insn:
11 | }
| ^
(insn 39 38 16 2 (parallel [
(set (reg:SI 124)
(ior:SI (lshiftrt:SI (reg:SI 120)
(and:QI (subreg:QI (reg:SI 98 [ num_rshift_n.0_1 ]) 0)
(const_int 31 [0x1f])))
(subreg:SI (ashift:DI (zero_extend:DI (subreg:SI (reg:DI
122 [ num ]) 0))
(minus:QI (const_int 32 [0x20])
(and:QI (subreg:QI (reg:SI 98 [
num_rshift_n.0_1 ]) 0)
(const_int 31 [0x1f] 0)))
(clobber (reg:CC 17 flags))
(set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -28 [0xffe4])) [1 num.low+0 S4
A32])
(reg:SI 124))
]) "20040703-wpa.c":9:37 -1
(nil))
during RTL pass: subreg3
20040703-wpa.c:11:1: internal compiler error: in extract_insn, at recog.cc:2882
0x370010f internal_error(char const*, ...)
/home/mjires/git/GCC/master/gcc/diagnostic-global-context.cc:517
0x36cfabb fancy_abort(char const*, int, char const*)
/home/mjires/git/GCC/master/gcc/diagnostic.cc:1722
0x17e96a0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x17e96e1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:116
0x1792f12 extract_insn(rtx_insn*)
/home/mjires/git/GCC/master/gcc/recog.cc:2882
0x34fe2be decompose_multiword_subregs
/home/mjires/git/GCC/master/gcc/lower-subreg.cc:1587
0x34fec65 execute
/home/mjires/git/GCC/master/gcc/lower-subreg.cc:1894
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.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap
--enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250116 (experimental) (GCC)
[Bug target/118511] [15 Regression] ICE when compiling s390-tools since r15-2002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118511 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-01-16 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 60171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60171&action=edit gcc15-pr118511.patch Untested fix.
[Bug target/118510] [15 Regression][x86] ICE in extract_insn, at recog.cc:2869 with -mapxf since r15-5635-g1ff69000b50e8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118510
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2025-01-16
Target Milestone|--- |15.0
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||hongyuw at gcc dot gnu.org
--- Comment #1 from Uroš Bizjak ---
The compiler is trying to split:
(insn 15 14 16 2 (parallel [
(set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -28 [0xffe4])) [1 num.low+0 S4
A32])
(ior:SI (lshiftrt:SI (reg:SI 120)
(subreg:QI (reg:SI 98 [ num_rshift_n.0_1 ]) 0))
(ashift:SI (subreg:SI (reg:DI 122 [ num ]) 0)
(minus:QI (const_int 32 [0x20])
(subreg:QI (reg:SI 98 [ num_rshift_n.0_1 ]) 0)
(clobber (reg:CC 17 flags))
]) "pr118510.c":9:37 1165 {*x86_shrd_ndd_2}
(nil))
and manages to create one strange RTX:
(insn 39 38 16 2 (parallel [
(set (reg:SI 124)
(ior:SI (lshiftrt:SI (reg:SI 120)
(and:QI (subreg:QI (reg:SI 98 [ num_rshift_n.0_1 ]) 0)
(const_int 31 [0x1f])))
(subreg:SI (ashift:DI (zero_extend:DI (subreg:SI (reg:DI
122 [ num ]) 0))
(minus:QI (const_int 32 [0x20])
(and:QI (subreg:QI (reg:SI 98 [
num_rshift_n.0_1 ]) 0)
(const_int 31 [0x1f] 0)))
(clobber (reg:CC 17 flags))
(set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -28 [0xffe4])) [1 num.low+0 S4
A32])
(reg:SI 124))
]) "pr118510.c":9:37 -1
(nil))
The problem is in the split RTX of:
(define_insn_and_split "*x86_shrd_ndd_2"
[(set (match_operand:SI 0 "nonimmediate_operand")
(ior:SI (lshiftrt:SI (match_operand:SI 1 "nonimmediate_operand")
(match_operand:QI 3 "nonmemory_operand"))
(ashift:SI (match_operand:SI 2 "register_operand")
(minus:QI (const_int 32) (match_dup 3)
(clobber (reg:CC FLAGS_REG))]
"TARGET_APX_NDD
CC author.
[Bug target/118019] RISC-V: Performance regression in hottest function of X264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019 --- Comment #15 from Robin Dapp --- I think it's r15-2820-gab18785840d7b8.
[Bug libstdc++/118158] std::filesystem::equivalent unsupported on socket files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118158 --- Comment #8 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:301a961ffd0567eece55ece42e80a7ba9e855ba0 commit r15-6951-g301a961ffd0567eece55ece42e80a7ba9e855ba0 Author: Jonathan Wakely Date: Mon Dec 30 13:08:41 2024 + libstdc++: Implement LWG 2937 for std::filesystem::equivalent [PR118158] Do not report an error for (is_other(s1) && is_other(s2)) as the standard originally said, nor for (is_other(s1) || is_other(s2)) as libstdc++ was doing. We can compare inode numbers for special files and so give sensible answers. libstdc++-v3/ChangeLog: PR libstdc++/118158 * src/c++17/fs_ops.cc (fs::equivalent): Remove error reporting for is_other(s1) && is_other(s2) case, as per LWG 2937. * testsuite/27_io/filesystem/operations/pr118158.cc: New test.
[Bug tree-optimization/115825] [12/13/14 Regression] Loop unrolling increases code size with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825 --- Comment #26 from Richard Biener --- (In reply to Segher Boessenkool from comment #25) > No, darn does have a side effect: it returns a random number in the > destination reg (_deliver_ _a_ _r_andom _n_umber). It does not touch memory > at all. > > There are no call insns at all either, of course, so how is that code you > show > relevant at all? This is a GIMPLE pass which has no idea what the backend will expand __builtin_darn() to. And yes, on the GIMPLE side builtin calls are calls. And builtins like __builtin_strftime () do expand to calls. As said already - if the rev in question caused tons of testsuite fails please open a _separate_ bugreport listing those so that we can properly track such a regression. _This_ bug is about the excessive unrolling and thus code size regression involving stmts with side-effects (on AVR).
[Bug middle-end/118490] [15 Regression] ICE Indefinite recursion transforming exp-log with -frounding-math since r15-5116-ge232dc3bb5c3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118490 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |soumyaa at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from ktkachov at gcc dot gnu.org --- Soumya is working on it.
[Bug target/118510] [15 Regression][x86] ICE in extract_insn, at recog.cc:2869 with -mapxf since r15-5635-g1ff69000b50e8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118510
--- Comment #2 from Uroš Bizjak ---
Something like the following patch should fix the ICE:
--cut here--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 362b0ddcf40..2f1997bc36c 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -17226,7 +17226,7 @@ (define_insn_and_split "*x86_shrd_2"
(clobber (reg:CC FLAGS_REG))])])
(define_insn_and_split "*x86_shrd_ndd_2"
- [(set (match_operand:SI 0 "nonimmediate_operand")
+ [(set (match_operand:SI 0 "register_operand")
(ior:SI (lshiftrt:SI (match_operand:SI 1 "nonimmediate_operand")
(match_operand:QI 3 "nonmemory_operand"))
(ashift:SI (match_operand:SI 2 "register_operand")
@@ -17236,7 +17236,7 @@ (define_insn_and_split "*x86_shrd_ndd_2"
&& ix86_pre_reload_split ()"
"#"
"&& 1"
- [(parallel [(set (match_dup 4)
+ [(parallel [(set (match_dup 0)
(ior:SI (lshiftrt:SI (match_dup 1)
(and:QI (match_dup 3) (const_int 31)))
(subreg:SI
@@ -17245,12 +17245,7 @@ (define_insn_and_split "*x86_shrd_ndd_2"
(minus:QI (const_int 32)
(and:QI (match_dup 3)
(const_int 31 0)))
- (clobber (reg:CC FLAGS_REG))
- (set (match_dup 0) (match_dup 4))])]
-{
- operands[4] = gen_reg_rtx (SImode);
- emit_move_insn (operands[4], operands[0]);
-})
+ (clobber (reg:CC FLAGS_REG))])])
;; Base name for insn mnemonic.
(define_mode_attr cvt_mnemonic
--cut here--
[Bug target/118512] New: [15 regression] Failed bootstrap on sparc (Error: Hardware capability "vis3b" not enabled for "fpcmpule8".)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512
Bug ID: 118512
Summary: [15 regression] Failed bootstrap on sparc (Error:
Hardware capability "vis3b" not enabled for
"fpcmpule8".)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: assemble-failure, build
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
```
$
/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/build/./prev-gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/build/./prev-gcc/
-B/usr/sparc64-unknown-linux-gnu/bin/ -B/usr/sparc64-unknown-linux-gnu/bin/
-B/usr/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/sparc64-unknown-linux-gnu/include -isystem
/usr/sparc64-unknown-linux-gnu/sys-include -fno-checking -c -mcpu=niagara4 -g
-pipe -ggdb3 -O3 -fno-checking -gnatpg -gnata -W -Wall -fPIE -nostdinc -I- -I.
-Iada/generated -Iada
-I/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada
-Iada/libgnat
-I/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/libgnat
-Iada/gcc-interface
-I/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/gcc-interface
/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/errout.adb
-o ada/errout.o
{standard input}: Assembler messages:
{standard input}:10660: Error: Hardware capability "vis3b" not enabled for
"fpcmpule8".
{standard input}:11823: Error: Hardware capability "vis3b" not enabled for
"fpcmpule8".
{standard input}:12020: Error: Hardware capability "vis3b" not enabled for
"fpcmpule8".
{standard input}:12655: Error: Hardware capability "vis3b" not enabled for
"fpcmpule8".
{standard input}:13429: Error: Hardware capability "vis3b" not enabled for
"fpcmpule8".
{standard input}:14604: Error: Hardware capability "vis3b" not enabled for
"fpcmpule8".
{standard input}:15440: Error: Hardware capability "vis3b" not enabled for
"fpcmpule8".
```
With 14, it succeeds:
```
$ gcc-14 -fno-checking -c -mcpu=niagara4 -g -pipe -ggdb3 -O3 -fno-checking
-gnatpg -gnata -W -Wall -fPIE -nostdinc -I- -I. -Iada/generated -Iada
-I/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada
-Iada/libgnat
-I/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/libgnat
-Iada/gcc-interface
-I/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/gcc-interface
/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/errout.adb
-o ada/errout.o
```
---
```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-unknown-linux-gnu/15/lto-wrapper
Target: sparc64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0.0_pre20240728/work/gcc-15-20240728/configure
--host=sparc64-unknown-linux-gnu --build=sparc64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/sparc64-unknown-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/sparc64-unknown-linux-gnu/15/include
--datadir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/15
--mandir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/15/man
--infodir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/sparc64-unknown-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/sparc64-unknown-linux-gnu/15/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
15.0.0_pre20240728 p7' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --without-zstd --without-isl
--enable-default-pie --enable-host-pie --disable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config=bootstrap-O3
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240728 (experimental) (Gentoo 15.0.0_pre20240728 p7)
```
```
$
/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/build/./prev-gcc/xgcc
-v
Using built-in specs.
COLLECT_GCC=/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/build/./prev-gcc/xgcc
Target: sparc64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/configure
--host=sparc64-unknown-linux-gnu --build=sparc64-unknown-linux-gnu
-
[Bug libstdc++/99995] [12/13/14/15 Regression] should not include in c++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #11 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:462a7f45caf78466ee6d9a1256a1e2848e4ec49c commit r15-6952-g462a7f45caf78466ee6d9a1256a1e2848e4ec49c Author: Jonathan Wakely Date: Wed Dec 11 17:32:39 2024 + libstdc++: Move std::basic_ostream to new internal header [PR5] This adds so that other headers don't need to include all of , which pulls in all of since C++23 (for the std::print and std::println overloads in ). This new header allows the constrained operator<< in to be defined without all of std::format being compiled. We could also replace with in all of , , , and . That seems more likely to cause problems for users who might be expecting to define std::endl, for example. Although the standard doesn't guarantee that, it is more reasonable than expecting to define it! We can look into making those changes for GCC 16. libstdc++-v3/ChangeLog: PR libstdc++/5 * include/Makefile.am: Add new header. * include/Makefile.in: Regenerate. * include/bits/unique_ptr.h: Include bits/ostream.h instead of ostream. * include/std/ostream: Include new header. * include/bits/ostream.h: New file.
[Bug target/118512] [15 regression] Failed bootstrap on sparc (Error: Hardware capability "vis3b" not enabled for "fpcmpule8".)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512 Sam James changed: What|Removed |Added Target Milestone|--- |15.0 CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Sam James --- I don't know if it's a gas bug instead.
[Bug target/118512] [15 regression] Failed bootstrap on sparc (Error: Hardware capability "vis3b" not enabled for "fpcmpule8".)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512 --- Comment #1 from Sam James --- Created attachment 60172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60172&action=edit errout.s.xz
[Bug libstdc++/50871] libstdc++ should be built with -Wpedantic and/or -Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50871 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |15.0 --- Comment #20 from Jonathan Wakely --- (In reply to Sam James from comment #19) > FTR: > * r15-3714-gd3a7302ec5985a > * r15-3859-g63a598deb0c9fc Yeah I think this is fixed thanks to Jason's GCC 15 changes.
[Bug target/118512] [15 regression] Failed bootstrap on sparc (Error: Hardware capability "vis3b" not enabled for "fpcmpule8".)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512 --- Comment #3 from Sam James --- Created attachment 60173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60173&action=edit errout.s-14.xz
[Bug target/118512] [15 regression] Failed bootstrap on sparc (Error: Hardware capability "vis3b" not enabled for "fpcmpule8".)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512 --- Comment #4 from Sam James --- We don't emit fpcmpule8 for 14.
[Bug fortran/118441] [15 Regression] [openmp] ICE with assignment of PACK of string array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118441 --- Comment #7 from GCC Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c5a8e22c5dacf4f9d4f66e60990bf34c70f04714 commit r15-6953-gc5a8e22c5dacf4f9d4f66e60990bf34c70f04714 Author: Tobias Burnus Date: Thu Jan 16 11:50:26 2025 +0100 Fortran: Create fresh ts.u.cl for result in gfc_get_symbol_for_expr [PR118441] For intrinsic routines, called in libraries, the prototype is created from the call via gfc_get_symbol_for_expr. For the actual arguments, it calls gfc_copy_formal_args_intr which already ensures that the ts.u.cl is freshly allocated. This commit now ensures the same for character-returning functions. PR fortran/118441 gcc/fortran/ChangeLog: * trans-intrinsic.cc (gfc_get_symbol_for_expr): Use gfc_new_charlen for character-returning functions. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/intrinsic_pack_7.f90: New test.
[Bug target/118489] [15 Regression][avx512] ICE in ix86_expand_vector_bf2sf_with_vec_perm, at config/i386/i386-expand.cc:26917 since r15-4955-g648bd1fcc6acfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118489 Hongtao Liu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Hongtao Liu --- Fixed.
[Bug tree-optimization/118487] [15 Regression] ICE tree check: expected vector_cst, have ssa_name in vector_cst_encoded_nelts, at tree.h:4683 since r15-5563-g1c4d39ada33d36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118487 Christoph Müllner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Christoph Müllner --- Fixed with https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b42eeef63a7e88f90e6ecab9c541b96146759b8c Thanks for reporting!
[Bug tree-optimization/41339] Variables can occur multiple times in cfun->local_decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41339 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog, ||internal-improvement, ||memory-hog Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #10 from Richard Biener --- It's only an inefficiency. I'm not working on this, I'm not sure spending cycles is worth those.
[Bug c++/118509] New: Front-end produced uninitialized memory reference when compiling Nektar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509 Bug ID: 118509 Summary: Front-end produced uninitialized memory reference when compiling Nektar Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dizhao at os dot amperecomputing.com Target Milestone: --- Created attachment 60170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60170&action=edit preprocessed cpp code The problem is found when building Nektar++: https://gitlab.nektar.info/nektar/nektar, file library/LocalRegions/QuadExp.cpp . Attached is a preprocessed version of the code, so it would be easier to reproduce the problem. (Sorry the source file has a big 2Mb size, I've tried to remove some codes, but it's rather difficult and time consuming to go on with that...) The compile option is "g++ -std=c++17 -Ofast -c". The bug is exposed after commit b25d3201 (gcc-15), On function: "struct shared_ptr std::__invoke_impl, Nektar::ScaledMatrixTag>, Nektar::BlockMatrixTag> >, std::shared_ptr, Nektar::ScaledMatrixTag>, Nektar::BlockMatrixTag> > (Nektar::LocalRegions::Expansion::*&)(const Nektar::LocalRegions::MatrixKey&), Nektar::LocalRegions::QuadExp*&, const Nektar::LocalRegions::MatrixKey&> (struct ..." . After this commit, the gimple code at 007.gimple is like: ... struct QuadExp * D.278923;//The problematic pointer. D.271234 = MEM[(struct QuadExp * &)__t]; D.271235 = *__f; _1 = D.271235.__delta; _2 = _1 & 1; if (_2 != 0) goto ; else goto ; : D.278923 = D.271234;//Assigned in one of the if-else branch. _3 = D.271235.__delta; _4 = _3 >> 1; _5 = (sizetype) _4; _6 = D.278923->D.217872._vptr.StdExpansion2D; _7 = _6 + 18446744073709551472; _8 = MEM[(long int *)_7]; _9 = (sizetype) _8; _10 = _5 + _9; _11 = D.278923 + _10; _12 = MEM[(int (*) () * *)_11]; _13 = D.271235.__pfn; _14 = (sizetype) _13; _15 = _12 + _14; iftmp.53 = *_15; goto ; : iftmp.53 = D.271235.__pfn; : iftmp.54_16 = iftmp.53; _17 = D.271235.__delta; _18 = _17 >> 1; _19 = (sizetype) _18; _20 = D.278923->D.217872._vptr.StdExpansion2D; //Used after if-else. _21 = _20 + 18446744073709551472; _22 = MEM[(long int *)_21]; _23 = (sizetype) _22; _24 = _19 + _23; _25 = D.278923 + _24; * = iftmp.54_16 (_25, __args#0); [return slot optimization] return ; While before the commit, the gimple code was like: D.379618 = MEM[(struct QuadExp * &)__t]; //Only this variable is used. D.379620 = *__f; _1 = D.379620.__delta; _2 = _1 & 1; if (_2 != 0) goto ; else goto ; : _3 = D.379620.__delta; _4 = _3 >> 1; _5 = (sizetype) _4; _6 = D.379618->D.283369.D.273899._vptr.StdExpansion2D; _7 = _6 + 18446744073709551096; _8 = MEM[(long int *)_7]; _9 = (sizetype) _8; _10 = _5 + _9; _11 = D.379618 + _10; _12 = MEM[(int (*) () * *)_11]; _13 = D.379620.__pfn; _14 = (sizetype) _13; _15 = _12 + _14; iftmp.82 = *_15; goto ; : iftmp.82 = D.379620.__pfn; : iftmp.83_16 = iftmp.82; _17 = D.379620.__delta; _18 = _17 >> 1; _19 = (sizetype) _18; _20 = D.379618->D.283369.D.273899._vptr.StdExpansion2D; _21 = _20 + 18446744073709551096; _22 = MEM[(long int *)_21]; _23 = (sizetype) _22; _24 = _19 + _23; _25 = D.379618 + _24; * = iftmp.83_16 (_25, __args#0); [return slot optimization] return ;
[Bug middle-end/116891] [12/13 Regression] invalid optimization of -fma(-x,x,-z) when -O3 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891 --- Comment #17 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e599311147332567d8d8c8c457fe5f6c2de64fe0 commit r13-9319-ge599311147332567d8d8c8c457fe5f6c2de64fe0 Author: Jakub Jelinek Date: Tue Oct 15 19:38:46 2024 +0200 match.pd: Further fma negation fixes [PR116891] On Mon, Oct 14, 2024 at 08:53:29AM +0200, Jakub Jelinek wrote: > > PR middle-end/116891 > > * match.pd ((negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2)): > > Only enable for !HONOR_SIGN_DEPENDENT_ROUNDING. > > Guess it would be nice to have a testcase which FAILs without the patch and > PASSes with it, but it can be added later. I've added such a testcase now, and additionally found the fix only fixed one of the 4 problematic similar cases. Here is a patch which fixes the others too and adds the testcases. fma-pr116891.c FAILed without your patch, FAILs with your patch too (but only due to the bar/baz/qux checks) and PASSes with the patch. 2024-10-15 Jakub Jelinek PR middle-end/116891 * match.pd ((negate (fmas@3 @0 @1 @2)) -> (IFN_FNMS @0 @1 @2)): Only enable for !HONOR_SIGN_DEPENDENT_ROUNDING. ((negate (IFN_FMS@3 @0 @1 @2)) -> (IFN_FNMA @0 @1 @2)): Likewise. ((negate (IFN_FNMA@3 @0 @1 @2)) -> (IFN_FMS @0 @1 @2)): Likewise. * gcc.dg/pr116891.c: New test. * gcc.target/i386/fma-pr116891.c: New test. (cherry picked from commit 4366f0c7e296ea0d7279343c9b0a1d597588a1da)
[Bug tree-optimization/116380] [13 regression] ICE on valid code at -O3 with "-fno-tree-scev-cprop" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116380 Richard Biener changed: What|Removed |Added Known to work||13.3.1 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to fail||13.3.0 --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/117254] [12/13 Regression] ICE: have var_decl in get_len, at tree.h:6512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117254 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:945d4718652a9b32b973f7f2e7563591b5bd0154 commit r13-9322-g945d4718652a9b32b973f7f2e7563591b5bd0154 Author: Richard Biener Date: Tue Oct 22 11:46:47 2024 +0200 tree-optimization/117254 - ICE with access diangostics The diagnostics code fails to handle non-constant domain max. PR tree-optimization/117254 * gimple-ssa-warn-access.cc (maybe_warn_nonstring_arg): Check the array domain max is constant before using it. * gcc.dg/pr117254.c: New testcase. (cherry picked from commit d464a52d0678dfea523a60efe8b792ba1b8d40db)
[Bug tree-optimization/117574] [12/13 Regression] Miscompile with -O2/3 and -O0/1 since r6-4133-ga8fc25795155d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117574 --- Comment #15 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:35069d462540f1175665fc90076142504a35f423 commit r13-9326-g35069d462540f1175665fc90076142504a35f423 Author: Richard Biener Date: Fri Nov 15 11:56:14 2024 +0100 tree-optimization/117574 - bougs niter lt-to-ne When trying to change a IV from IV0 < IV1 to IV0' != IV1' we apply fancy adjustments to the may_be_zero condition we compute rather than using the obvious IV0->base >= IV1->base expression (to be able to use > instead of >=?). This doesn't seem to go well. PR tree-optimization/117574 * tree-ssa-loop-niter.cc (number_of_iterations_lt_to_ne): Use the obvious may_be_zero condition. * gcc.dg/torture/pr117574-1.c: New testcase. (cherry picked from commit ff5a14abeb31cd6bd0ca55e7043d05c8141a8c7f)
[Bug tree-optimization/117417] [12/13 Regression] ICE: verify_gimple failed: non-top-level 'bit_field_ref' with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117417 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:8a51ec3176837b22d6ffa02c11ebcd7e8fe2f8b8 commit r13-9325-g8a51ec3176837b22d6ffa02c11ebcd7e8fe2f8b8 Author: Richard Biener Date: Tue Nov 12 11:15:15 2024 +0100 tree-optimization/117417 - ICE with complex load optimization When we decompose a complex load only used as real and imaginary parts we fail to honor IL constraints which are that a BIT_FIELD_REF of register type should be outermost in a ref. The following simply avoids the transform when the complex load has such a BIT_FIELD_REF. PR tree-optimization/117417 * tree-ssa-forwprop.cc (pass_forwprop::execute): Avoid decomposing BIT_FIELD_REF complex load. * gcc.dg/torture/pr117417.c: New testcase. (cherry picked from commit d976daa931642d940b7b27032ca6139210c07eed)
[Bug tree-optimization/117086] [13 Regression] ICE in tree check: expected vector_type, have boolean_type in TYPE_VECTOR_SUBPARTS, at tree.h:4255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117086 Richard Biener changed: What|Removed |Added Known to fail||13.3.0 Known to work||13.3.1 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Richard Biener --- Fixed.
[Bug tree-optimization/117307] [12 regression] ICE when building gavl-1.4.0 in vect_slp_analyze_operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117307 Richard Biener changed: What|Removed |Added Known to work||13.3.1 Priority|P3 |P2 Summary|[12/13 regression] ICE when |[12 regression] ICE when |building gavl-1.4.0 in |building gavl-1.4.0 in |vect_slp_analyze_operations |vect_slp_analyze_operations
[Bug testsuite/118451] gcc.dg/vect/vect-switch-search-line-fast.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118451 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Tamar Christina --- Fixed, the tests should now report UNSUPPORTED on the targets that don't support early break.
[Bug c++/118513] New: ICE with modules and structured binding using std::tuple*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513
Bug ID: 118513
Summary: ICE with modules and structured binding using
std::tuple*
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
--- gcc/testsuite/g++.dg/modules/decomp-3_a.H.jj2025-01-16
13:43:36.492879734 +0100
+++ gcc/testsuite/g++.dg/modules/decomp-3_a.H 2025-01-16 13:43:11.314224231
+0100
@@ -0,0 +1,19 @@
+// { dg-additional-options -fmodule-header }
+// { dg-module-cmi {} }
+
+namespace std {
+ template struct tuple_size;
+ template struct tuple_element;
+}
+
+struct A {
+ int a, b;
+ template int &get () { if (I == 0) return a; else return b; }
+};
+
+template <> struct std::tuple_size { static const int value = 2; };
+template struct std::tuple_element { using type = int; };
+
+namespace {
+auto [x, y] = A { 42, 43 };
+}
--- gcc/testsuite/g++.dg/modules/decomp-3_b.C.jj2025-01-16
13:43:41.782807354 +0100
+++ gcc/testsuite/g++.dg/modules/decomp-3_b.C 2025-01-16 13:41:49.256346946
+0100
@@ -0,0 +1,11 @@
+// { dg-do run }
+// { dg-additional-options "-fmodules-ts" }
+
+import "decomp-3_a.H";
+
+int
+main ()
+{
+ if (x != 42 || y != 43)
+__builtin_abort ();
+}
testcase ICEs with
FAIL: g++.dg/modules/decomp-3_b.C -std=c++17 (internal compiler error: in
import_export_decl, at cp/decl2.cc:3442)
FAIL: g++.dg/modules/decomp-3_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/decomp-3_b.C -std=c++2a (internal compiler error: in
import_export_decl, at cp/decl2.cc:3442)
FAIL: g++.dg/modules/decomp-3_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/decomp-3_b.C -std=c++2b (internal compiler error: in
import_export_decl, at cp/decl2.cc:3442)
FAIL: g++.dg/modules/decomp-3_b.C -std=c++2b (test for excess errors)
If I use #include "decomp-3_a.H" instead of import "decomp-3_a.H"; then
the x and y VAR_DECLs, initially TREE_PUBLIC, first go through (in
cp_finish_decomp)
through layout_decl (v[i], 0);, then copy_linkage (v[i], decl); which among
other things clears TREE_PUBLIC and then
cp_finish_decl (v[i], init, /*constexpr*/false,
/*asm*/NULL_TREE, LOOKUP_NORMAL);
which among other things calls
9291 make_rtl_for_nonlocal_decl (decl, init, asmspec);
and so var_finalized_p is since then true, so write_out_vars does nothing for
it.
Now, when reading the module header, the VAR_DECLs are streamed in with proper
!TREE_PUBLIC flag, but var_finalized_p is not true, and as the var doesn't have
DECL_INTERFACE_KNOWN, we ICE in import_export_decl.
I'm afraid I have no idea what should be done in the module case, whether the
vars need to be finalized somewhere during the streaming in (just namespace
scope structured bindings, something else?) or whether something should arrange
for DECL_INTERFACE_KNOWN to be set for those.
[Bug c++/118513] ICE with modules and structured binding using std::tuple*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513 --- Comment #1 from Jakub Jelinek --- Note, on the structured binding base VAR_DECL, DECL_INTERFACE_KNOWN has been set in #0 constrain_visibility (decl=, visibility=4, tmpl=false) at ../../gcc/cp/decl2.cc:2815 #1 0x005962ad in determine_visibility (decl=) at ../../gcc/cp/decl2.cc:3068 #2 0x00551b80 in cp_finish_decl (decl=, init=, init_const_expr_p=true, asmspec_tree=, flags=5, decomp=0x7fffcdf0) at ../../gcc/cp/decl.cc:9107 Later on we copy_linkage from that base VAR_DECL to x and y VAR_DECLs, but that just copies DECL_VISIBILITY and the like, but doesn't actually set DECL_INTERFACE_KNOWN. Shall copy_linkage call constraint_visibility (or perhaps just for VISIBILITY_ANON)?
[Bug tree-optimization/117307] [12/13 regression] ICE when building gavl-1.4.0 in vect_slp_analyze_operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117307 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:fbf5f5bd00de543868e05ca20a8db6c2bc1c21db commit r13-9323-gfbf5f5bd00de543868e05ca20a8db6c2bc1c21db Author: Richard Biener Date: Mon Oct 28 09:52:08 2024 +0100 tree-optimization/117307 - STMT_VINFO_SLP_VECT_ONLY mis-computation STMT_VINFO_SLP_VECT_ONLY isn't properly computed as union of all group members and when the group is later split due to duplicates not all sub-groups inherit the flag. PR tree-optimization/117307 * tree-vect-data-refs.cc (vect_analyze_data_ref_accesses): Properly compute STMT_VINFO_SLP_VECT_ONLY. Set it on all parts of a split group. * gcc.dg/vect/pr117307.c: New testcase. (cherry picked from commit 19722308a286d9a00eead8ac82b948da8c4ca38b)
[Bug tree-optimization/117104] [12/13 regression] ICE when building python-3.12.7 (prepare_cmp_insn, at optabs.cc:4622) with -O2 -march=x86-64-v4 -fno-vect-cost-model -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117104 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e05758094fd725366c96129e84092b0d1f472834 commit r13-9321-ge05758094fd725366c96129e84092b0d1f472834 Author: Richard Biener Date: Sat Oct 12 14:51:37 2024 +0200 tree-optimization/117104 - add missed guards to max(a,b) != a simplification For vector types we have to make sure the comparison result is a vector type and the resulting compare operation is supported. As the resulting compare is never an equality compare I didn't bother to check for the cbranch case. PR tree-optimization/117104 * match.pd ((cmp:c (minmax:c @0 @1) @0) -> (out @0 @1)): Properly guard the vector case. * gcc.dg/pr117104.c: New testcase. (cherry picked from commit f54d42e7e7a558b273d87f95b3e5b1938f5a)
[Bug middle-end/116891] [12/13 Regression] invalid optimization of -fma(-x,x,-z) when -O3 and -frounding-math are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116891 --- Comment #16 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:c59ab5fba1c8c6b6f13c213ee9e7e677b9782dd0 commit r13-9318-gc59ab5fba1c8c6b6f13c213ee9e7e677b9782dd0 Author: Richard Biener Date: Mon Oct 14 08:11:22 2024 +0200 middle-end/116891 - fix (negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2) Transforming -fma (-a, b, -c) to fma (a, b, c) is only valid when not rounding towards -inf or +inf as the sign of the multiplication changes. PR middle-end/116891 * match.pd ((negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2)): Only enable for !HONOR_SIGN_DEPENDENT_ROUNDING. (cherry picked from commit c53bd48c6920bc1f4039b6682aafbf414a600e47)
[Bug tree-optimization/117086] [13 Regression] ICE in tree check: expected vector_type, have boolean_type in TYPE_VECTOR_SUBPARTS, at tree.h:4255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117086 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:13860e2f036c34d43a6ef07da4f6e66854d176fd commit r13-9320-g13860e2f036c34d43a6ef07da4f6e66854d176fd Author: Richard Biener Date: Fri Oct 11 11:46:45 2024 +0200 middle-end/117086 - fixup vec_cond simplifications The following adds missing checks for a vector type result type to simplifications that end up creating a vec_cond. PR middle-end/117086 * match.pd ((op (vec_cond ...) ..) -> (vec_cond ...)): Add missing checks for VECTOR_TYPE_P (type). * gcc.dg/torture/pr117086.c: New testcase. (cherry picked from commit c64ae8377210bde44714d265311ee7bfa2733df9)
[Bug middle-end/116290] [12/13 Regression] -fcompare-debug -gno-statement-frontiers -O2 failure with evolution-data-server-3.52.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116290 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:a1bdcba603d79b4c20acd668ce056a586c4ab77a commit r13-9314-ga1bdcba603d79b4c20acd668ce056a586c4ab77a Author: Richard Biener Date: Sun Oct 13 15:12:44 2024 +0200 tree-optimization/116290 - fix compare-debug issue in ldist Loop distribution does different analysis with -g0/-g due to counting a debug stmt starting a BB against a limit which will everntually lead to different IVOPTs choices. I've fixed a possible IVOPTs issue on the way even though it doesn't make a difference here. PR tree-optimization/116290 * tree-loop-distribution.cc (determine_reduction_stmt_1): PHIs have no debug variants. Start with first non-debug real stmt. * tree-ssa-loop-ivopts.cc (find_givs_in_bb): Do not analyze debug stmts. * gcc.dg/pr116290.c: New testcase. (cherry picked from commit 566740013b3445162b8c4bc2205e4e568d014968)
[Bug tree-optimization/116380] [13 regression] ICE on valid code at -O3 with "-fno-tree-scev-cprop" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116380 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ad9e846e25a7907920faecafa1f034526e86d348 commit r13-9315-gad9e846e25a7907920faecafa1f034526e86d348 Author: Richard Biener Date: Wed Aug 21 13:56:40 2024 +0200 tree-optimization/116380 - bogus SSA update with loop distribution When updating LC PHIs after copying loops we have to handle defs defined outside of the loop appropriately (by not setting them to NULL ...). This mimics how we handle this in the SSA updating code of the vectorizer. PR tree-optimization/116380 * tree-loop-distribution.cc (copy_loop_before): Handle out-of-loop defs appropriately. * gcc.dg/torture/pr116380.c: New testcase. (cherry picked from commit af0d2d95a5f767d92bd64f959679fb4612247b0b)
[Bug rtl-optimization/118067] [15 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1860 (unable to find a register to spill) {*lshrhi3_1} with -O -fno-split-wide-types -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067 --- Comment #7 from Vladimir Makarov --- I've been working on thr PR this week. The case is complicated as it contains cycle of reloads of more one step length. LRA has a mechanism to avoid choosing insn alternatives which can results in a loop. But the loop should be simple, containing just one step. I still hope to fix it on this week.
[Bug c++/118513] ICE with modules and structured binding using std::tuple*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513
--- Comment #2 from Jakub Jelinek ---
--- gcc/cp/decl2.cc.jj 2025-01-16 13:34:29.719360710 +0100
+++ gcc/cp/decl2.cc 2025-01-16 14:27:54.095464791 +0100
@@ -3656,6 +3656,8 @@ copy_linkage (tree guard, tree decl)
comdat_linkage (guard);
DECL_VISIBILITY (guard) = DECL_VISIBILITY (decl);
DECL_VISIBILITY_SPECIFIED (guard) = DECL_VISIBILITY_SPECIFIED (decl);
+ if (expr_visibility (decl) == VISIBILITY_ANON)
+ constrain_visibility (guard, VISIBILITY_ANON, false);
}
}
fixes it, but then if decl has VISIBILITY_ANON, it should already be
!TREE_PUBLIC, so shouldn't that be if (!TREE_PUBLIC (decl))
constrain_visibility (guard, VISIBILITY_ANON, false); or even
if (!TREE_PUBLIC (decl) && DECL_INTERFACE_KNOWN (decl)) { DECL_INTERFACE_KNOWN
(guard) = 1; if (DECL_LANG_SPECIFIC (decl)) DECL_NOT_REALLY_EXTERN (decl) = 1;
}
?
[Bug c++/118513] ICE with modules and structured binding using std::tuple*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513 --- Comment #3 from Jakub Jelinek --- Or of course if something like that isn't appropriate for all copy_linkage uses (other than structured bindings it is used for guard variables I think), then cp_finish_decomp could do that.
[Bug libstdc++/112934] excessive code for std::map::erase(key)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934 --- Comment #2 from Jonathan Wakely --- Gah, I didn't get around to this for GCC 15, sorry.
[Bug libstdc++/90389] std::deque::emplace tries to call wrong overload internally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90389 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a5ce37b32d6a32e774ba4e156fe0d6d3f4e616fe commit r14-11213-ga5ce37b32d6a32e774ba4e156fe0d6d3f4e616fe Author: Jonathan Wakely Date: Tue Dec 17 17:38:43 2024 + libstdc++: Fix std::deque::emplace calling wrong _M_insert_aux [PR90389] We have several overloads of std::deque::_M_insert_aux, one of which is variadic and called by std::deque::emplace. With a suitable set of arguments to emplace, it's possible for one of the non-variadic _M_insert_aux overloads to be selected by overload resolution, making emplace ill-formed. Rename the variadic _M_insert_aux to _M_emplace_aux so that calls to emplace never select an _M_insert_aux overload. Also add an inline _M_insert_aux for the const lvalue overload that is called from insert(const_iterator, const value_type&). libstdc++-v3/ChangeLog: PR libstdc++/90389 * include/bits/deque.tcc (_M_insert_aux): Rename variadic overload to _M_emplace_aux. * include/bits/stl_deque.h (_M_insert_aux): Define inline. (_M_emplace_aux): Declare. * testsuite/23_containers/deque/modifiers/emplace/90389.cc: New test. (cherry picked from commit 5f44b1776e748a7528020557036740905a11b1df)
[Bug libstdc++/118493] [14 regression] std::vector::insert regression in C++03: execution reaches an unreachable program point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118493 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- I put the wrong PR number in the commit message, but this was fixed on trunk by: commit r15-6926-g6f85a97248fdff15aadc9514c1118eee0293d256 Date: Wed Jan 15 09:33:55 2025 + libstdc++: Fix reversed args in unreachable assumption [PR109849] libstdc++-v3/ChangeLog: PR libstdc++/109849 * include/bits/vector.tcc (vector::_M_range_insert): Fix reversed args in length calculation. and on gcc-14 by commit r14-11215-g7df6af205f5c9853c4d70b5b8172b0483179c891 Thanks for noticing this and reporting it!
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #44 from Jonathan Wakely --- Oops, I put this PR number in the commits rather than PR 118493
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #43 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7df6af205f5c9853c4d70b5b8172b0483179c891 commit r14-11215-g7df6af205f5c9853c4d70b5b8172b0483179c891 Author: Jonathan Wakely Date: Wed Jan 15 09:33:55 2025 + libstdc++: Fix reversed args in unreachable assumption [PR109849] libstdc++-v3/ChangeLog: PR libstdc++/109849 * include/bits/vector.tcc (vector::_M_range_insert): Fix reversed args in length calculation. (cherry picked from commit 6f85a97248fdff15aadc9514c1118eee0293d256)
[Bug c++/118513] ICE with modules and structured binding using std::tuple*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513
Nathaniel Shead changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-01-16
Ever confirmed|0 |1
--- Comment #4 from Nathaniel Shead ---
Confirmed. Without having looked into it too much I think maybe doing
`varpool_node::finalize_decl` might be the way to go to cover this and any
other related issues that may be cropping up by not having done so?
On a possibly-related note I discovered that 'decl_linkage' doesn't correctly
work for structured bindings (it always gives lk_none), and we don't check for
violation of https://eel.is/c++draft/module.import#6 when removing the
anonymous namespace.
Here's a quick untested patch that seemingly fixes most of these issues (though
I admit I copied conditions for finalize_decl somewhat at random from
make_rtl_for_nonlocal_decl; I would need to spend more time analysing the logic
to know what is actually needed here).
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 61116fe7669..b4117d353a2 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -12467,6 +12467,13 @@ trees_in::read_var_def (tree decl, tree
maybe_template)
note_vague_linkage_variable (decl);
}
DECL_INITIAL (decl) = init;
+ if (VAR_P (maybe_template)
+ && !DECL_IMPLICIT_INSTANTIATION (decl)
+ && (!DECL_FUNCTION_SCOPE_P (decl) || TREE_STATIC (decl))
+ && (!DECL_DEFER_OUTPUT (decl) || DECL_INITIAL (decl))
+ && !DECL_EXTERNAL (decl)
+ && !DECL_HAS_VALUE_EXPR_P (decl))
+varpool_node::finalize_decl (decl);
if (!dyn_init)
;
else if (CP_DECL_THREAD_LOCAL_P (decl))
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 9600b140916..643be09528f 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -16675,6 +16675,7 @@ cp_parser_decomposition_declaration (cp_parser *parser,
cp_finish_decl (decl, initializer, non_constant_p, NULL_TREE,
(is_direct_init ? LOOKUP_NORMAL : LOOKUP_IMPLICIT),
&decomp);
+ check_module_decl_linkage (decl);
}
}
else if (decl != error_mark_node)
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index dd6e872e4e7..b06d8a6b7fb 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -5998,6 +5998,8 @@ decl_linkage (tree decl)
{
if (TREE_CODE (decl) == TYPE_DECL && !TYPE_ANON_P (TREE_TYPE (decl)))
/* This entity has a typedef name for linkage purposes. */;
+ else if (DECL_DECOMPOSITION_P (decl) && DECL_DECOMP_IS_BASE (decl))
+/* Structured binding declarations can have linkage. */;
else if (TREE_CODE (decl) == NAMESPACE_DECL && cxx_dialect >= cxx11)
/* An anonymous namespace has internal linkage since C++11. */
return lk_internal;
[Bug tree-optimization/56547] missed opportunity for FMA with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- This was noticed in TSVC s258 (it actually does `(a + 1.0) * b`). So I am going to give my hand at this.
[Bug c++/118507] Erroneous 'invalid use of qualified-name' for member function defined with 'typedef' in a friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118507 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 44402 ***
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 118507, which changed state. Bug 118507 Summary: Erroneous 'invalid use of qualified-name' for member function defined with 'typedef' in a friend declaration https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118507 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/44402] Doesn't allow friend declarations using a typedef for function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44402 Andrew Pinski changed: What|Removed |Added CC||rush102333 at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 118507 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/118506] Missing FMA for `(a + 1.0) * b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118506 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- This is just a dup of bug 56547 . *** This bug has been marked as a duplicate of bug 56547 ***
[Bug tree-optimization/56547] missed opportunity for FMA with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56547 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- *** Bug 118506 has been marked as a duplicate of this bug. ***
[Bug target/118489] [15 Regression][avx512] ICE in ix86_expand_vector_bf2sf_with_vec_perm, at config/i386/i386-expand.cc:26917 since r15-4955-g648bd1fcc6acfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118489 --- Comment #3 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:3872daa5767622d1f8b086050996c85604db7514 commit r15-6940-g3872daa5767622d1f8b086050996c85604db7514 Author: liuhongt Date: Wed Jan 15 19:09:24 2025 -0800 Fix typo to avoid ICE. gcc/ChangeLog: PR target/118489 * config/i386/sse.md (VF1_AVX512BW): Fix typo. gcc/testsuite/ChangeLog: * gcc.target/i386/pr118489.c: New test.
[Bug tree-optimization/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505 --- Comment #5 from Dhruv Chawla --- (In reply to Andrew Pinski from comment #3) > Note there is also a fma forming missing: > _69 = s_64 + 1.0e+0; > ... > _71 = _69 * _70; > > which is: > `(s_64 + 1.0) * _70` which can be rewritten as `s_64 * _70 + _70` > > That might alone get the performance back up. I should note that LLVM also > does the fcsel but with changing of the 2 instruction `(a+1) * b` into one > fma instruction `a*b + b`. I tried doing this, via: fcmpe s2, #0.0 fmuls1, s30, s30 fcsel s31, s1, s31, gt fmadd s0, s31, s0, s30 str s0, [x21, x0] ldr s29, [x19, x0] fmadd s29, s31, s29, s29 str s29, [x20, x0] I don't really see a performance impact. Also, it seems that clang's codegen is still a bit slower than the split paths.
[Bug tree-optimization/118430] [14/15 Regression] tail call vs IPA-VRP return value range with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430 --- Comment #13 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7f5adfd31b3af08924faec36679eaea40a98af19 commit r15-6944-g7f5adfd31b3af08924faec36679eaea40a98af19 Author: Jakub Jelinek Date: Thu Jan 16 09:25:16 2025 +0100 tree-ssa-propagate: Special case lhs of musttail calls in may_propagate_copy [PR118430] This patch ensures that VRP or similar passes don't replace the uses of lhs of [[gnu::musttail]] calls with some constant (e.g. if the call is known is known to return a singleton value range) etc. to make it more likely that it is actually tail callable. 2025-01-16 Jakub Jelinek PR tree-optimization/118430 * tree-ssa-propagate.cc (may_propagate_copy): Return false if dest is lhs of an [[gnu::musttail]] call. (substitute_and_fold_dom_walker::before_dom_children): Formatting fix. * c-c++-common/musttail14.c: Expect lhs on the must tail call calls.
[Bug tree-optimization/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- I have some ideas to look at split path for better heuristics here. Though I won't get to it until next week, I have few other patches I need to finish up first.
[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:43f4d44bebd63b354f8798fcef512d4d2b42c655 commit r15-6941-g43f4d44bebd63b354f8798fcef512d4d2b42c655 Author: Jakub Jelinek Date: Thu Jan 16 09:17:50 2025 +0100 vec.h: Properly destruct elements in auto_vec auto storage [PR118400] For T with non-trivial destructors, we were destructing objects in the vector on release only when not using auto storage of auto_vec. The following patch calls truncate (0) instead of m_vecpfx.m_num clearing, and truncate takes care of that destruction: unsigned l = length (); gcc_checking_assert (l >= size); if (!std::is_trivially_destructible ::value) vec_destruct (address () + size, l - size); m_vecpfx.m_num = size; 2025-01-16 Jakub Jelinek PR ipa/118400 * vec.h (vec::release): Call m_vec->truncate (0) instead of clearing m_vec->m_vecpfx.m_num.
[Bug tree-optimization/118430] [14/15 Regression] tail call vs IPA-VRP return value range with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9c4397cafc5ded9b008a92a55d4e5207e1c2e4e4
commit r15-6943-g9c4397cafc5ded9b008a92a55d4e5207e1c2e4e4
Author: Jakub Jelinek
Date: Thu Jan 16 09:20:15 2025 +0100
tailc: Virtually undo IPA-VRP return value optimization for tail calls
[PR118430]
When we have return somefn (whatever); where somefn is normally tail
callable and IPA-VRP determines somefn returns a singleton range, VRP
just changes the IL to
somefn (whatever);
return 42;
(or whatever the value in that range is). The introduction of IPA-VRP
return value tracking then effectively regresses the tail call
optimization.
This is even more important if the call is [[gnu::musttail]].
So, the following patch queries IPA-VRP whether a function returns
singleton
range and if so and the value returned is identical to that, marks the
call as [tail call] anyway. If expansion decides it can't use the tail
call, we'll still expand the return 42; or similar statement, and if it
decides it can use the tail call, that part will be ignored and we'll emit
normal tail call.
The reason it works is that the expand pass relies on the tailc pass to
do its job properly.
E.g. when we have
[local count: 1073741824]:
foo (x_2(D));
baz (&v);
v ={v} {CLOBBER(eos)};
bar (x_2(D)); [tail call]
return 1;
when expand_gimple_basic_block handles the bar (x_2(D)); call, it uses
if (call_stmt && gimple_call_tail_p (call_stmt))
{
bool can_fallthru;
new_bb = expand_gimple_tailcall (bb, call_stmt,
&can_fallthru);
if (new_bb)
{
if (can_fallthru)
bb = new_bb;
else
{
currently_expanding_gimple_stmt = NULL;
return new_bb;
}
}
}
As it is actually tail callable during expansion of the bar (x_2(D)); call
stmt, expand_gimple_tailbb returns non-NULL and sets can_fallthru to false,
plus emits
;; bar (x_2(D)); [tail call]
(insn 11 10 12 2 (set (reg:SI 5 di)
(reg/v:SI 99 [ x ])) "pr118430.c":35:10 -1
(nil))
(call_insn/j 12 11 13 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("bar") [flags 0x3] ) [0 bar S1 A8])
(const_int 0 [0]))) "pr118430.c":35:10 -1
(expr_list:REG_CALL_DECL (symbol_ref:DI ("bar") [flags 0x3]
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:SI (use (reg:SI 5 di))
(nil)))
(barrier 13 12 0)
Because it doesn't fallthru, no further statements in the same bb are
expanded. Now, if the bb with return happened to be in some other basic
block from the [tail call], it could be expanded but because the bb with
tail call ends with a barrier, it doesn't fall thru there and if nothing
else could reach it, we'd remove the unreachable bb RSN.
2025-01-16 Jakub Jelinek
Andrew Pinski
PR tree-optimization/118430
* tree-tailcall.cc: Include gimple-range.h, alloc-pool.h, sreal.h,
symbol-summary.h, ipa-cp.h and ipa-prop.h.
(find_tail_calls): If ass_var is NULL and ret_var is not, check if
IPA-VRP has not found singleton return range for it. In that case,
don't punt if ret_var is the only value in that range. Adjust the
maybe_error_musttail message otherwise to diagnose different value
being returned from the caller and callee rather than using return
slot. Formatting fixes.
* c-c++-common/musttail14.c: New test.
* c-c++-common/pr118430.c: New test.
[Bug ipa/118400] [14 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 Jakub Jelinek changed: What|Removed |Added Summary|[14/15 Regression] memory |[14 Regression] memory leak |leak of irange at |of irange at |evaluate_properties_for_edg |evaluate_properties_for_edg |e (ipa-fnsummary.cc:690)|e (ipa-fnsummary.cc:690) |since r14-2121 |since r14-2121 --- Comment #9 from Jakub Jelinek --- Fixed on the trunk. Not sure about the backport, it is less important in 14 because there is no musttail and the patch is a new optimization which can e.g. introduce tail calls where they weren't before.
[Bug gcov-profile/118508] New: 10% performance drop when enabling autofdo for spec2017 554.roms_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118508 Bug ID: 118508 Summary: 10% performance drop when enabling autofdo for spec2017 554.roms_r Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: liuhongt at gcc dot gnu.org Target Milestone: --- with -march=x86-64-v3 -O2. part of dump_gcov is like __step3d_t_mod_MOD_step3d_t total:5500129 head:0 0: 0 29: 0 30: 0 31: 0 32: 0 36: 0 37: 0 38: 0 39: 0 46: 0 59: 0 60: 0 62: 0 59: step3d_t_tile total:5500129 4: 0 4.2: 0 4.4: 0 4.6: 0 4.8: 0 5: 0 5.2: 0 5.4: 0 5.6: 0 5.8: 0 5.10: 0 5.12: 0 7: 0 7.2: 0 7.4: 1 8: 0 8.2: 0 step3d_t_tile is local and only called by step3d_t. Autofdo will do early inline if the edge in the call graph is hot, and it will check total count from the callsite. Unfortranately, the string name it used is DECL_ASSEMBLER_NAME (edge->callee->decl)) which is __step3d_t_mod_MOD_step3d_t_tile, but corresponding name in afdo string table is step3d_t_tile(w/o prefix, I guess it's from debug string table). The mismatch cause auto lost profiling info for step3d_t_tile and thought it was cold and optimized for size. A hack like below can recover performance and further improve 554.roms_r by 3% with autofdo diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc index 3f890e6d1e6..ae8dd9bfdaf 100644 --- a/gcc/auto-profile.cc +++ b/gcc/auto-profile.cc @@ -837,8 +837,10 @@ autofdo_source_profile::get_callsite_total_count ( function_instance *s = get_function_instance_by_inline_stack (stack); if (s == NULL - || afdo_string_table->get_index (IDENTIFIER_POINTER ( - DECL_ASSEMBLER_NAME (edge->callee->decl))) != s->name ()) + || (afdo_string_table->get_index (IDENTIFIER_POINTER ( + DECL_ASSEMBLER_NAME (edge->callee->decl))) != s->name () + && afdo_string_table->get_index_by_decl (edge->callee->decl) + != s->name())) return 0; return s->total_count ();
[Bug ipa/118400] [14 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690) since r14-2121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 --- Comment #10 from Jakub Jelinek --- Please ignore the above comment, that was meant for a different PR. This surely should be backported to 14.
[Bug tree-optimization/118505] [15 regression] aarch64: 25% regression in TSVC s258 since r15-3436-gb2b20b277988ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118505 --- Comment #7 from Andrew Pinski --- I do have to wonder if splitting the path here helps because the condition (a[i] > 0.) Is predictable. I can't think it would be predictable but maybe on accident the predictor get it right 50% of the time, we can keep the pipeline full. I have to think of a good heuristic for that too.
[Bug target/118511] New: [15 Regression] ICE when compiling s390-tools since r15-2002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118511
Bug ID: 118511
Summary: [15 Regression] ICE when compiling s390-tools since
r15-2002
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
s390-tools stage3.c has
static inline void __attribute__((noreturn)) start_kernel(void)
{
struct psw_t *psw = &(*((struct _lowcore *) 0)).program_new_psw;
unsigned long addr, code;
psw->mask = 0x0018000ULL;
code = 1;
asm volatile(
" larl%[addr],.no_diag308\n"
" stg %[addr],8(%[psw])\n"
" diag%[code],%[code],0x308\n"
".no_diag308:\n"
" sam31\n"
" sr %r1,%r1\n"
" sr %r2,%r2\n"
" sigp%r1,%r2,%[order]\n"
" lpsw0\n"
: [addr] "=&d" (addr),
[code] "+&d" (code)
: [psw] "a" (psw),
[order] "L" (18));
while (1);
}
It is unclear what they intended, it assembled before r15-2002 with %r1 the
same as %[code] (or %1, same thing) and %r2 the same as %[psw] (or %2, same
thing), the r modifier was just ignored.
They could have meant %%r1 and %%r2 too, who knows.
With --enable-checking=release gcc 15 it just emits something which doesn't
assemble.
In any case, print_operand hooks shouldn't be using assertions, they should be
using
output_operand_lossage.
[Bug target/118511] [15 Regression] ICE when compiling s390-tools since r15-2002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118511 Jakub Jelinek changed: What|Removed |Added Target||s390x-linux Target Milestone|--- |15.0
[Bug libstdc++/99995] [12/13/14/15 Regression] should not include in c++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #10 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #9) > (In reply to Jonathan Wakely from comment #0) > > In C++20 mode includes which includes > > for SYS_futex, > > We should use for that instead, which would improve things > somewhat. That doesn't help because we still need unistd.h for the actual syscall(long,...) declaration. sys/syscall.h only declares the syscall numbers like SYS_futex.
[Bug c++/118516] New: Misleading error message "call to non-'constexpr' function" when loop variable is not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118516 Bug ID: 118516 Summary: Misleading error message "call to non-'constexpr' function" when loop variable is not declared Product: gcc Version: 12.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: arvo at me dot com Target Milestone: --- Created attachment 60174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60174&action=edit Minimal working example and compiler outputs Observed on Ubuntu 22.04 with GCC 12 (Ubuntu 12.3.0-1ubuntu1~22.04). Command line to reproduce: g++-12 --std=c++20 -c undeclared-loop-var.cxx The main element of the source code is a loop in which the loop variable is misspelled in the condition, and a call to a function is also made in the condition. Expected behavior: (only) error message "'i' was not declared in this scope", according to the misspelled loop variable Actual behavior: The expected error message does appear, but only after 9 (!) instances of the misleading error message "call to non-‘constexpr’ function ‘int foo()’", referring to the same line. It is unclear why 'foo()' being non-'constexpr' should be relevant here. Nothing at the use site seems to suggest that only 'constexpr' calls are allowed here. See the attachment for minimal source code and compiler outputs. Additional notes: - A coworker was able to reproduce this with a variety of GCC versions using godbolt.org. - Importantly, the behavior is observed with the --std=c++20 (or --std=c++23) command line option but is not observed if the option is omitted. In the latter case, the actual behavior matches the expected behavior.
[Bug tree-optimization/118517] ICE in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118517 --- Comment #1 from Michal Jireš --- The patch trips up on empty basic block without successors. This block comes from DSE and can be fixed by: --- a/gcc/tree-ssa-dse.cc +++ b/gcc/tree-ssa-dse.cc @@ -1396,8 +1396,9 @@ dse_optimize_call (gimple_stmt_iterator *gsi, sbitmap live_bytes) if (!node) return false; - if (stmt_could_throw_p (cfun, stmt) - && !cfun->can_delete_dead_exceptions) + if ((stmt_could_throw_p (cfun, stmt) + && !cfun->can_delete_dead_exceptions) + || gimple_call_ctrl_altering_p (stmt)) return false;
[Bug tree-optimization/118517] ICE in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118517 --- Comment #2 from Sam James --- I think this is a dupe of PR117892 / PR118077.
[Bug target/118328] Implement preserve_none for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328 --- Comment #11 from Richard Sandiford --- Created attachment 60175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60175&action=edit Proof-of-concept patch Here's a lightly-tested proof-of-concept patch for preserve_none on AArch64. In practice, I don't think there's much scope for sharing implementation code between targets.
[Bug tree-optimization/118517] New: ICE in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118517
Bug ID: 118517
Summary: ICE in single_succ_edge, at basic-block.h:332 since
r15-5336-gcee7d080d5c2a5
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
Compiling reduced testcase gcc.dg/torture/pr54824.c results in ICE since
r15-5336-gcee7d080d5c2a5.
$ cat pr54824.c
void __attribute__((noreturn)) bar(void) {
__builtin_unreachable ();
}
int p;
void foo() {
if (p) bar();
}
$ gcc pr54824.c -fno-ipa-pure-const -O1
during GIMPLE pass: local-fnsummary
pr54824.c: In function ‘foo’:
pr54824.c:8:1: internal compiler error: in single_succ_edge, at
basic-block.h:332
8 | }
| ^
0x370010f internal_error(char const*, ...)
/home/mjires/git/GCC/master/gcc/diagnostic-global-context.cc:517
0x36cfabb fancy_abort(char const*, int, char const*)
/home/mjires/git/GCC/master/gcc/diagnostic.cc:1722
0x1108f5f single_succ_edge(basic_block_def const*)
/home/mjires/git/GCC/master/gcc/basic-block.h:332
0x14bfef7 builtin_unreachable_bb_p
/home/mjires/git/GCC/master/gcc/ipa-fnsummary.cc:2708
0x14c00e4 guards_builtin_unreachable
/home/mjires/git/GCC/master/gcc/ipa-fnsummary.cc:2730
0x14c04d2 find_necessary_statements
/home/mjires/git/GCC/master/gcc/ipa-fnsummary.cc:2805
0x14c0c6b analyze_function_body
/home/mjires/git/GCC/master/gcc/ipa-fnsummary.cc:2931
0x14c3257 compute_fn_summary(cgraph_node*, bool)
/home/mjires/git/GCC/master/gcc/ipa-fnsummary.cc:3473
0x14c3324 compute_fn_summary_for_current
/home/mjires/git/GCC/master/gcc/ipa-fnsummary.cc:3503
0x14c8d8c execute
/home/mjires/git/GCC/master/gcc/ipa-fnsummary.cc:5158
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.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap
--enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250116 (experimental) (GCC)
[Bug c++/118515] New: [15] Incorrect error message:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118515
Bug ID: 118515
Summary: [15] Incorrect error message:
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor.pugin at gmail dot com
Target Milestone: ---
template auto b() {}
auto c() { return b(0); }
gives (stripped):
note: candidate 1: 'template< > auto b()'
See https://godbolt.org/z/P7x3EEnhc
[Bug c++/118515] [15] Incorrect error message:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118515
--- Comment #1 from Egor Pugin ---
Actually the output is the same since gcc-6.
from gcc-4.6 to gcc-5 output is:
note: candidate: template > auto b()
Slightly updated example:
template void b() {}
void c() { b(0); }
Is considered an error at all or it was made such
intentionally?
[Bug tree-optimization/118517] ICE in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118517 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- DSE issue is tracked as PR 117892 so this is a Dup of bug 117892. *** This bug has been marked as a duplicate of bug 117892 ***
[Bug ipa/117892] [15 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in single_succ_edge, at basic-block.h:332 since r15-5336-gcee7d080d5c2a5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117892 Andrew Pinski changed: What|Removed |Added CC||mjires at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- *** Bug 118517 has been marked as a duplicate of this bug. ***
[Bug c++/118518] New: gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518
Bug ID: 118518
Summary: gcc 14.2.1 nvptx cross compiler complains about alias
definitions in a struct with two constructors that are
not aliases
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: schulz.benjamin at googlemail dot com
Target Milestone: ---
Created attachment 60176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60176&action=edit
mdspan template classes
Hi there,
I tried to write my own version of the new mdspan class, but one which works
with non-compile time extents (i.e. which can be set by the input) and with gpu
offload support. The following c++23 code contains interesting algorithms for
matrix multiplication (Strassen Algorithm, and Winograd version of the Strassen
Algorithm) as well as some advanced and new algorithms for Cholesky, LU and QR
decomposition. It has two interfaces, one that uses the stl, with functions
that can work on gpu and may offload parts of the code at gpu, and another with
functions that can entirely reside on gpu.
It is certainly a bit more advanced than small openmp test cases. It uses
target teams, parallel for and simd instructions, as well as declare target
areas with functions on the target, memory allocation, pointer arithmetic for
sub-arrays.
It thus represents a nice compiler test. On clang, it compiles at least. but
the function offload fails for some reason on clang. and the winograd version
has, in clang, a problem with the omp runtime.
On gcc, it does not even compile.
the options:
-fopenmp -foffload=nvptx-none -fcf-protection=none -fno-stack-protector
-std=c++23 -no-pie lrt lm lc lstdc++
make gcc claim that "alias definitions" would not be allowed in this
configuration...
[100%] Linking CXX executable arraytest
/usr/bin/cmake -E cmake_link_script CMakeFiles/arraytest.dir/link.txt
--verbose=1
/home/benni/projects/arraylibrary/mdspan.h:356:22: Fehler: Alias-Definitionen
werden in dieser Konfiguration nicht unterstützt
356 | template datastruct::datastruct(
| ^
/home/benni/projects/arraylibrary/mdspan.h:386:22: Fehler: Alias-Definitionen
werden in dieser Konfiguration nicht unterstützt
386 | template datastruct::datastruct(
| ^
nvptx mkoffload: schwerwiegender Fehler:
/usr/bin/x86_64-pc-linux-gnu-accel-nvptx-none-gcc gab Ende-Status 1 zurück
but if we look at the sourcecode, we get this, which do not look like aliases.
Probably gcc has difficulties with the offloaded functions which may be aliases
generated by the compiler?
#pragma omp begin declare target
template datastruct::datastruct(
T* data,
size_t pdatalength,
bool rowm,
size_t rank,
size_t* extents,
size_t* strides,
bool compute_datalength,
bool compute_strides_from_extents
) : pdata(data),
pextents(extents),
pstrides(strides),
pdatalength(pdatalength),
prank(rank),
prowmayor(rowm)
{
if(compute_strides_from_extents==true && pextents!=nullptr &&
pstrides!=nullptr && rank !=0)
{
fill_strides(pextents,pstrides,rank,rowm);
}
if(compute_datalength==true && pextents!=nullptr && pstrides!=nullptr &&
rank !=0)
{
pdatalength=compute_data_length(pextents,pstrides,rank);
}
}
#pragma omp end declare target
#pragma omp begin declare target
template datastruct::datastruct(
T* data,
size_t datalength,
bool rowm,
size_t rows,
size_t cols,
size_t* extents,
size_t* strides,
bool compute_datalength,
bool compute_strides_from_extents
) : pdata(data),
pextents(extents),
pstrides(strides),
pdatalength(datalength),
prank(2),
prowmayor(rowm)
{
if(extents!=nullptr)
{
pextents[0]=(rowm==true)?rows:cols;
pextents[1]=(rowm==true)?cols:rows;
}
if(pstrides!=nullptr && compute_strides_from_extents)
{
pstrides[0]=(rowm==true)? cols:1;
pstrides[1]=(rowm==true)?1: rows;
}
if(compute_datalength==true && extents!=nullptr && strides!=nullptr)
{
pdatalength=(rows-1) * strides[0]+(cols-1)*strides[1]+1;
}
}
#pragma omp end declare target
#pragma omp begin declare target
template datastruct::datastruct(
T* data,
size_t datalength,
bool rowm,
bool rowvector,
size_t noelements,
size_t* extents,
size_t* strides,
bool compute_datalength,
bool compute_strides_from_extents
) : pdata(data),
pextents(extents),
pstrides(strides),
pdatalength(datalength),
prank(1),
prowmayor(true)
{
if(extents!=nullptr)
{
pextents[0]=noelements;
}
if(pstrides!=nullptr && compute_strides_from_extents)
{
if(rowvector)
pstrides[0]=(rowm==true)? 1:noelements;
[Bug c++/118509] [14/15 regression] Front-end produced uninitialized memory reference when compiling Nektar since r15-4595-gb25d3201b6338d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509 --- Comment #2 from Jakub Jelinek --- Trying to reduce it now...
[Bug c++/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 Benjamin Schulz changed: What|Removed |Added Target|nvptx | Component|target |c++ --- Comment #3 from Benjamin Schulz --- i use this configuration ~/projects/arraylibrary $ eselect gcc list [1] nvptx-none-14 * [2] x86_64-pc-linux-gnu-13 [3] x86_64-pc-linux-gnu-14 * gcc (Gentoo 14.2.1_p20241221 p7) 14.2.1 20241221 Copyright (C) 2024 Free Software Foundation, Inc.
[Bug c++/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #2 from Benjamin Schulz --- Created attachment 60178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60178&action=edit cmakelists.txt
[Bug c++/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #1 from Benjamin Schulz --- Created attachment 60177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60177&action=edit main.cpp
[Bug tree-optimization/115825] [12/13/14 Regression] Loop unrolling increases code size with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825 --- Comment #27 from Segher Boessenkool --- > This is a GIMPLE pass which has no idea what the backend will expand > __builtin_darn() to. So you are saying >90% of builtins now need to say they are pure and const (which makes totally no sense for things not touching memory)? It never was like this, only things that do touch memory at all ever looked at those attributes :-(
[Bug c++/118214] [15 regression] OpenTTD test failure with C++ large initializer since r15-6339-g40f243e9179667
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118214 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3191d7404bb9c2f53554d7c7f50dfb73b5a78726 commit r15-6958-g3191d7404bb9c2f53554d7c7f50dfb73b5a78726 Author: Jakub Jelinek Date: Thu Jan 16 17:25:24 2025 +0100 c++: Fix up reshape_* RAW_DATA_CST handling [PR118214] The embed-17.C testcase is miscompiled and pr118214.C testcase used to be miscompiled on the trunk before I've temporarily reverted the r15-6339 C++ large initializer speed-up commit in r15-6448. The problem is that reshape_* is only sometimes allowed to modify the given CONSTRUCTOR in place (when reuse is true, so first_initializer_p && (complain & tf_error) && !CP_AGGREGATE_TYPE_P (elt_type) && !TREE_SIDE_EFFECTS (first_initializer_p) ) and at other times is not allowed to change it. But the RAW_DATA_CST handling was modifying those in place always, by peeling off whatever was needed for the processing of the current element or set of elements and leaving the rest in the original CONSTRUCTOR_ELTS, either as RAW_DATA_CST with adjusted RAW_DATA_POINTER/RAW_DATA_LENGTH, or turning it into INTEGER_CST if it would be a RAW_DATA_LENGTH == 1 RAW_DATA_CST. The following patch fixes that by adding raw_idx member into struct reshape_iter where we for the RAW_DATA_CST current elements track offset into the current RAW_DATA_CST (how many elements were processed from it already) and modifying the original CONSTRUCTOR_ELTS only if reuse is true and we used the whole RAW_DATA_CST (with zero raw_idx); which means just modifying its type in place. 2025-01-16 Jakub Jelinek PR c++/118214 * decl.cc (struct reshape_iter): Add raw_idx member. (cp_maybe_split_raw_data): Add inc_cur parameter, set *inc_cur, don't modify original CONSTRUCTOR, use d->raw_idx to track index into a RAW_DATA_CST d->cur->value. (consume_init): Adjust cp_maybe_split_raw_data caller, increment d->cur when cur_inc is true. (reshape_init_array_1): Don't modify original CONSTRUCTOR when handling RAW_DATA_CST d->cur->value and !reuse, instead use d->raw_idx to track index into RAW_DATA_CST. (reshape_single_init): Initialize iter.raw_idx. (reshape_init_class): Adjust for introduction of d->raw_idx, adjust cp_maybe_split_raw_data caller, do d->cur++ if inc_cur rather than when it returns non-NULL. (reshape_init_r): Check for has_designator_problem for second half of _Complex earlier, also check for error_operand_p (d->cur->value). Use consume_init instead of cp_maybe_split_raw_data with later conditional d->cur++. (reshape_init): Initialize d.raw_idx. * g++.dg/cpp/embed-17.C: New test. * g++.dg/cpp0x/pr118214.C: New test.
[Bug c++/118396] [15 regression] -O1+ leads to reading uninitialized data when virtual destructor is present since r15-6369-gfa99002538bc91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396
--- Comment #12 from Marek Polacek ---
So I think I'll test this:
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8871,9 +8871,17 @@ cxx_eval_outermost_constant_expr (tree t, bool
allow_non_constant,
/* Turn off -frounding-math for manifestly constant evaluation. */
warning_sentinel rm (flag_rounding_math,
ctx.manifestly_const_eval == mce_true);
- tree type = (object
- ? cv_unqualified (TREE_TYPE (object))
- : initialized_type (t));
+ tree type;
+ if (object)
+{
+ type = cv_unqualified (TREE_TYPE (object));
+ /* If there is an object to initialize, make sure we don't throw
+away the initializer. */
+ gcc_assert (!VOID_TYPE_P (initialized_type (t)) || constexpr_dtor);
+}
+ else
+type = initialized_type (t);
+
tree r = t;
bool is_consteval = false;
if (VOID_TYPE_P (type))
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index c7074b00cef..283c0fa3e26 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1475,7 +1475,9 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
cp_walk_tree (&init, cp_fold_r, data, NULL);
cp_walk_tree (&TARGET_EXPR_CLEANUP (stmt), cp_fold_r, data, NULL);
*walk_subtrees = 0;
- if (!flag_no_inline)
+ /* Only attempt to evaluate the initializer if we're inlining and
+the TARGET_EXPR is simple. */
+ if (!flag_no_inline && !VOID_TYPE_P (TREE_TYPE (init)))
{
tree folded = maybe_constant_init (init, TARGET_EXPR_SLOT (stmt));
if (folded != init && TREE_CONSTANT (folded))
[Bug target/118512] [15 regression] Failed bootstrap on sparc (Error: Hardware capability "vis3b" not enabled for "fpcmpule8".)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118512 --- Comment #6 from Sam James --- (In reply to Eric Botcazou from comment #5) > The OSA 2015 document says that VIS3 & VIS 3B are supported since SPARC T3 > (Niagara 3), in particular by SPARC T4 (Niagara 4). > > What's the command line passed to the assembler by GCC exactly? # Using 14 assembly $ /var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/build/./prev-gcc/as -v -I - -I . -I ada/generated -I ada -I /var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada -I ada/libgnat -I /var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/libgnat -I ada/gcc-interface -I /var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/gcc-interface --gdwarf-5 -s -K PIC -xarch=sparc4 -64 -no-undeclared-regs -relax -o ada/errout.o ada/errout # Using 15 assembly $ /var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/build/./prev-gcc/as -v -I - -I . -I ada/generated -I ada -I /var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada -I ada/libgnat -I /var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/libgnat -I ada/gcc-interface -I /var/tmp/portage/sys-devel/gcc-15.0.0_pre20250112-r2/work/gcc-15-20250112/gcc/ada/gcc-interface --gdwarf-5 -s -K PIC -xarch=sparc4 -64 -no-undeclared-regs -relax -o ada/errout.o ada/errout.s.15 GNU assembler version 2.43.1 (sparc64-unknown-linux-gnu) using BFD version (Gentoo 2.43 p3) 2.43.1 ada/errout.s.15: Assembler messages: ada/errout.s.15:10660: Error: Hardware capability "vis3b" not enabled for "fpcmpule8". ada/errout.s.15:11823: Error: Hardware capability "vis3b" not enabled for "fpcmpule8". ada/errout.s.15:12020: Error: Hardware capability "vis3b" not enabled for "fpcmpule8". ada/errout.s.15:12655: Error: Hardware capability "vis3b" not enabled for "fpcmpule8". ada/errout.s.15:13429: Error: Hardware capability "vis3b" not enabled for "fpcmpule8". ada/errout.s.15:14604: Error: Hardware capability "vis3b" not enabled for "fpcmpule8". ada/errout.s.15:15440: Error: Hardware capability "vis3b" not enabled for "fpcmpule8".
[Bug c++/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 Benjamin Schulz changed: What|Removed |Added Target|nvptx | Component|target |c++ --- Comment #4 from Benjamin Schulz --- and by the way, feel free to use this file for testing purposes. I guess it uses more involved things than a simpe test file. Because of its complexity, it may have own bugs, but since uses many openmp features, it may be an interesting test case. One thing that fails in clang on runtime is the function offload, despite i think i do this according to the openmp standard. another thing that fails in clang on runtime is the attempt to mimic the multiplication with "tiles", where only a subset of the matrix array data is uploaded to the gpu. Once one can compile the file, one can test all these things. Also, one can test memory allocation. the algorithms make use of sub-arrays, pointer arithmetic, allocation and de-allocation of memory and so on. So feel free to test it. On the host, the computations work.
[Bug c/118519] New: Escaped line breaks in the middle of a token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118519
Bug ID: 118519
Summary: Escaped line breaks in the middle of a token
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alx at kernel dot org
Target Milestone: ---
Once upon a time, this probably made sense due to hardware or software
limitations. These days, it doesn't make sense anymore.
We should add a diagnostic when an escaped line break breaks a token.
alx@devuan:~/tmp/gcc$ cat split.c
#define A\
B \
4\
2
int
ma\
in(void)
{
return AB;
}
alx@devuan:~/tmp/gcc$ cc -Wall -Wextra split.c
alx@devuan:~/tmp/gcc$ ./a.out
alx@devuan:~/tmp/gcc$ echo $?
42
---
Or:
alx@devuan:~/tmp/gcc$ cat split.c
#d\
e\
f\
i\
n\
e \
A\
B \
4\
2
i\
n\
t
m\
a\
i\
n
(
v\
o\
i\
d)
{
r\
e\
t\
u\
r\
n AB;
}
alx@devuan:~/tmp/gcc$ cc -Wall -Wextra split.c
alx@devuan:~/tmp/gcc$ ./a.out; echo $?
42
[Bug tree-optimization/118514] [15 regression] wrong code at -O{1,s,3} on x86_64-linux-gnu since r15-6360-g6d5df5133c5dd8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118514 Sam James changed: What|Removed |Added Last reconfirmed||2025-01-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/118520] New: compiles with clang on openmp target, but gcc fails to compile with unresolved symbol __cxa_throw_bad_array_new_length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118520 Bug ID: 118520 Summary: compiles with clang on openmp target, but gcc fails to compile with unresolved symbol __cxa_throw_bad_array_new_length Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: schulz.benjamin at googlemail dot com Target Milestone: --- Created attachment 60179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60179&action=edit openmp offload test for simple pointer arithmetic the attached file compiles with clang and runs on target, but gcc -O3 -fopenmp -foffload=nvptx-none -fcf-protection=none -fno-stack-protector -no-pie ./main.cpp -lm -lstdc++ -lrt yields: unresolved symbol __cxa_throw_bad_array_new_length If it would run, its results would be rather interesting, since in clang the running file shows rundime problems, when the lines that are commented out in the source-code, are activated. I have two devices, one gpu and one cpu, yet the omp device number (at least on clang) is always 1. This confuses the target enter data and target exit data commands of openmp. If i set them to work on device(1), they will, on clang silently work on the host. If i run them on device(0), the mat(alloc: ) preprocessor directive will erase data on the host. But that is for clang. For gcc, this small test file does not even compile... I guess that is because there is a new command in a target region? or because of whatever..., but well, i suspect that i have the c++ language available at the target?
[Bug c++/118516] [12/13/14/15 Regression] Misleading error message "call to non-'constexpr' function" when loop variable is not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118516 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Marek Polacek --- Mine then.
[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544 --- Comment #15 from Andrew Stubbs --- BTW, if you're calling "new" in the offload kernel then you're probably "doing it wrong", even when we do implement full C++ support. Offload kernels are for hot code, executed many times, and memory allocation is inherently slow. On AMDGCN, "malloc" uses Newlib's heap support and gets serialized via a global lock. Likewise for "free". On NVPTX, the implementation is provided by the PTX finalizer, so may be better optimized, but I still don't recommend it. I'm assuming you're using printf for debug and testing only, so that's fine, but it definitely has no place in hot code either.
[Bug tree-optimization/118522] New: ICE: 'verify_gimple' failed: mismatching comparison operand types with _BitInt(32) cast to double and compared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118522 Bug ID: 118522 Summary: ICE: 'verify_gimple' failed: mismatching comparison operand types with _BitInt(32) cast to double and compared Product: gcc Version: 15.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 CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 60180 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60180&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc testcase.c testcase.c: In function 'foo': testcase.c:4:1: error: mismatching comparison operand types 4 | foo(unsigned short p) | ^~~ int _BitInt(32) _3 = _1 == b.0_2; testcase.c:4:1: internal compiler error: 'verify_gimple' failed 0x2de1b21 internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic-global-context.cc:517 0x16d448e verify_gimple_in_seq(gimple*, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5333 0x130013a gimplify_body(tree_node*, bool) /repo/gcc-trunk/gcc/gimplify.cc:20653 0x1300355 gimplify_function_tree(tree_node*) /repo/gcc-trunk/gcc/gimplify.cc:20779 0x110ab67 cgraph_node::analyze() /repo/gcc-trunk/gcc/cgraphunit.cc:689 0x110d7e7 analyze_functions /repo/gcc-trunk/gcc/cgraphunit.cc:1265 0x110e79d symbol_table::finalize_compilation_unit() /repo/gcc-trunk/gcc/cgraphunit.cc:2574 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-20250116125444-r15-6956-g80b52301e8ee9a-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.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 --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-20250116125444-r15-6956-g80b52301e8ee9a-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.1 20250116 (experimental) (GCC)
[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 --- Comment #10 from GCC Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:4e20914d3306d8898ce586313a40fb92ef0b8964 commit r15-6961-g4e20914d3306d8898ce586313a40fb92ef0b8964 Author: Sandra Loosemore Date: Tue Jan 14 23:27:53 2025 + OpenMP: Add C support for metadirectives and dynamic selectors. Additional shared C/C++ testcases are included in a subsequent patch in this series. gcc/c-family/ChangeLog PR middle-end/112779 PR middle-end/113904 * c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_META. (c_omp_expand_variant_construct): Declare. * c-gimplify.cc: Include omp-general.h. (genericize_omp_metadirective_stmt): New. (c_genericize_control_stmt): Add case for OMP_METADIRECTIVE. * c-omp.cc (c_omp_directives): Fix entries for metadirective. (c_omp_expand_variant_construct_r): New. (c_omp_expand_variant_construct): New. * c-pragma.cc (omp_pragmas): Add metadirective. * c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_METADIRECTIVE. gcc/c/ChangeLog PR middle-end/112779 PR middle-end/113904 * c-parser.cc (struct c_parser): Add omp_metadirective_state field. (c_parser_skip_to_end_of_block_or_statement): Add metadirective_p parameter and handle skipping over the parentheses in a "for" statement. (struct omp_metadirective_parse_data): New. (mangle_metadirective_region_label): New. (c_parser_label): Mangle label names in a metadirective body. (c_parser_statement_after_labels): Likewise. (c_parser_pragma): Handle PRAGMA_OMP_METADIRECTIVE. (c_parser_omp_context_selector): Allow arbitrary expressions in device_num and condition properties. (c_parser_omp_assumption_clauses): Handle C_OMP_DIR_META. (analyze_metadirective_body): New. (c_parser_omp_metadirective): New. gcc/testsuite/ PR middle-end/112779 * c-c++-common/gomp/declare-variant-2.c: Adjust expected output for C. * gcc.dg/gomp/metadirective-1.c: New. Co-Authored-By: Kwok Cheung Yeung Co-Authored-By: Sandra Loosemore
[Bug middle-end/112779] [OpenMP] Support omp Metadirectives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112779 --- Comment #3 from GCC Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:4e20914d3306d8898ce586313a40fb92ef0b8964 commit r15-6961-g4e20914d3306d8898ce586313a40fb92ef0b8964 Author: Sandra Loosemore Date: Tue Jan 14 23:27:53 2025 + OpenMP: Add C support for metadirectives and dynamic selectors. Additional shared C/C++ testcases are included in a subsequent patch in this series. gcc/c-family/ChangeLog PR middle-end/112779 PR middle-end/113904 * c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_META. (c_omp_expand_variant_construct): Declare. * c-gimplify.cc: Include omp-general.h. (genericize_omp_metadirective_stmt): New. (c_genericize_control_stmt): Add case for OMP_METADIRECTIVE. * c-omp.cc (c_omp_directives): Fix entries for metadirective. (c_omp_expand_variant_construct_r): New. (c_omp_expand_variant_construct): New. * c-pragma.cc (omp_pragmas): Add metadirective. * c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_METADIRECTIVE. gcc/c/ChangeLog PR middle-end/112779 PR middle-end/113904 * c-parser.cc (struct c_parser): Add omp_metadirective_state field. (c_parser_skip_to_end_of_block_or_statement): Add metadirective_p parameter and handle skipping over the parentheses in a "for" statement. (struct omp_metadirective_parse_data): New. (mangle_metadirective_region_label): New. (c_parser_label): Mangle label names in a metadirective body. (c_parser_statement_after_labels): Likewise. (c_parser_pragma): Handle PRAGMA_OMP_METADIRECTIVE. (c_parser_omp_context_selector): Allow arbitrary expressions in device_num and condition properties. (c_parser_omp_assumption_clauses): Handle C_OMP_DIR_META. (analyze_metadirective_body): New. (c_parser_omp_metadirective): New. gcc/testsuite/ PR middle-end/112779 * c-c++-common/gomp/declare-variant-2.c: Adjust expected output for C. * gcc.dg/gomp/metadirective-1.c: New. Co-Authored-By: Kwok Cheung Yeung Co-Authored-By: Sandra Loosemore
