[Bug c++/105756] [12/13 Regression] ICE in cxx_eval_constant_expression at cp/constexpr.cc:7586: unexpected expression ‘ElemSize’ of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105756 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Priority|P3 |P2 Ever confirmed|0 |1 Target Milestone|--- |12.2 Last reconfirmed||2022-05-28 --- Comment #2 from Jakub Jelinek --- Started with r12-7564-gec0f53a3a542e762f8fc8 aka PR104823 fix.
[Bug middle-end/98865] Missed transform of (a >> 63) * b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98865 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #9 from Roger Sayle --- This is now fixed/implemented on mainline for GCC 13.
[Bug c++/105757] New: default argument of incomplete type with C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105757
Bug ID: 105757
Summary: default argument of incomplete type with C++20
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fsb4000 at yandex dot ru
Target Milestone: ---
Hi!
One user reported that some code doesn't work with current MSVC but worked
before and works with gcc.
Reduced code:
template
struct A {
constexpr A() {}
constexpr ~A() { T t; }
};
struct B;
void f(const A& = {});
$ g++ -std=c++20 -c main.cpp
https://gcc.godbolt.org/z/jWdd3Gc5h
MSVC devs think that the code is not valid and I decided to inform you:
Cameron DaCamara: "I'm pretty convinced this is a source bug and that GCC
hasn't quite implemented
P0859R0(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0859r0.html)
fully yet. The reason this is now observable with newer MSVC versions is
because the compiler is required to instantiate special member functions if
they could be potentially used for constant evaluation. Since the default
argument here is going to end up being assigned to a variable the ctor and dtor
are actually odr-used in the default argument."
Also if we reformat the code slightly(A{} instead of {}) then it is rejected
by gcc:
template
struct A {
constexpr A() {}
constexpr ~A() { T t; }
};
struct B;
void f(const A& = A{});
$ g++ -std=c++20 -c main.cpp
main.cpp: In instantiation of 'constexpr A::~A() [with T = B]':
main.cpp:9:27: required from here
main.cpp:5:24: error: 'B t' has incomplete type
5 | constexpr ~A() { T t; }
|
My GCC version:
$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\tools\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-12.1.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib
--enable-bootstrap --enable-checking=release --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev2, Built by MSYS2 project'
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++
--with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Rev2, Built by MSYS2 project)
[Bug c++/105758] New: [12/13 Regression] ICE in build_baselink since r12-6897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105758
Bug ID: 105758
Summary: [12/13 Regression] ICE in build_baselink since
r12-6897
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Starting with r12-6897-gdec8d0e5fa00ceb2ded78b8a3eba8976d860a90e we ICE with
-std=c++11 on the following testcase:
struct A {
template void foo(D, T, int);
};
template
struct Z : A {
static Z *z;
void bar();
};
template
Z *Z::z;
template
void Z::bar() {
int a = 0, b = 1, c = 2;
z->foo(a, b, c);
}
[Bug c++/105758] [12/13 Regression] ICE in build_baselink since r12-6897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105758 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.2 CC||ppalka at gcc dot gnu.org Priority|P3 |P2
[Bug libbacktrace/105721] libbacktrace: update README
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105721 --- Comment #1 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:f535f9d7b05db6fa02e90c90173c597d1972faa1 commit r13-811-gf535f9d7b05db6fa02e90c90173c597d1972faa1 Author: Ian Lance Taylor Date: Sat May 28 07:57:32 2022 -0700 libbacktrace: update README PR libbacktrace/105721 * README: Update.
[Bug libbacktrace/105721] libbacktrace: update README
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105721 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com --- Comment #2 from Ian Lance Taylor --- Thanks, fixed.
[Bug target/77311] bfin: error: unable to find a register to spill in class 'CCREGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77311
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-05-28
CC||law at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #1 from Jeffrey A. Law ---
So my tester tripped over a similar, likely the same, problem starting about a
week ago.
After reviewing the bfin port I think it is fundamentally broken WRT its
handling of condition codes.
Let's say we have these two insns in the stream:
(insn 1711 1710 1717 139 (set (reg:BI 1203)
(ne:BI (reg:SI 977)
(const_int 0 [0]))) "k.c":18:12 130 {movsibi}
(expr_list:REG_DEAD (reg:SI 977)
(nil)))
(insn 1717 1711 1726 139 (set (reg:BI 1204)
(reg:BI 34 CC)) "k.c":19:13 13 {movbi}
(expr_list:REG_DEAD (reg:BI 34 CC)
(nil)))
r1203 is going to need to be allocated to the CC register. But we can
trivially see that the CC register already has a live value in it by way of the
use at insn 1717.
So r1203 is going to have to be assigned to a GPR and LRA/reload will have to
fix things up. Any sequence I can think of to do that will ultimately result
in clobbering CC. But that's not valid because bfin has exposed CC prior to
allocation/reload.
This change from Richi is trigger for the fault I've seen, but I think the real
issue is the bfin port is just plain broken.
commit 68e0063397ba820e71adc220b2da0581dce29ffa (HEAD, refs/bisect/bad)
Author: Richard Biener
Date: Mon Apr 11 13:36:53 2022 +0200
Force the selection operand of a GIMPLE COND_EXPR to be a register
This goes away with the selection operand allowed to be a GENERIC
tcc_comparison tree. It keeps those for vectorizer pattern recog,
those are short lived and removing this instance is a bigger task.
The patch doesn't yet remove dead code and functionality, that's
left for a followup. Instead the patch makes sure to produce
valid GIMPLE IL and continue to optimize COND_EXPRs where the
previous IL allowed and the new IL showed regressions in the testsuite.
Here's the new failures just for reference. But I suspect this will likely go
latent as some point given its sensitivity to instruction orderings and
register allocation.
bfin-sim: c-c++-common/torture/pr101636.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
bfin-sim: c-c++-common/torture/pr101636.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess
errors)
bfin-sim: c-c++-common/torture/pr101636.c -O3 -g (test for excess errors)
bfin-sim: c-c++-common/torture/pr101636.c -O3 -g (test for excess errors)
[Bug fortran/105759] New: is_contiguous(zero_size_array(2:0)) wrongly returns .true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105759 Bug ID: 105759 Summary: is_contiguous(zero_size_array(2:0)) wrongly returns .true. Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- GCC and ifort both return T for the following code: integer :: a(2) print *, is_contiguous(a(2:1)) end However, I think that should be F / .false. as F2018 has: 8.5.7 CONTIGUOUS attribute ... An object is contiguous if it is ... (7) a nonzero-sized array section (9.5.3) provided that ... Disclaimer: I might have missed something. If it is a bug, then we probably need to fix both the simplify.cc compile-time and libgfortran run-time check.
[Bug c++/105760] New: ICE: in build_function_type, at tree.cc:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760
Bug ID: 105760
Summary: ICE: in build_function_type, at tree.cc:7365
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
13 Regression
template
struct A { A(Ts...); };
A a;
https://godbolt.org/z/qeYGz1Yov
[Bug c++/105761] New: ICE on hidden friend definition defined in base type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105761
Bug ID: 105761
Summary: ICE on hidden friend definition defined in base type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/v8arThEs1.
```C++
#include
template class X {
friend auto f(X);
};
template> struct downcast_t { using type = void;
};
template struct downcast_t{}))>> {
using type = decltype(f(X{})); };
template using downcast = typename downcast_t::type;
static_assert(std::is_same_v>);
struct Y : X {
friend auto f(X) { return 0L; }
};
static_assert(std::is_same_v>);
```
```
:4:18: warning: friend declaration 'auto f(X)' declares a
non-template function [-Wnon-template-friend]
4 | friend auto f(X);
| ^
:4:18: note: (if this is not what you intended, make sure the function
template has already been declared and add '<>' after the function name here)
:15:20: internal compiler error: in push_template_decl, at
cp/pt.cc:6125
15 | friend auto f(X) { return 0L; }
|^
0x21ffa39 internal_error(char const*, ...)
???:0
0x7452f3 fancy_abort(char const*, int, char const*)
???:0
0x82a0cd start_preparsed_function(tree_node*, tree_node*, int)
???:0
0x98cb8d c_parse_file()
???:0
0xb21d91 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug fortran/105759] is_contiguous(zero_size_array(2:0)) wrongly returns .true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105759 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) > GCC and ifort both return T for the following code: > > integer :: a(2) > print *, is_contiguous(a(2:1)) > end > > > However, I think that should be F / .false. as F2018 has: > > 8.5.7 CONTIGUOUS attribute > ... > An object is contiguous if it is > ... > (7) a nonzero-sized array section (9.5.3) provided that > ... > > > Disclaimer: I might have missed something. > > > If it is a bug, then we probably need to fix both the simplify.cc > compile-time and libgfortran run-time check. I think that you may be wrongly interpreting what the standard says. (7) clearly does not apply to your code because a(2:1) is a zero-sized array section. What I think you're missing from 22-007.pdf, page 104, It is processor dependent whether any other object is contiguous. and a zero-sized entity falls under this statement. Then on page 94, we have An empty sequence forms a zero-sized array. As the sequence is empty, it can be neither contiguous nor discontiguous.
[Bug target/103722] [12/13 Regression] ICE in extract_constrain_insn building glibc for SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722 --- Comment #5 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:ce1580252ea57de23a595e9804ea87ed4353aa6a commit r13-813-gce1580252ea57de23a595e9804ea87ed4353aa6a Author: Vladimir Makarov Date: Sat May 28 12:08:38 2022 -0600 Fix ICE on sh gcc/ PR target/103722 * config/sh/sh.cc (sh_register_move_cost): Avoid cost "2" (which is special) for various scenarios.
[Bug c++/105761] ICE on hidden friend definition defined in base type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105761
--- Comment #1 from Johel Ernesto Guerrero Peña ---
Simplified: https://godbolt.org/z/66Gd84dos.
```C++
template
class X {
friend auto f(X);
};
struct Y : X {
friend auto f(X) { return 0L; }
};
```
[Bug target/103722] [12/13 Regression] ICE in extract_constrain_insn building glibc for SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722 --- Comment #6 from Jeffrey A. Law --- Fixed on the trunk. Backporting to the gcc-12 release branch should be safe if someone wanted to do that.
[Bug middle-end/105762] New: [12 Regression] -Warray-bounds false positives for integer-to-pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762
Bug ID: 105762
Summary: [12 Regression] -Warray-bounds false positives for
integer-to-pointer casts
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
This code:
```
void crash(void) {
volatile int* ptr = (volatile int*)1ul;
*ptr = 1;
}
```
now gets:
```
warning: array subscript 0 is outside array bounds of 'volatile int[0]'
[-Warray-bounds]
```
This is a regression since GCC 11.
Reproduced on aarch64-elf and x86_64-elf targets as of 12 branch commit
2c11a9a380e7af333e19d6e576a889646d699b2a
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2022-May/057887.html
[Bug c/105763] New: ice in outgoing_edge_range_p, at gimple-ra nge-gori.cc:1253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105763 Bug ID: 105763 Summary: ice in outgoing_edge_range_p, at gimple-ra nge-gori.cc:1253 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 53048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53048&action=edit C source code For the attached code, with compiler flag -O3, does this: during GIMPLE pass: unswitch rl2png.c: In function ‘rl2_decode_png’: rl2png.c:1292:1: internal compiler error: in outgoing_edge_range_p, at gimple-ra nge-gori.cc:1253 0xa17888 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*, ran ge_query&) ../../trunk.git/gcc/gimple-range-gori.cc:1253 0x2da292b evaluate_control_stmt_using_entry_checks ../../trunk.git/gcc/tree-ssa-loop-unswitch.cc:686 0x2da4e43 evaluate_bbs > ../../trunk.git/gcc/tree-ssa-loop-unswitch.cc:830 0x2da97b6 evaluate_loop_insns_for_predicate ../../trunk.git/gcc/tree-ssa-loop-unswitch.cc:876 The problem first seems to occur sometime between git hash 442cf0977a299394 and 850a9ce8bcca59c7, a distance of some 32 commits. A reduction is running now and will be finishing in the next ten minutes.
[Bug c/105763] ice in outgoing_edge_range_p, at gimple-ra nge-gori.cc:1253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105763
--- Comment #1 from David Binderman ---
Reduced C code is
int rl2_decode_png_bit_depth;
int *rl2_decode_png_p_data;
void rl2_decode_png_row_pointers() {
unsigned sample_type = 0;
_setjmp();
switch (rl2_decode_png_bit_depth)
case 6:
sample_type = 7;
png_destroy_read_struct();
for (;;)
switch (sample_type)
case 3:
case 5:
*rl2_decode_png_p_data;
}
[Bug tree-optimization/105763] [13 Regression] ice in outgoing_edge_range_p, at gimple-ra nge-gori.cc:1253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105763 Andrew Pinski changed: What|Removed |Added Version|12.0|13.0 Target Milestone|--- |13.0 Summary|ice in |[13 Regression] ice in |outgoing_edge_range_p, at |outgoing_edge_range_p, at |gimple-ra nge-gori.cc:1253 |gimple-ra nge-gori.cc:1253
[Bug libfortran/105764] New: libgfortran fails to build with a custom thread model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105764 Bug ID: 105764 Summary: libgfortran fails to build with a custom thread model Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 53049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53049&action=edit proposed patch Bootstrapping GCC with fortran enabled and a custom thread model can fail: ``` In file included from ../../../gcc/libgfortran/runtime/error.c:28: ../../../gcc/libgfortran/io/async.h:354:3: error: unknown type name 'pthread_t' 354 | pthread_t thread; | ^ ``` In commit a79878585a1c5e32bafbc6d1e73f91fd6e4293bf, `pthread_mutex_t` was replaced with `__gthread_mutex_t`, but `pthread_t` was left over. Not sure whether this was by design, or was an oversight. Patch also sent to gcc-patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595754.html
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Sam James changed: What|Removed |Added CC||sam at gentoo dot org --- Comment #46 from Sam James --- Even partially making the build less recursive would likely help a fair bit. The classic text on this is https://accu.org/journals/overload/14/71/miller_2004/. This doesn't mean that splitting up files is futile, but when watching a build, much of the time, make doesn't even get to traverse into each of the directories, because it doesn't know if it's able to. It can safely be done in stages. Using includes would let you get a lot of the current state wrt split directories. Could even just have a certain number of toplevel directories but non-recursive within them.
[Bug libgomp/90084] Parallelize libgomp testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90084 Sam James changed: What|Removed |Added CC||sam at gentoo dot org --- Comment #2 from Sam James --- Duplicate of bug 66005?
[Bug other/82383] Some new toplevel directories are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82383 --- Comment #7 from CVS Commits --- The master branch has been updated by Eric Gallager : https://gcc.gnu.org/g:da5f0cc2f51a791a397fd1b3cef662763897a826 commit r13-817-gda5f0cc2f51a791a397fd1b3cef662763897a826 Author: Eric Gallager Date: Sun May 29 00:57:05 2022 -0400 sourcebuild.texi: Document toplevel directories Fixes PR82383 gcc/ChangeLog: PR other/82383 * doc/sourcebuild.texi: Add entries for the c++tools, gotools, libbacktrace, libcc1, libcody, liboffloadmic, and libsanitizer directories. Remove entry for boehm-gc. Fix alphabetization for libquadmath.
[Bug libgomp/90084] Parallelize libgomp testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90084 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Eric Gallager --- (In reply to Sam James from comment #2) > Duplicate of bug 66005? Sure I guess so. *** This bug has been marked as a duplicate of bug 66005 ***
[Bug libgomp/66005] libgomp make check time is excessive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005 Eric Gallager changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #3 from Eric Gallager --- *** Bug 90084 has been marked as a duplicate of this bug. ***
[Bug other/82383] Some new toplevel directories are not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82383 Eric Gallager changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Eric Gallager --- Fixed for GCC 13; I'm not planning on backporting. If someone else would like to backport, feel free to reopen.
[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104423 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103324 --- Comment #6 from Eric Gallager --- Seems kinda like the same idea as bug 103324, albeit a more-specific variant of it just for libgomp.
[Bug analyzer/105765] New: [13 Regression] ICE: Segmentation fault (in ana::region_model::deref_rvalue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105765
Bug ID: 105765
Summary: [13 Regression] ICE: Segmentation fault (in
ana::region_model::deref_rvalue)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 13.0.0 20220522 snapshot (g:a60228404f2ac11b5eb66270037ff3fa6bf948e5) ICEs
when compiling the following testcase, reduced from
clang/testsuite/CodeGen/ms_abi_aarch64.c from the clang 14.0.3 test suite, w/
-fanalyzer:
void
f4 (int a, ...)
{
__builtin_ms_va_list ap, ap2;
__builtin_ms_va_start (ap, a);
__builtin_ms_va_copy (ap2, ap);
__builtin_ms_va_end (ap);
}
% gcc-13.0.0 -fanalyzer -c jhszfd06.c
during IPA pass: analyzer
jhszfd06.c: In function 'f4':
jhszfd06.c:7:3: internal compiler error: Segmentation fault
7 | __builtin_ms_va_copy (ap2, ap);
| ^~
0xedc30f crash_signal
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/toplev.cc:322
0x12af921 ana::region_model::deref_rvalue(ana::svalue const*, tree_node*,
ana::region_model_context*) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/region-model.cc:2472
0x130 get_BT_VALIST_ARG
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/varargs.cc:183
0x1311449 ana::region_model::impl_call_va_copy(ana::call_details const&)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/varargs.cc:670
0x12b2268 ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*, bool*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/region-model.cc:1439
0x12c0bc2 ana::region_model::on_stmt_pre(gimple const*, bool*, bool*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/region-model.cc:1213
0x128bff9 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:1383
0x128f3cc ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:3776
0x12903da ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:3219
0x1292ac5 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:5811
0x12939ce ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/engine.cc:5885
0x1282358 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220522/work/gcc-13-20220522/gcc/analyzer/analyzer-pass.cc:87
[Bug c++/98469] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98469 --- Comment #3 from Arseny Solokha --- The ICE was fixed for gcc 11, and gcc 10 does not support __builtin_bit_cast. I believe this PR can be closed now.
[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103324 --- Comment #8 from Sam James --- Using make synchronisation can help a bit: https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html. It's made our build logs in Gentoo a lot more readable for GCC, FWIW. As for the bug request: yes, this would be most helpful in trying to quickly ascertain if things work well enough as a non-GCC developer. Otherwise I'm stuck trying to diff failures and runs taking hours at a time. Not a complaint about your workflow, but saying there's a good usecase for some partial "really should pass" tests.
[Bug tree-optimization/86725] ICE: Segmentation fault (in vect_get_vec_def_for_operand_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86725 Arseny Solokha changed: What|Removed |Added Known to fail|8.1.0 |8.5.0 Known to work|9.0 |10.3.0, 11.3.0, 12.1.0, ||13.0, 9.4.0 --- Comment #6 from Arseny Solokha --- The oldest supported branch is gcc 10 now, so this PR can be closed now.
