[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682 --- Comment #2 from Xi Ruoyao --- I applied the LoongArch port patch (upstream PR 678, config.guess and config.sub changes stripped and Makefile.am conflict resolved manually) and use autogen.sh to regenerate the build system. But libgo build still fails with: libtool: compile: /home/xry111/git-repos/gcc-build/./gcc/gccgo -B/home/xry111/git-repos/gcc-build/./gcc/ -B/home/xry111/gcc-trunk/loongarch64-unknown-linux-gnu/bin/ -B/home/xry111/gcc-trunk/loongarch64-unknown-linux-gnu/lib/ -isystem /home/xry111/gcc-trunk/loongarch64-unknown-linux-gnu/include -isystem /home/xry111/gcc-trunk/loongarch64-unknown-linux-gnu/sys-include -O2 -g -I . -c -fgo-pkgpath=internal/goarch ../../../gcc/libgo/go/internal/goarch/goarch.go zgoarch.go -fPIC -o internal/.libs/goarch.o zgoarch.go:7:14: error: expected ‘;’ or ‘)’ or newline 7 | _BigEndian = | ^ zgoarch.go:7:3: error: reference to undefined name ‘_BigEndian’ 7 | _BigEndian = | ^ ../../../gcc/libgo/go/internal/goarch/goarch.go:18:19: error: reference to undefined name ‘_BigEndian’ 18 | const BigEndian = _BigEndian | ^ ../../../gcc/libgo/go/internal/goarch/goarch.go:21:29: error: reference to undefined name ‘_DefaultPhysPageSize’ 21 | const DefaultPhysPageSize = _DefaultPhysPageSize | ^ ../../../gcc/libgo/go/internal/goarch/goarch.go:25:19: error: reference to undefined name ‘_PCQuantum’ 25 | const PCQuantum = _PCQuantum | ^ ../../../gcc/libgo/go/internal/goarch/goarch.go:28:20: error: reference to undefined name ‘_Int64Align’ 28 | const Int64Align = _Int64Align |^ ../../../gcc/libgo/go/internal/goarch/goarch.go:35:22: error: reference to undefined name ‘_MinFrameSize’ 35 | const MinFrameSize = _MinFrameSize | ^ ../../../gcc/libgo/go/internal/goarch/goarch.go:39:20: error: reference to undefined name ‘_StackAlign’ 39 | const StackAlign = _StackAlign |^
[Bug fortran/109003] New: memory leak in module loading (mio_formal_arglist)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109003 Bug ID: 109003 Summary: memory leak in module loading (mio_formal_arglist) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- valgrind complains when building SPEC 2017 521.wrf ==24177== 32 bytes in 2 blocks are possibly lost in loss record 66 of 2,272 ==24177==at 0x4C39571: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==24177==by 0x1C071F0: xcalloc (xmalloc.c:164) ==24177==by 0x766248: mio_formal_arglist (module.cc:3201) ==24177==by 0x766248: mio_symbol(gfc_symbol*) (module.cc:4586) ==24177==by 0x766836: load_needed(pointer_info*) (module.cc:5195) ==24177==by 0x7667E0: load_needed(pointer_info*) (module.cc:5154) ==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153) ==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153) ==24177==by 0x7667E0: load_needed(pointer_info*) (module.cc:5154) ==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153) ==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153) ==24177==by 0x7667D5: load_needed(pointer_info*) (module.cc:5153) ==24177==by 0x767C0B: read_module() (module.cc:5697) I'm not sure what actually happens, but I guess sym->formal is eventually replaced so the allocated memory gets dangling? Or we free some of the module memory later but not everything. It seems valgrind complains about a lot of leaks when modules are involved.
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #9 from Jonathan Wakely --- You can skip things not relevant to this issue by configuring with: --disable-multilib --disable-bootstrap --enable-languages=c++,c --disable-libcc1 --disable-libitm --disable-libvtv --disable-libgomp --disable-libsanitizer
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #8 from Andrew Pinski --- Plus you can use --disable-bootstrap and maybe not rebuild llvm and just set LD_LIBRARY_PATH.
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #7 from Andrew Pinski --- (In reply to Tom Stellard from comment #6) > (In reply to Andrew Pinski from comment #5) > > (In reply to Tom Stellard from comment #4) > > > This test case was passing with older versions of LLVM/Clang + gcc-13.0.1, > > > so I bisected it down to this commit: > > > https://github.com/llvm/llvm-project/commit/ > > > 6747fc07d1aa94e22622e278e5a02ba70675ac9b > > > > can you bisect GCC instead? > > I can try do you have any tips for speeding up the build? Maybe try before and after the revisions I mentioned first.
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #6 from Tom Stellard --- (In reply to Andrew Pinski from comment #5) > (In reply to Tom Stellard from comment #4) > > This test case was passing with older versions of LLVM/Clang + gcc-13.0.1, > > so I bisected it down to this commit: > > https://github.com/llvm/llvm-project/commit/ > > 6747fc07d1aa94e22622e278e5a02ba70675ac9b > > can you bisect GCC instead? I can try do you have any tips for speeding up the build?
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 --- Comment #14 from Martin Liška --- (In reply to Marek Polacek from comment #13) > I would really not like to do that, the false positives rate is pretty low. You right! I noticed the warning for about 3 packages of 3300 we have in a testing CI.
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Richard Biener --- Should be fixed now. I think the issue is likely latent earlier but unless we run into it in real world lets wait and see.
[Bug target/108738] compile-time and memory-hog in mdreorg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Keywords||compile-time-hog Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Biener --- This has been mitigated for GCC 13, in theory backporting is possible but there's a workaround available (-mno-stv), so I think that's not strictly necessary since the issue is quite old already.
[Bug target/108738] compile-time and memory-hog in mdreorg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:6010189923908501ca5b02bd1f4aee05d2283118 commit r13-6439-g6010189923908501ca5b02bd1f4aee05d2283118 Author: Richard Biener Date: Thu Mar 2 13:43:51 2023 +0100 target/108738 - limit STV chain discovery The following puts a hard limit on the inherently quadratic STV chain discovery. Without a limit for the compiler.i testcase in PR26854 we see at -O2 machine dep reorg : 574.45 ( 53%) with release checking while with the proposed limit it's machine dep reorg : 2.86 ( 1%) PR target/108738 * config/i386/i386.opt (--param x86-stv-max-visits): New param. * doc/invoke.texi (--param x86-stv-max-visits): Document it. * config/i386/i386-features.h (scalar_chain::max_visits): New. (scalar_chain::build): Add bitmap parameter, return boolean. (scalar_chain::add_insn): Likewise. (scalar_chain::analyze_register_chain): Likewise. * config/i386/i386-features.cc (scalar_chain::scalar_chain): Initialize max_visits. (scalar_chain::analyze_register_chain): When we exhaust max_visits, abort. Also abort when running into any disallowed insn. (scalar_chain::add_insn): Propagate abort. (scalar_chain::build): Likewise. When aborting amend the set of disallowed insn with the insns set. (convert_scalars_to_vector): Adjust. Do not convert aborted chains.
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:33ca5c92dfa7e2f591a838bb768d9d6eea56793b commit r13-6438-g33ca5c92dfa7e2f591a838bb768d9d6eea56793b Author: Richard Biener Date: Wed Mar 1 10:01:10 2023 +0100 debug/108772 - ICE with late debug generated with -flto When combining -g1 with -flto we run into the DIE location annotation machinery for globals calling dwarf2out_late_global_decl but not having any early generated DIE for function scope statics. In this process we'd generate a limbo DIE since also the function scope doesn't have any early generated DIE. The limbo handling then tries to force a DIE for the context chain which ultimatively fails and ICEs at the std namespace decl because at -g1 we don't represent that. The following avoids this situation by making sure to never generate any DIEs from dwarf2out_late_global_decl in the in_lto_p path for function scope globals but rely on DIE generation for the function to output a DIE for the local static (which doesn't happen for -g1). I explored a lot of other options to fix this but in the end this seems to be the most spot-on fix with the least risk of unwanted effects. PR debug/108772 * dwarf2out.cc (dwarf2out_late_global_decl): Do not generate a DIE for a function scope static. * g++.dg/lto/pr108772_0.C: New testcase.
[Bug tree-optimization/109002] -O1 -ftree-pre -ftree-partial-pre results in stall value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002 --- Comment #2 from Akihiko Odaki --- Oops. Replacing i++ with i = !i removes the undefined behavior while the bug still remains.
[Bug tree-optimization/109002] -O1 -ftree-pre -ftree-partial-pre results in stall value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002 --- Comment #1 from Andrew Pinski --- Note there will be undefined behavior when i become INT_MAx.
[Bug tree-optimization/109002] New: -O1 -ftree-pre -ftree-partial-pre results in stall value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002
Bug ID: 109002
Summary: -O1 -ftree-pre -ftree-partial-pre results in stall
value
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: akihiko.odaki at daynix dot com
Target Milestone: ---
The following should emit an executable which prints "a" forever, but the
actual compiled executable prints nothing and just hangs. It seems the code
sees a stall value of variable g.
gcc -O1 -ftree-pre -ftree-partial-pre -x c - <
int g;
int h;
int main(void)
{
for (int i = 0; ; i++) {
for (int j = 0; j < g; j++);
if (i & 1) {
if (h)
continue;
if (g)
puts("a");
g = 1;
}
}
}
EOF
I reproduced this bug with the current master. gcc -v says:
Using built-in specs.
COLLECT_GCC=/home/alarm/gcc-installation/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-bootstrap : (reconfigured)
../gcc/configure --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230302 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-mlittle-endian' '-mabi=lp64'
/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/cc1
-quiet -v -iprefix
/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/
/home/alarm/a.c -quiet -dumpbase a.c -dumpbase-ext .c -mlittle-endian
-mabi=lp64 -version -o /tmp/ccetU9yt.s
GNU C17 (GCC) version 13.0.1 20230302 (experimental)
(aarch64-unknown-linux-gnu)
compiled by GNU C version 12.1.0, GMP version 6.2.1, MPFR version
4.2.0, MPC version 1.3.1, isl version isl-0.25-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/../../../../aarch64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/include"
ignoring duplicate directory
"/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/include-fixed"
ignoring nonexistent directory
"/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/../../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/../../../../aarch64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/include
/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/include-fixed
/usr/local/include
/usr/include
End of search list.
Compiler executable checksum: 374b2759695ed1b72f52cb0f1847fbb3
COLLECT_GCC_OPTIONS='-v' '-mlittle-endian' '-mabi=lp64'
as -v -EL -mabi=lp64 -o /tmp/ccTu98hj.o /tmp/ccetU9yt.s
GNU assembler version 2.38 (aarch64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.38
COMPILER_PATH=/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/:/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/
LIBRARY_PATH=/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/:/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/:/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/../../../../lib64/:/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mlittle-endian' '-mabi=lp64' '-dumpdir' 'a.'
/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/collect2
-plugin
/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/liblto_plugin.so
-plugin-opt=/home/alarm/gcc-installation/usr/local/bin/../libexec/gcc/aarch64-unknown-linux-gnu/13.0.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccup8iGA.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr -dynamic-linker /lib/ld-linux-aarch64.so.1 -X -EL -maarch64linux
/lib/crt1.o /lib/crti.o
/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1/crtbegin.o
-L/home/alarm/gcc-installation/usr/local/bin/../lib/gcc/aarch64-unknown-linux-gnu/13.0.1
-L/home/alarm/
[Bug target/106770] powerpc64le: Unnecessary xxpermdi before mfvsrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770 --- Comment #12 from Surya Kumari Jangala --- (In reply to Jens Seifert from comment #6) > The left part of VSX registers overlaps with floating point registers, that > is why no register xxpermdi is required and mfvsrd can access all (left) > parts of VSX registers directly. > The xxpermdi x,y,y,3 indicates to me that gcc prefers right part of register > which might also cause the xxpermdi at the beginning. At the end the mystery > is why gcc adds 3 xxpermdi to the code. The 3rd xxpermdi is incorrect.
[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127 --- Comment #7 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:1e4122f1159ace52c114c011013adce25172d77b commit r13-6437-g1e4122f1159ace52c114c011013adce25172d77b Author: Alexandre Oliva Date: Fri Mar 3 01:47:00 2023 -0300 [PR100127] Test for coroutine header in clang-compatible tests The test is compatible with clang as well as gcc, but ISTM that testing for the __clang__ macro is just as potentially error-prone as macros that used to be GCC-specific are now defined in compilers that aim for GCC compatibility. Use a __has_include feature test instead. for gcc/testsuite/ChangeLog PR c++/100127 * g++.dg/coroutines/pr100127.C: Test for header rather than compiler macro. * g++.dg/coroutines/pr100772-a.C: Likewise. * g++.dg/coroutines/pr100772-b.C: Likewise.
[Bug c++/109001] New: “no declaration matches” for complicated non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109001
Bug ID: 109001
Summary: “no declaration matches” for complicated non-type
template parameters
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: headch at gmail dot com
Target Milestone: ---
I’m reasonably certain (but not completely) that this is valid code:
#include
#include
template
class C {
public:
template
C set();
};
template
template
C C::set() {
return {};
}
however, GCC rejects it with “error: no declaration matches ‘C(x, y)> C::set()’” on the out-of-body function definition. This
is accepted in GCC 11.3, as well as the latest versions of Clang and MSVC on
gcc.godbolt.org. Interestingly, GCC 12 also accepts the code if I change the
function definition (just the definition, not the in-body declaration) to use
trailing-return-type syntax:
#include
#include
template
class C {
public:
template
C set();
};
template
template
auto C::set() -> C {
return {};
}
[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682 --- Comment #1 from Xi Ruoyao --- Merging libffi is a big change and not suitable for stage 3 IMO. Can we can apply the LoongArch patch locally instead? It will not affect other targets and even if does not work perfectly on LoongArch we don't lose anything.
[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682 Xi Ruoyao changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||xry111 at gcc dot gnu.org Last reconfirmed||2023-03-03
[Bug target/109000] LoongArch: "unmatched" -mabi and -mfpu setting can break ABI silently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000 Xi Ruoyao changed: What|Removed |Added Known to fail||12.2.0, 13.0 Last reconfirmed||2023-03-03 Target||loongarch64-linux-gnu Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot gnu.org Ever confirmed|0 |1 Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |12.3 --- Comment #1 from Xi Ruoyao --- I've already made the patch. Just create a PR to track the issue.
[Bug target/109000] New: LoongArch: "unmatched" -mabi and -mfpu setting can break ABI silently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
Bug ID: 109000
Summary: LoongArch: "unmatched" -mabi and -mfpu setting can
break ABI silently
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
$ cat t.c
double t(double x)
{
return 1.0 / x;
}
$ ~/gcc-trunk/bin/gcc t.c -O2 -c -mabi=lp64s
$ readelf -a t.o | grep FLOAT
Flags: 0x41, SOFT-FLOAT, OBJ-v1
$ objdump -d t.o
t.o: file format elf64-loongarch
Disassembly of section .text:
:
0: 01145800frecip.d$fa0, $fa0
4: 4c20jirl$zero, $ra, 0
So we now have a SOFT-FLOAT object using FPR for arguments and return values
:(.
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #5 from Andrew Pinski --- (In reply to Tom Stellard from comment #4) > This test case was passing with older versions of LLVM/Clang + gcc-13.0.1, > so I bisected it down to this commit: > https://github.com/llvm/llvm-project/commit/ > 6747fc07d1aa94e22622e278e5a02ba70675ac9b can you bisect GCC instead?
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #4 from Tom Stellard --- This test case was passing with older versions of LLVM/Clang + gcc-13.0.1, so I bisected it down to this commit: https://github.com/llvm/llvm-project/commit/6747fc07d1aa94e22622e278e5a02ba70675ac9b
[Bug d/108877] Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from ibuclaw at gcc dot gnu.org --- Fix committed and backported.
[Bug d/108877] Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:c90e68bffa37edd655dd2f5d14bb7b213c9e2431 commit r10-11235-gc90e68bffa37edd655dd2f5d14bb7b213c9e2431 Author: Iain Buclaw Date: Mon Feb 27 20:46:18 2023 +0100 d: Fix ICE on explicit immutable struct import [PR108877] Const and immutable types are built as variants of the type they are derived from, and TYPE_STUB_DECL is not set for these variants. PR d/108877 gcc/d/ChangeLog: * imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call make_import on TYPE_MAIN_VARIANT. (ImportVisitor::visit (AggregateDeclaration *)): Likewise. (ImportVisitor::visit (ClassDeclaration *)): Likewise. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr108877a.d: New test. * gdc.dg/pr108877.d: New test. (cherry picked from commit ce1cea3e22f58bbddde017f8a92e59bae8892339)
[Bug d/108877] Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:fe6cd1ba23ecbce9c0206c08db182cb5164e3b7d commit r11-10554-gfe6cd1ba23ecbce9c0206c08db182cb5164e3b7d Author: Iain Buclaw Date: Mon Feb 27 20:46:18 2023 +0100 d: Fix ICE on explicit immutable struct import [PR108877] Const and immutable types are built as variants of the type they are derived from, and TYPE_STUB_DECL is not set for these variants. PR d/108877 gcc/d/ChangeLog: * imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call make_import on TYPE_MAIN_VARIANT. (ImportVisitor::visit (AggregateDeclaration *)): Likewise. (ImportVisitor::visit (ClassDeclaration *)): Likewise. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr108877a.d: New test. * gdc.dg/pr108877.d: New test. (cherry picked from commit ce1cea3e22f58bbddde017f8a92e59bae8892339)
[Bug d/108877] Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:2583365912c8700abe1f4a23ed611acb80fac09d commit r12-9212-g2583365912c8700abe1f4a23ed611acb80fac09d Author: Iain Buclaw Date: Mon Feb 27 20:46:18 2023 +0100 d: Fix ICE on explicit immutable struct import [PR108877] Const and immutable types are built as variants of the type they are derived from, and TYPE_STUB_DECL is not set for these variants. PR d/108877 gcc/d/ChangeLog: * imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call make_import on TYPE_MAIN_VARIANT. (ImportVisitor::visit (AggregateDeclaration *)): Likewise. (ImportVisitor::visit (ClassDeclaration *)): Likewise. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr108877a.d: New test. * gdc.dg/pr108877.d: New test. (cherry picked from commit ce1cea3e22f58bbddde017f8a92e59bae8892339)
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #12 from David Edelsohn --- We're working to add a Power10 system to the Compile Farm. The systems are at OSUOSL, but Power10 doesn't have official KVM support so the interface to the OpenStack management system is complicated.
[Bug rtl-optimization/108999] New: Maybe LRA produce inaccurate hardware register occupancy information for subreg operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108999
Bug ID: 108999
Summary: Maybe LRA produce inaccurate hardware register
occupancy information for subreg operand
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lehua.ding at rivai dot ai
Target Milestone: ---
The problem code on the compiler explorer is here:
https://godbolt.org/z/GaGWEahPY
The problem is that the line `mov z1.d, z4.d` of the assembly code[1] is
unnecessary. I find the reason is the LRA pass[2] thinks the hard registers
`(subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) [16, 16])` occupied is in
conflict with `(reg/v:VNx2DI 98 [ v19 ])`[3]. That is not true because r103
occupied 32 and 33, and r98 occupied 34 according to the dump information of
IRA[4]. This is because the function process_alt_operands in lra-constraints.cc
source file[5]. When it checks whether the operand 0 of insn 39 is in conflict
with other operands of insn 39, it set operand 0 occupied 33 and 34 according
to the mode(`biggest_mode[i]`) and the start hard regno
33(`clobbered_hard_regno`). The mode it used is VNx4DI, I think it should use
Vnx2DI which is the proper mode for the entire operand 0. So for getting the
occupied hard register of the normal subreg operand, it is maybe too wider if
use the inner reg's mode.
References:
[1] assembly code
```
subreg_coalesce5:
mov p1.b, p0.b
ld2d{z0.d - z1.d}, p0/z, [x0]
cmp w1, 0
ble .L2
sxtwx1, w1
mov x0, 0
.L3:
ld1dz3.d, p1/z, [x2, x0, lsl 3]
ld1dz2.d, p1/z, [x3, x0, lsl 3]
add x0, x0, 1
movprfx z4.d, p0/z, z1.d
mla z4.d, p0/m, z3.d, z2.d
movprfx z0.d, p0/z, z0.d
mla z0.d, p0/m, z3.d, z2.d
mov z1.d, z4.d
cmp x1, x0
bne .L3
.L2:
st2d{z0.d - z1.d}, p0, [x4]
ret
```
[2] partial content of LRA dump info
```
...
0 Early clobber: reject++
0 Conflict early clobber reload: reject--
alt=0,overall=6,losers=1,rld_nregs=0
0 Early clobber: reject++
alt=1,overall=1,losers=0,rld_nregs=0
Choosing alt 1 in insn 36: (0) (1) Upl (2) w (3) w (4) 0 (5)
Dz {*cond_fmavnx2di_any}
0 Early clobber: reject++
0 Matched conflict early clobber reloads: reject--
alt=0,overall=6,losers=1,rld_nregs=0
0 Early clobber: reject++
0 Conflict early clobber reload: reject--
alt=1,overall=6,losers=1,rld_nregs=0
0 Early clobber: reject++
2 Matching earlyclobber alt: reject--
alt=2,overall=6,losers=1,rld_nregs=1
0 Early clobber: reject++
3 Matching earlyclobber alt: reject--
alt=3,overall=6,losers=1,rld_nregs=1
0 Early clobber: reject++
5 Matching earlyclobber alt: reject--
5 Non-pseudo reload: reject+=2
5 Non input pseudo reload: reject++
alt=4,overall=9,losers=1 -- refuse
Staticly defined alt reject+=6
0 Early clobber: reject++
5 Non-pseudo reload: reject+=2
5 Non input pseudo reload: reject++
alt=5,overall=16,losers=1 -- refuse
Choosing alt 0 in insn 39: (0) = (1) Upl (2) w (3) w (4) w (5)
Dz {*cond_fmavnx2di_any}
Creating newreg=117, assigning class FP_REGS to r117
39:
r117:VNx2DI=unspec[r104:VNx16BI#0,r97:VNx2DI*r98:VNx2DI+r103:VNx4DI#[16,16],const_vector]
284
REG_DEAD r98:VNx2DI
REG_DEAD r97:VNx2DI
Inserting insn reload after:
76: r103:VNx4DI#[16,16]=r117:VNx2DI
...
```
[3] partial rtl of IRA pass
```lisp
(insn 36 43 37 4 (set (subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) 0)
(unspec:VNx2DI [
(subreg:VNx2BI (reg/v:VNx16BI 104 [ pg ]) 0)
(plus:VNx2DI (mult:VNx2DI (reg/v:VNx2DI 97 [ v18 ])
(reg/v:VNx2DI 98 [ v19 ]))
(subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) 0))
(const_vector:VNx2DI repeat [
(const_int 0 [0])
])
] UNSPEC_SEL)) "/app/example.c":13:25 discrim 1 7465
{*cond_fmavnx2di_any}
(nil))
(insn 39 37 40 4 (set (subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) [16, 16])
(unspec:VNx2DI [
(subreg:VNx2BI (reg/v:VNx16BI 104 [ pg ]) 0)
(plus:VNx2DI (mult:VNx2DI (reg/v:VNx2DI 97 [ v18 ])
(reg/v:VNx2DI 98 [ v19 ]))
(subreg:VNx2DI (reg/v:VNx4DI 103 [ result ]) [16, 16]))
(const_vector:VNx2DI repeat [
(const_int 0 [0])
])
] UNSPEC_SEL)) "/app/example.c":14:25
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #11 from Rui Ueyama --- I'll try to add a POWER10 support to mold using Qemu.
[Bug d/108167] d: internal compiler error: in binary_op, at d/expr.cc:117
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from ibuclaw at gcc dot gnu.org --- Fix has already been committed as part of a previous upstream/dmd merge. Added test.
[Bug d/108945] [13.0] d: vector float comparison doesn't result in 0 or -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from ibuclaw at gcc dot gnu.org --- Fix committed.
[Bug d/108946] [13.0] d: Identity comparison of vectors not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from ibuclaw at gcc dot gnu.org --- Fix committed.
[Bug d/108877] Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:ce1cea3e22f58bbddde017f8a92e59bae8892339 commit r13-6432-gce1cea3e22f58bbddde017f8a92e59bae8892339 Author: Iain Buclaw Date: Mon Feb 27 20:46:18 2023 +0100 d: Fix ICE on explicit immutable struct import [PR108877] Const and immutable types are built as variants of the type they are derived from, and TYPE_STUB_DECL is not set for these variants. PR d/108877 gcc/d/ChangeLog: * imports.cc (ImportVisitor::visit (EnumDeclaration *)): Call make_import on TYPE_MAIN_VARIANT. (ImportVisitor::visit (AggregateDeclaration *)): Likewise. (ImportVisitor::visit (ClassDeclaration *)): Likewise. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr108877a.d: New test. * gdc.dg/pr108877.d: New test.
[Bug d/108946] [13.0] d: Identity comparison of vectors not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108946 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:929c6b8cd12a3bd338a4c250274a9d86da5b2ea7 commit r13-6433-g929c6b8cd12a3bd338a4c250274a9d86da5b2ea7 Author: Iain Buclaw Date: Fri Mar 3 00:00:44 2023 +0100 d: Allow vectors to be compared for identity [PR108946] Vector equality and comparisons are now accepted by the language implementation, but identity wasn't. Implement it as an extra integer comparison of the bit-casted bitmask. PR d/108946 gcc/d/ChangeLog: * d-target.cc (Target::isVectorOpSupported): Allow identity ops. * expr.cc (ExprVisitor::visit (IdentityExp *)): Handle vector identity comparisons. gcc/testsuite/ChangeLog: * gdc.dg/simd2a.d: Update test. * gdc.dg/simd2b.d: Likewise. * gdc.dg/simd2c.d: Likewise. * gdc.dg/simd2d.d: Likewise. * gdc.dg/simd2e.d: Likewise. * gdc.dg/simd2f.d: Likewise. * gdc.dg/simd2g.d: Likewise. * gdc.dg/simd2h.d: Likewise. * gdc.dg/simd2i.d: Likewise. * gdc.dg/simd2j.d: Likewise.
[Bug d/108167] d: internal compiler error: in binary_op, at d/expr.cc:117
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108167 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:33a7811896a6c8e6fa71e385dbdf5013d833a116 commit r13-6431-g33a7811896a6c8e6fa71e385dbdf5013d833a116 Author: Iain Buclaw Date: Mon Feb 27 18:38:53 2023 +0100 d: Add test for PR d/108167 to the testsuite [PR108167] The D front-end implementation got fixed in upstream, add test to the gdc testsuite to check we don't regress on it. PR d/108167 gcc/testsuite/ChangeLog: * gdc.dg/pr108167.d: New test.
[Bug d/108945] [13.0] d: vector float comparison doesn't result in 0 or -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108945 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:51af8a6401eea726d3498e6b2aba456b6af246d6 commit r13-6430-g51af8a6401eea726d3498e6b2aba456b6af246d6 Author: Iain Buclaw Date: Mon Feb 27 16:02:21 2023 +0100 d: vector float comparison doesn't result in 0 or -1 [PR108945] When comparing two vectors, the type of vector was used as the result of the condition result. This meant that for floating point comparisons, each value would either be `0.0' or `-1.0' reinterpreted as an integer, not the expected integral bitmask values `0' and `-1'. Instead, use the comparison type determined by truth_type_for as the result of the comparison. If a reinterpret is later required by the final conversion for generating CmpExp, it is still only going to reinterpret one integer kind as another. PR d/108945 gcc/d/ChangeLog: * d-codegen.cc (build_boolop): Evaluate vector comparison as the truth_type_for vector type. gcc/testsuite/ChangeLog: * gdc.dg/pr108945.d: New test.
[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997 --- Comment #4 from Andrew Pinski --- (In reply to Nikita Kniazev from comment #3) > For cond == 789 > if (cond_2(D) == 789) > goto ; [20.24%] > else > goto ; [79.76%] > > For cond != 789 > if (cond_2(D) != 789) > goto ; [48.88%] > else > goto ; [51.12%] an intergal type equaling a specific # is handled this way on purpose. Bool should be handled differently because it only has two values, 0/1. Anyways != is not handled specially except for the zero value case ...
[Bug c++/108998] [13 Regression] ICE in tsubst, at cp/pt.cc:16037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998 --- Comment #3 from waffl3x --- I made a mistake in my previous comment, the version on my system that fails is 12.2.1, sorry for any possible confusion.
[Bug c++/108998] [13 Regression] ICE in tsubst, at cp/pt.cc:16037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998 Marek Polacek changed: What|Removed |Added Target Milestone|--- |13.0 CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Priority|P3 |P1 Ever confirmed|0 |1 Summary|ICE in tsubst, at |[13 Regression] ICE in |cp/pt.cc:16037 |tsubst, at cp/pt.cc:16037 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2023-03-03 --- Comment #2 from Marek Polacek --- Started with r13-4730: commit 18499b9f848707aee42d810e99ac0a4c9788433c Author: Patrick Palka Date: Thu Dec 15 16:02:05 2022 -0500 c++: extract_local_specs and unevaluated contexts [PR100295]
[Bug c++/108998] ICE in tsubst, at cp/pt.cc:16037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998 --- Comment #1 from waffl3x --- I ran it on my local system, just to get some line numbers, and I accidentally ran it on an older version (12.1) and found that it has a similar result, I'm posting the output of -v and the error of both here. As a reminder, gcc 12.2 on godbolt does not ICE. [waffl3x@waffl3x-manjaro-desktop gcc]$ /opt/compiler/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/compiler/bin/g++ COLLECT_LTO_WRAPPER=/opt/compiler/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-13-20230115/configure --enable-languages=c,c++,lto --enable-bootstrap --prefix=/opt/compiler --mandir=/usr/share/man --infodir=/usr/share/info --with-linker-hash-style=gnu --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-werror --enable-clocale=gnu --enable-libstdcxx-backtrace --enable-multilib --disable-libstdcxx-pch --with-build-config=bootstrap-lto Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20230115 (experimental) (GCC) [waffl3x@waffl3x-manjaro-desktop gcc]$ /opt/compiler/bin/g++ test.cpp test.cpp: In instantiation of ‘ice(int):: [with int I = 0]’: test.cpp:11:34: required from ‘void ice(T) [with T = int]’ test.cpp:15:8: required from here test.cpp:7:10: internal compiler error: in tsubst, at cp/pt.cc:16025 7 | auto aa = a; | ^~ 0x635279 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:16025 0x8278de tsubst_decl ../../gcc-13-20230115/gcc/cp/pt.cc:15194 0x8302c8 tsubst_copy ../../gcc-13-20230115/gcc/cp/pt.cc:17267 0x8200fc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:21530 0x8248c8 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:16547 0x829de5 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:13659 0x821322 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:20299 0x80d340 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:19764 0x80e512 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:18711 0x80e512 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:19041 0x80eb23 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:18711 0x80eb23 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:19105 0x80eb23 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:18711 0x80eb23 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:19105 0x80d0d9 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc-13-20230115/gcc/cp/pt.cc:26702 0x80d0d9 instantiate_body ../../gcc-13-20230115/gcc/cp/pt.cc:26702 0x81219d instantiate_decl(tree_node*, bool, bool) ../../gcc-13-20230115/gcc/cp/pt.cc:26992 0x6ffcb3 maybe_instantiate_decl(tree_node*) ../../gcc-13-20230115/gcc/cp/decl2.cc:5448 0x6ffcb3 maybe_instantiate_decl(tree_node*) ../../gcc-13-20230115/gcc/cp/decl2.cc:5435 0x718092 mark_used(tree_node*, int) ../../gcc-13-20230115/gcc/cp/decl2.cc:5747 [waffl3x@waffl3x-manjaro-desktop gcc]$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.1 20230111 (GCC) [waffl3x@waffl3x-manjaro-desktop gcc]$ g++ test.cpp test.cpp: In instantiation of ‘ice(int):: [with int I = 0]’: test.cpp:11:34: required from ‘void ice(T) [with T = int]’ test.cpp:15:8: required from
[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997 --- Comment #3 from Nikita Kniazev --- For cond == 789 if (cond_2(D) == 789) goto ; [20.24%] else goto ; [79.76%] For cond != 789 if (cond_2(D) != 789) goto ; [48.88%] else goto ; [51.12%]
[Bug c++/107939] [11/12/13 Regression] Rejects use of `extern const` variable in a template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939 --- Comment #5 from Marek Polacek --- I think p_c_e just needs to handle constexpr functors in templates. I'll poke more tomorrow.
[Bug c++/108998] New: ICE in tsubst, at cp/pt.cc:16037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Bug ID: 108998
Summary: ICE in tsubst, at cp/pt.cc:16037
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail dot com
Target Milestone: ---
Created attachment 54573
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54573=edit
the output of -v on godbolt at the time of posting this report
template
inline constexpr bool templ = false;
template
void ice(T a)
{
auto aa = a;
auto lambda = [](){
if constexpr (templ) {}
};
lambda.template operator()<0>();
}
void go() {
ice(0);
}
https://godbolt.org/z/4qn9s6cad
The conditions for this were rather complicated, this was as far as I could
reduce it. Some things to note,
it does not trigger when the lambda's template parameter is a type parameter,
it does not trigger with an auto function parameter,
it does not trigger outside of if constexpr,
and it does not trigger when the first argument to templ is not a lambda's
template parameter.
I couldn't find a way to trigger it without a lambda's non type template
parameter.
: In instantiation of 'ice(int):: [with int I = 0]':
:11:34: required from 'void ice(T) [with T = int]'
:15:8: required from here
:7:10: internal compiler error: in tsubst, at cp/pt.cc:16037
7 | auto aa = a;
| ^~
0x247996e internal_error(char const*, ...)
???:0
0xae93fe fancy_abort(char const*, int, char const*)
???:0
0xd11fdd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd13f4d tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0xd09c65 instantiate_decl(tree_node*, bool, bool)
???:0
0xbdf731 maybe_instantiate_decl(tree_node*)
???:0
0xbe11be mark_used(tree_node*, int)
???:0
0xb16f0e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xd09c65 instantiate_decl(tree_node*, bool, bool)
???:0
0xd35ffb instantiate_pending_templates(int)
???:0
0xbe4325 c_parse_final_cleanups()
???:0
0xe215f8 c_common_parse_file()
???:0
[Bug testsuite/108991] [13 regression] gcc.dg/memchr-3.c fails after r13-6414-g62a8d31ecc0704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108991 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Should be fixed now.
[Bug testsuite/108991] [13 regression] gcc.dg/memchr-3.c fails after r13-6414-g62a8d31ecc0704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108991 --- Comment #1 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:73bbfd5970ba3b7a5bcb3f7043d93fec89ccb991 commit r13-6428-g73bbfd5970ba3b7a5bcb3f7043d93fec89ccb991 Author: Jakub Jelinek Date: Fri Mar 3 00:50:10 2023 +0100 testsuite: Fix up memchr-3.c test [PR108991] The newly added dg-warning directive was missing the comment argument, so the target selector was treated as comment and the warning was expected on all targets when it should be expected only on llp64 targets. 2023-03-03 Jakub Jelinek PR testsuite/108991 * gcc.dg/memchr-3.c: Add missing comment argument to dg-warning before target selector.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #16 from Andrew Pinski --- (In reply to Costas Argyris from comment #15) > Sounds like I am hitting a separate existing limitation that has nothing to > do with this bug. > > Do we need a new bug report for that one then? No one bug report is enough really in this case. It should not be hard to come up with a secondary patch which fixes that issue. I might give it a go in a few weeks if someone has not already.
[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Fixed now on the trunk. I'd wait a little bit with backports, though I think the gmp-param.h change doesn't need backporting.
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #13 from Jakub Jelinek --- Fixed now on the trunk. I'd wait a little bit with backports, though I think the gmp-param.h change doesn't need backporting.
[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108883 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed now.
[Bug c++/16151] Poor diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16151 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. Additionally, it makes mp_limb_t 64-bit on llp64 targets like 64-bit cygwin. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t, BITS_PER_MP_LIMB): Use 64-bit limbs on LLP64 targets. * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes.
[Bug target/26137] Cannot connect to target board h8 using GDB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26137 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. Additionally, it makes mp_limb_t 64-bit on llp64 targets like 64-bit cygwin. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t, BITS_PER_MP_LIMB): Use 64-bit limbs on LLP64 targets. * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes.
[Bug target/18247] [4.0 regression] ada runtime bootstrap failure on powerpc-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18247 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. Additionally, it makes mp_limb_t 64-bit on llp64 targets like 64-bit cygwin. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t, BITS_PER_MP_LIMB): Use 64-bit limbs on LLP64 targets. * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes.
[Bug c++/16965] [3.4/4.0 regression] Confusing mismatch in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16965 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. Additionally, it makes mp_limb_t 64-bit on llp64 targets like 64-bit cygwin. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t, BITS_PER_MP_LIMB): Use 64-bit limbs on LLP64 targets. * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes.
[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. Additionally, it makes mp_limb_t 64-bit on llp64 targets like 64-bit cygwin. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t, BITS_PER_MP_LIMB): Use 64-bit limbs on LLP64 targets. * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes.
[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:df63f4162c78ef799d4ea9dec3443d5e9c51e5aa commit r13-6427-gdf63f4162c78ef799d4ea9dec3443d5e9c51e5aa Author: Jakub Jelinek Date: Fri Mar 3 00:40:13 2023 +0100 libquadmath: Assorted libquadmath strtoflt128 fixes [PR87204, PR94756] This patch cherry-pickx 8 commits from glibc which fix various strtod_l bugs. Additionally, it makes mp_limb_t 64-bit on llp64 targets like 64-bit cygwin. 2023-03-03 niXman Jakub Jelinek PR libquadmath/87204 PR libquadmath/94756 * printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t, BITS_PER_MP_LIMB): Use 64-bit limbs on LLP64 targets. * strtod/strtod_l.c (round_and_return): Cherry-pick glibc 9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a BZ #23279 fixes. (STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007, 5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and d84f25c7d87 fixes.
[Bug libstdc++/108883] [13 Regression] ABI problems with _Float16/std::bfloat16_t rtti symbols on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108883
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6978df2c04df165eaa6aac9e17b6c770bed460e3
commit r13-6426-g6978df2c04df165eaa6aac9e17b6c770bed460e3
Author: Jakub Jelinek
Date: Fri Mar 3 00:34:59 2023 +0100
c++, v3: Emit fundamental tinfos for _Float16/decltype(0.0bf16) types on
ia32 with -mno-sse2 [PR108883]
_Float16 and decltype(0.0bf16) types are on x86 supported only with
-msse2. On x86_64 that is the default, but on ia32 it is not.
We should still emit fundamental type tinfo for those types in
libsupc++.a/libstdc++.*, regardless of whether libsupc++/libstdc++
is compiled with -msse2 or not, as user programs can be compiled
with different ISA flags from libsupc++/libstdc++ and if they
are compiled with -msse2 and use std::float16_t or std::bfloat16_t
and need RTTI for it, it should work out of the box. Furthermore,
libstdc++ ABI on ia32 shouldn't depend on whether the library
is compiled with -mno-sse or -msse2.
Unfortunately, just hacking up libsupc++ Makefile/configure so that
a single source is compiled with -msse2 isn't appropriate, because
that TU emits also code and the code should be able to run on CPUs
which libstdc++ supports. We could add [[gnu::attribute ("no-sse2")]]
there perhaps conditionally, but it all gets quite ugly.
The following patch instead adds a target hook which allows the backend
to temporarily tweak registered types such that emit_support_tinfos
emits whatever is needed.
Additionally, it makes emit_support_tinfos_1 call emit_tinfo_decl
immediately, so that temporarily created dummy types for emit_support_tinfo
purposes only can be nullified again afterwards. And removes the
previous fallback_* types used for dfloat*_type_node tinfos even when
decimal types aren't supported.
2023-03-03 Jakub Jelinek
PR target/108883
gcc/
* target.h (emit_support_tinfos_callback): New typedef.
* targhooks.h (default_emit_support_tinfos): Declare.
* targhooks.cc (default_emit_support_tinfos): New function.
* target.def (emit_support_tinfos): New target hook.
* doc/tm.texi.in (emit_support_tinfos): Document it.
* doc/tm.texi: Regenerated.
* config/i386/i386.cc (ix86_emit_support_tinfos): New function.
(TARGET_EMIT_SUPPORT_TINFOS): Redefine.
gcc/cp/
* cp-tree.h (enum cp_tree_index): Remove CPTI_FALLBACK_DFLOAT*_TYPE
enumerators.
(fallback_dfloat32_type, fallback_dfloat64_type,
fallback_dfloat128_type): Remove.
* rtti.cc (emit_support_tinfo_1): If not emitted already, call
emit_tinfo_decl and remove from unemitted_tinfo_decls right away.
(emit_support_tinfos): Move *_type_node from fundamentals
array
into new fundamentals_with_fallback array. Call
emit_support_tinfo_1
on elements of that array too, with the difference that if
the type is NULL, use a fallback REAL_TYPE for it temporarily.
Drop the !targetm.decimal_float_supported_p () handling. Call
targetm.emit_support_tinfos at the end.
* mangle.cc (write_builtin_type): Remove references to
fallback_dfloat*_type. Handle bfloat16_type_node mangling.
[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Nikita Kniazev from comment #6)
> > The duplication happens even if I make cond int and compare with any other
> > value
> >
> > void use(int *);
> > void use2(int *);
> >
> > void foo(int * p, int cond)
> > {
> > if (cond == 789) {
> > use(p);
> > }
> > use2(p);
> > }
>
> Yes and no, Yes it does in GCC 7/8 but starting in GCC 9 there is not.
> GCC before GCC 10.x is no longer supported so there is not much we can do
> there.
Well actually I was wrong, the duplication is there but you can see why GCC
does the code duplication really. To also do shrink wrapping.
That is GCC 9+ does not need to setup a stack frame for the != 789 case and
just tail call to use2.
[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #7 from Andrew Pinski ---
(In reply to Nikita Kniazev from comment #6)
> The duplication happens even if I make cond int and compare with any other
> value
>
> void use(int *);
> void use2(int *);
>
> void foo(int * p, int cond)
> {
> if (cond == 789) {
> use(p);
> }
> use2(p);
> }
Yes and no, Yes it does in GCC 7/8 but starting in GCC 9 there is not.
GCC before GCC 10.x is no longer supported so there is not much we can do
there.
[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997 --- Comment #2 from Andrew Pinski --- (In reply to Nikita Kniazev from comment #1) > Is it about bool? YES.
[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment #1 from Nikita Kniazev ---
Is it about bool?
void use(int *);
void use2(int *);
void foo(int * p, int cond)
{
if (cond == 789) {
use(p);
}
use2(p);
}
[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #6 from Nikita Kniazev ---
> Did you see this in real code or you just noticed this while looking at code
> generation?
If you mean do I have any benchmark - unfortunately no. I noticed it for a
while by poking different code to compare Clang codegen to GCC.
> In the first case GCC predicts that the cond is going to be true 66% of the
> time
The 66% thing is what I also noticed for a while.
> because there is comparison against 0 prediction going in the heurstics.
The duplication happens even if I make cond int and compare with any other
value
void use(int *);
void use2(int *);
void foo(int * p, int cond)
{
if (cond == 789) {
use(p);
}
use2(p);
}
[Bug middle-end/108990] Too restrictive precision check in fold and simplify pattern for PR70920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70920 Last reconfirmed||2023-03-02 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- There are other patterns which handle different precision integeral types though. e.g. match.pd:5780 /* If possible, express the comparison in the shorter mode. */ (if ((cmp == EQ_EXPR || cmp == NE_EXPR || TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE (@00)) || (!TYPE_UNSIGNED (TREE_TYPE (@0)) && TYPE_UNSIGNED (TREE_TYPE (@00 && (types_match (TREE_TYPE (@10), TREE_TYPE (@00)) || ((TYPE_PRECISION (TREE_TYPE (@00)) >= TYPE_PRECISION (TREE_TYPE (@10))) && (TYPE_UNSIGNED (TREE_TYPE (@00)) == TYPE_UNSIGNED (TREE_TYPE (@10 || (TREE_CODE (@10) == INTEGER_CST && INTEGRAL_TYPE_P (TREE_TYPE (@00)) && int_fits_type_p (@10, TREE_TYPE (@00) (cmp @00 (convert @10)) I wonder if the pattern for PR 70920 should be combined with the above one and fixed up.
[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch. Given that this failure started with r13-4410-g7c01d029fca669263b9c2, no backporting is needed. Marking as resolved.
[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #5 from Andrew Pinski --- Note I filed PR 108997 for what seems like the wrong heurstic for the prediction.
[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6b432c0f777ab9b8436fb07f71de6ea4d259b869 commit r13-6425-g6b432c0f777ab9b8436fb07f71de6ea4d259b869 Author: Guillaume Gomez Date: Thu Mar 2 17:52:07 2023 -0500 jit, testsuite: fix a failing test by updating its error string [PR107999] gcc/testsuite/ChangeLog: PR jit/107999 * jit.dg/test-error-array-bounds.c: Update test. Signed-off-by: Guillaume Gomez
[Bug tree-optimization/108997] New: GCC prediction on bool comparisons seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Bug ID: 108997
Summary: GCC prediction on bool comparisons seems wrong
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
I noticed this while looking into 108992.
I suspect we look into this but I am not 100% sure this is a bug.
Testcase:
void use(int *);
void use2(int *);
void foo(bool cond, int * p)
{
if (cond) {
use(p);
}
use2(p);
}
GCC predicts the branch to be taken 66% of the time, but I would have assume it
should be 50% as it is a bool and there is no other information. I suspect this
is due to prediction when comparing against 0.
[Bug c++/107939] [11/12/13 Regression] Rejects use of `extern const` variable in a template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- A similar example extern const int z; template constexpr auto p = z; works, because require_constant_expression is OK with 'z' here. The difference between 'z' here and 'q' in the previous test is INTEGRAL_OR_ENUMERATION_TYPE_P, which makes decl_maybe_constant_var_p return different answers: else if (CP_TYPE_CONST_NON_VOLATILE_P (type) && INTEGRAL_OR_ENUMERATION_TYPE_P (type)) /* And const integers. */;
[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Andrew Pinski ---
I suspect this is not a bug, GCC tries to optimze the fast path into straight
line code without any waste of space.
In the first case GCC predicts that the cond is going to be true 66% of the
time because there is comparison against 0 prediction going in the heurstics.
For the first testcase if you do:
void use(int *);
void use2(int *);
void foo(bool cond, int * p)
{
if (__builtin_expect(cond, 1)) {
use(p);
}
use2(p);
}
Then you get the result you want.
Adding the builtin_expect for the second case you get the same too.
Basically GCC is pushing what it thinks as cold code away from the original
path.
[Bug rtl-optimization/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #3 from Andrew Pinski --- Did you see this in real code or you just noticed this while looking at code generation?
[Bug c++/107504] Debugger jumps back to structured binding declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107504 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/84471] Debugger jumps back to lambda capture location every time a captured variable is odr-used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 --- Comment #6 from Jason Merrill --- Fixed for GCC 13.
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #18 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:2639f9d2313664e6b4ed2f8131fefa60aeeb0518 commit r13-6424-g2639f9d2313664e6b4ed2f8131fefa60aeeb0518 Author: Vladimir N. Makarov Date: Thu Mar 2 16:29:05 2023 -0500 IRA: Use minimal cost for hard register movement This is the 2nd attempt to fix PR90706. IRA calculates wrong AVR costs for moving general hard regs of SFmode. This was the reason for spilling a pseudo in the PR. In this patch we use smaller move cost of hard reg in its natural and operand modes. PR rtl-optimization/90706 gcc/ChangeLog: * ira-costs.cc: Include print-rtl.h. (record_reg_classes, scan_one_insn): Add code to print debug info. (record_operand_costs): Find and use smaller cost for hard reg move. gcc/testsuite/ChangeLog: * gcc.target/avr/pr90706.c: New.
[Bug fortran/106856] [12/13 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856 --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-March/059003.html
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #18 from David Malcolm --- Looks like it doesn't even need the asm stmt at line 32 to consider that it could take the false-then-true path.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #17 from David Malcolm ---
...where trunk emits:
test.c:35:22: warning: dereference of NULL 'ptr' [CWE-476]
[-Wanalyzer-null-dereference]
35 | ptr[0] = ~ptr[0];
| ~~~^~~
'foo': events 1-6
|
| 27 | char *ptr = ((void*)0);
| | ^~~
| | |
| | (1) 'ptr' is NULL
| 28 |
| 29 | if ( ((get_cpu_info()->current_vcpu))->domain )
| |~
| ||
| |(2) following 'false' branch...
|..
| 32 | asm volatile ("cmc");
| | ~~~
| | |
| | (3) ...to here
| 33 |
| 34 | if ( ((get_cpu_info()->current_vcpu))->domain )
| |~
| ||
| |(4) following 'true' branch...
| 35 | ptr[0] = ~ptr[0];
| | ~~
| | |
| | (5) ...to here
| | (6) dereference of NULL 'ptr'
|
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #16 from David Malcolm ---
Minimized version of attachment 54572:
struct cpu_info {
/* [...snip...] */
struct vcpu *current_vcpu;
/* [...snip...] */
};
struct vcpu
{
/* [...snip...] */
struct domain *domain;
/* [...snip...] */
};
static __inline__ struct cpu_info *get_cpu_info_from_stack(unsigned long sp)
{
return (struct cpu_info *)((sp | 1L) << 12) << 3) - 1)) + 1) - 1;
}
static __inline__ struct cpu_info *get_cpu_info(void)
{
register unsigned long sp asm("rsp");
return get_cpu_info_from_stack(sp);
}
void foo(char *other)
{
char *ptr = ((void*)0);
if ( ((get_cpu_info()->current_vcpu))->domain )
ptr = other;
asm volatile ("cmc");
if ( ((get_cpu_info()->current_vcpu))->domain )
ptr[0] = ~ptr[0];
}
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #15 from Andrew Cooper --- Wow that's a lot of junk getting included for the minimal include set I could easily make. It occurs to me only after posting that you're liable to fail at: asm ( ".include \"arch/x86/include/asm/asm-macros.h\"" ); which always trips things up. You can safely drop it if you're just interested in the analyser behaviour.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #14 from Andrew Cooper --- Created attachment 54572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54572=edit Preprocessed example
[Bug c++/108975] [10/11/12/13 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
|ICE on constexpr variable |ICE on constexpr variable
|used as nontype template|used as nontype template
|since |since
|e32fc4499f863fe0fa81767d11f |r9-5473-ge32fc4499f863f
|40ad2f1ab1668 |
--- Comment #12 from Patrick Palka ---
(In reply to Patrick Palka from comment #11)
> Started with r268016
... aka r9-5473-ge32fc4499f863f.
More reduced testcase:
template
void f() {
constexpr int dim = 1;
auto f = [&] {
int n[dim * 1];
};
}
template void f();
: In instantiation of ‘void f() [with T = int]’:
:9:22: required from here
:5:11: internal compiler error: in lookup_template_class, at
cp/pt.cc:10080
We similarly crash when using a generic lambda:
template
void f() {
constexpr int dim = 1;
auto f = [&] (auto) {
int n[dim * 1];
};
f(0);
}
template void f();
In either case, since dim is a constant variable we should prune the implicit
capture of it and sizeof(f) should be 1.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #13 from Andrew Cooper ---
I've constructed an example which might be the knockon effect you were worried
about?
void foo(char *other)
{
char *ptr = NULL;
if ( current->domain )
ptr = other;
asm volatile ("cmc");
if ( current->domain )
ptr[0] = ~ptr[0];
}
yields
arch/x86/tmp.c: In function 'foo':
arch/x86/tmp.c:14:22: error: dereference of NULL 'ptr' [CWE-476]
[-Werror=analyzer-null-dereference]
14 | ptr[0] = ~ptr[0];
| ~~~^~~
'foo': events 1-5
|
|8 | if ( current->domain )
| |^
| ||
| |(1) following 'false' branch...
|..
| 11 | asm volatile ("cmc");
| | ~~~
| | |
| | (2) ...to here
| 12 |
| 13 | if ( current->domain )
| |~
| ||
| |(3) following 'true' branch...
| 14 | ptr[0] = ~ptr[0];
| | ~~~ ~~
| | ||
| | |(5) dereference of NULL 'ptr'
| | (4) ...to here
|
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #12 from David Malcolm --- (In reply to Andrew Cooper from comment #9) [...snip...] > Our code does fundamentally rely on get_cpu_info() always returning the same > pointer (on a single CPU). For example, `current` is defined as > `get_cpu_info()->current` and we do expect that to yield the same pointer > when used multiple times. > > Even if the analyser was interpreting the generated asm, there's no way it > could prove this without knowing the size/alignment constraints of our > stacks. Another issue is that even if the analyzer "knows" that get_cpu_info() always returns the same value, it doesn't know what memory is being pointed to, and so has to assume that in: T old_value = get_cpu_info()->current; some_function_call (); T new_value = get_cpu_info()->current; that old_value doesn't necessarily equal new_value, since some_function_call () could have modified the value of "current".
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #11 from David Malcolm --- (In reply to Andrew Cooper from comment #9) [...snip...] > Would a const annotation on get_cpu_info() be likely to help? It occurs to > me that this is true in all cases that the compiler could legitimately > reason about. (It would only cease being true if we fell off our stack, at > which point UB is the very least of our worries.) Probably not (without further patching of the analyzer, at least). For functions it can't see the definition of, the analyzer will respect const annotations and treat such a function as always returning the same results when given the same set of arguments. However, I don't think it will respect a const annotation on an function it can see the definition of; I think in your case it will simply try to (badly) simulate the insides of get_cpu_info. To what extent that's going to lead to false positives is hard to say.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #10 from Andrew Cooper --- >From trying this out, a const attribute doesn't alter the code generation in the slightest, so I presume GCC has already figured the const-ness out.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #9 from Andrew Cooper --- Thank-you for the fix. I've recompiled master and this uninitialised warning has gone. Unfortunately, Xen isn't GCC-13 clean (seems like a real bug in Xen), and the analyser has pointed out various other things which I'm still looking in to. I don't see anything which looks like it is a new knock-on effect from this change. Our code does fundamentally rely on get_cpu_info() always returning the same pointer (on a single CPU). For example, `current` is defined as `get_cpu_info()->current` and we do expect that to yield the same pointer when used multiple times. Even if the analyser was interpreting the generated asm, there's no way it could prove this without knowing the size/alignment constraints of our stacks. Would a const annotation on get_cpu_info() be likely to help? It occurs to me that this is true in all cases that the compiler could legitimately reason about. (It would only cease being true if we fell off our stack, at which point UB is the very least of our worries.)
[Bug fortran/106856] [12/13 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > - testcase pr69398.f90 ICE's - as expected, see comment in new testcase > class_75.f90. Shall we mark this one as XFAIL for the time being and > reopen pr69398? This intermediate regression appears to result from an invalid double-free. I plan to package an updated patch for submission.
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Andrew Pinski --- Hmm, I noticed that since GCC 7 with -std=c++17, the b.x is not initialized at all. So the question I have is there a difference between C++ standards here? Note the issue is we call Base's constructor after doing the zero initialization and the Base's constructor has a clobber in it which I think is correct. This is all front-end generation and not exactly related to the optimizations directly.
[Bug c/108996] New: Proposal for adding DWARF call site information got GCC with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
Bug ID: 108996
Summary: Proposal for adding DWARF call site information got
GCC with -O0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cel at us dot ibm.com
Target Milestone: ---
On PowerPC, the address of the buffer to return non-trivial values such as
structures is passed in register r3. The value of r3 on entry may change in
the body of the caller. Thus the contents of r3 can not be used by GDB at the
function exit to access the address of the buffer.
GDB needs to have the value of r3 on entry to the function to be able to print
the return value of the function when the function exits. GDB is able to get
the value of r3 from the caller at the time of the function call if the needed
DWARF information is available. Currently the only way to get the needed DWARF
information is to compile with -fvar-tracking. The option actually saves lots
of additional information which may negatively impact the size and speed of the
binary when compiled with -O0. We have not done any investigation to determine
the exact amounts but is based on a best guess.
GDB doesn't need all the information provided by -fvar-tracking, actually a
small subset of the information.
Currently GDB on PowerPC will attempt to determine the value of r3 on entry.
If the needed DWARF information is not available, GDB will print the message:
"Cannot resolve DW_OP_entry_value for the return value. Try compiling
with -fvar-tracking. “
The following is an example of how gdb is unable to print the return value. It
is a stripped down version of the gdb testsuite test
gdb/testsuite/gdb.cp/non-trivial-retval.cc.
class B
{
public:
B () {}
B (const B );
int b;
};
B::B(const B )
{
b = obj.b;
}
B
f2 (int i1, int i2)
{
B b;
b.b = i1 + i2;
return b;
}
int
main (void)
{
int i1 = 23;
int i2 = 100;
B b = f2 (i1, i2);
return 0;
}
# compile the program, without -fvar-tracking
gcc -g -o non-trivial-retval non-trivial-retval.cc
# Run GDB
gdb ./non-trivial-retval
...
gdb) break main
Breakpoint 1 at 0x1744: file non-trivial-retval.cc, line 28.
(gdb) r
Starting program: /home/carll/GDB/binutils-gdb-
current/gdb/testsuite/gdb.cp/non-trivial-retval
[Thread debugging using libthread_db
enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, main () at non-trivial-retval.cc:28
28 int i1 = 23;
(gdb) n
29 int i2 = 100;
(gdb) n
31 B b = f2 (i1, i2);
(gdb) s
f2 (i1=23, i2=100) at non-trivial-retval.cc:18
18 B b;
(gdb) finish
warning: Cannot determine the function return value. << Message to
user
Try compiling with -fvar-tracking. << Message to
user
Run till exit from #0 f2 (i1=23, i2=100) at non-trivial-
retval.cc:18
main () at non-trivial-retval.cc:32
32 return 0;
Value returned has type: B. Cannot determine contents << GDB can not
determine return value
(gdb)
When we compile with -fvar-tracking we can print the return value.
# Compile with -fvar-tracking
gcc -g -O0 -fvar-tracking -o non-trivial-retval non-trivial-retval.cc
# Run GDB
gdb ./non-trivial-retval
(gdb) break main
Breakpoint 1 at 0x1730: file non-trivial-retval.cc, line 27.
(gdb) r
Starting program: /home/carll/GDB/binutils-gdb-
current/gdb/testsuite/gdb.cp/non-trivial-retval
[Thread debugging using libthread_db
enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, 0x1730 in main () at non-trivial-
retval.cc:27
27 {
(gdb) s
28 int i1 = 23;
(gdb) s
29 int i2 = 100;
(gdb) s
31 B b = f2 (i1, i2);
(gdb) s
0x16b4 in f2 (i1=i1@entry=23, i2=i2@entry=100)
at non-trivial-retval.cc:17
17 {
(gdb) finish
Run till exit from #0 0x16b4 in f2 (i1=i1@entry=23,
i2=i2@entry=100) at non-trivial-retval.cc:17
main () at non-trivial-retval.cc:32
32 return 0;
Value returned is $1 = {b = 123}<< GDB can print the return
value
Looking at the dwarf information, we need to compile with -g -O2 -fvar-
tracking to get the info we need:
gcc -g -O0 -fvar-tracking -o non-trivial-retval non-trivial-retval.cc
dwarfdump non-trivial-retval > non-trivial-retval.dwarf
...
DW_AT_GNU_locviews0x0039
< 2><0x00d6> DW_TAG_variable
DW_AT_name b
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #3 from Andrew Pinski --- Maybe related to : r13-2801-g94ccaf62c378c3 r13-2870-g386ebf75f4c034
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #13 from Martin Uecker ---
Am Donnerstag, dem 02.03.2023 um 19:47 + schrieb qinzhao at gcc dot
gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #9)
> >
> > https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
> thanks for the info.
> >
> > But we made variably modified types mandatory in C23 to
> > help with bounds checking and this already works quite
> > nicely with GCC / Clang:
> >
> > https://godbolt.org/z/ddfsdWPMj
> nice!
> can you provide a pointer to the section in C23 that made this change?
VLAs and VM types exist since C99 and were made optional in C11.
The minimal change we adopted to make support for VM types
(but not VLAs) mandatory again was:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf
UBSan support in GCC to diagnose such out of bounds accesses
was added here:
https://gcc.gnu.org/git/?p=gcc.git=commit;h=04fd785e38c4c37ae4f71704397a27a924baf4d9
> >
> > > when this variable length concept is extended to global scope, not sure
> > > how to
> > > implement the size expression? need some study here.
> >
> > Here, we want to use a member of the struct as a size
> > expression. This could work equally at function and file scope.
> > But the semantics need to be worked out. I have started to work
> > on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR,
> > but did not get very far.
> >
> > The idea is to evaluate the size expression whenever the member
> > with the size is accesses. If the size is not set before, this
> > would be undefined behavior.
> >
> > Other languages such as Ada support this, so in principle this
> > should be a piece of cake.
> Oh, Ada can support this already?
> how does Ada implement this?
I think using PLACEHOLDER_EXPR that are insert into the size
expression and then replaced later by the struct being accessed,
e.g.
struct foo {
int len;
char buf[PLACEHOLDER_EXPR.len]
};
and then later when we have
struct foo x;
x->buf
we would replace in the size of the type for x->buf the placeholder
with x itself.
> then we can just borrow Ada's implementation idea to implement this in C if
> this is approved as an GCC extension for C.
Yes, this was what I wanted to do... My main use case is not flexible
array members but VM types in struct:
struct foo {
int len;
char (*buf)[.len];
};
This has less issues because the size of the struct then does not depend
on the length.
But I am still trying to understand how this all works in GCC.
Martin
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #12 from qinzhao at gcc dot gnu.org --- (In reply to Martin Uecker from comment #9) > > Here, we want to use a member of the struct as a size > expression. This could work equally at function and file scope. > But the semantics need to be worked out. I have started to work > on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR, > but did not get very far. what kind of semantics your patch will support?
[Bug c++/108243] [10/11/12 Regression] Missed optimization for static const std::string_view(const char*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
|Missed optimization for |Missed optimization for
|static const|static const
|std::string_view(const |std::string_view(const
|char*) |char*)
--- Comment #14 from Patrick Palka ---
The original testcase is fixed for GCC 13 by comment #12, so that we now
correctly constant initialize 'static const string_view foo("bar");'.
[Bug rtl-optimization/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #2 from Nikita Kniazev --- > Why do you think this is a bug? > I don't see anything wrong with the newer versions of gcc. > Duplicating the basic blocks is done on purpose for speed reasons. I understand that removing diamonds is done to open more optimization opportunities but in this case there is none; not undoing the cloning leads to code size increases which creates unnecessary pressure on instruction cache.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #9)
>
> https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
thanks for the info.
>
> But we made variably modified types mandatory in C23 to
> help with bounds checking and this already works quite
> nicely with GCC / Clang:
>
> https://godbolt.org/z/ddfsdWPMj
nice!
can you provide a pointer to the section in C23 that made this change?
>
> > when this variable length concept is extended to global scope, not sure how
> > to
> > implement the size expression? need some study here.
>
> Here, we want to use a member of the struct as a size
> expression. This could work equally at function and file scope.
> But the semantics need to be worked out. I have started to work
> on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR,
> but did not get very far.
>
> The idea is to evaluate the size expression whenever the member
> with the size is accesses. If the size is not set before, this
> would be undefined behavior.
>
> Other languages such as Ada support this, so in principle this
> should be a piece of cake.
Oh, Ada can support this already?
how does Ada implement this?
then we can just borrow Ada's implementation idea to implement this in C if
this is approved as an GCC extension for C.
> > this proposal basically is to extend the VLA concept from function scope to
> > global scope. is my understanding correct?
>
> I would say the idea is to allow size expressions to refer
> to member of a struct instead of only automatic variables.
>
Okay.
> > a question here is:
> >
> > for the following nested structure:
> >
> > struct object {
> > ...
> > char items;
> > ...
> > struct inner {
> > ...
> > int flex[];
> > };
> > } *ptr;
> >
> > what kind of syntax is good to represent the upper bound of "flex" in the
> > inner
> > struct with "items" in the outer structure? any suggestion?
>
> I would disallow it. At least at first. It also raises some
> questions: For example, one could form a pointer to the inner
> struct, and then it is not clear how 'items' could be accessed
> anymore.
>
Okay.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-03-02 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #8 from David Malcolm --- I've attempted to work around this with the above patch (for gcc 13). As written, this ought to suppress the "uninit" false positive, but I didn't have a good kind of symbolic value to use for the resulting pointer, hence the analyzer will treat the result of get_cpu_info as an "unknowable" pointer, which might lead to a chain of follow-up false positives if there's logic in the code being analyzed that relies on dereferencing the result and getting consistent results. Can you attach a typical preprocessed source file from xen (the GPL licensed part) that was showing this (use -E), so I can poke at it to see how well this workaround works - thanks! Keeping open in case this needs further work, and to possibly track backporting to GCC 12.
[Bug rtl-optimization/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #1 from Andrew Pinski --- Why do you think this is a bug? I don't see anything wrong with the newer versions of gcc. Duplicating the basic blocks is done on purpose for speed reasons.
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #2 from Tom Stellard --- $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/13/lto-wrapper Target: aarch64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-13.0.1-20230221/obj-aarch64-redhat-linux/isl-install --enable-gnu-indirect-function --build=aarch64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230221 (Red Hat 13.0.1-0) (GCC)
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #1 from Andrew Pinski --- Can you supply the output of "gcc -v"? There was a bug dealing with the unwinder which wad fixed in the last month.
[Bug c++/97553] [missed optimization] constexprness not noticed when UBsan enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:5425159d176a7a92afc932cbb22d8822667099c4 commit r13-6422-g5425159d176a7a92afc932cbb22d8822667099c4 Author: Patrick Palka Date: Thu Mar 2 14:04:50 2023 -0500 c++: more mce_false folding from cp_fully_fold_init [PR108243] We should also fold the overall initializer passed to cp_fully_fold_init with mce_false, which allows folding of the copy-initialization of 'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR). Unfortunately this doesn't help with direct- or default-initialization because we don't call cp_fully_fold_init in that case, and even if we did the initializer in that case is expressed as a bare CALL_EXPR instead of an AGGR_INIT_EXPR, which cp_fully_fold_init can't really fold. PR c++/108243 PR c++/97553 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fully_fold): Add an internal overload that additionally takes and propagate an mce_value parameter, and define the existing public overload in terms of it. (cp_fully_fold_init): Pass mce_false to cp_fully_fold. gcc/testsuite/ChangeLog: * g++.dg/opt/is_constant_evaluated3.C: New test.
[Bug c++/108243] [10/11/12/13 Regression] Missed optimization for static const std::string_view(const char*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243 --- Comment #13 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:5425159d176a7a92afc932cbb22d8822667099c4 commit r13-6422-g5425159d176a7a92afc932cbb22d8822667099c4 Author: Patrick Palka Date: Thu Mar 2 14:04:50 2023 -0500 c++: more mce_false folding from cp_fully_fold_init [PR108243] We should also fold the overall initializer passed to cp_fully_fold_init with mce_false, which allows folding of the copy-initialization of 'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR). Unfortunately this doesn't help with direct- or default-initialization because we don't call cp_fully_fold_init in that case, and even if we did the initializer in that case is expressed as a bare CALL_EXPR instead of an AGGR_INIT_EXPR, which cp_fully_fold_init can't really fold. PR c++/108243 PR c++/97553 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fully_fold): Add an internal overload that additionally takes and propagate an mce_value parameter, and define the existing public overload in terms of it. (cp_fully_fold_init): Pass mce_false to cp_fully_fold. gcc/testsuite/ChangeLog: * g++.dg/opt/is_constant_evaluated3.C: New test.
