[Bug rtl-optimization/112918] [m68k] [LRA] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 Thomas Schwinge changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org --- Comment #14 from Thomas Schwinge --- *** Bug 112265 has been marked as a duplicate of this bug. ***
[Bug target/112265] [14 Regression] GCN offloading 'libgomp.c-c++-common/for-5.c': 'internal compiler error: maximum number of generated reload insns per insn achieved (90)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112265 Thomas Schwinge changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |vmakarov at gcc dot gnu.org --- Comment #4 from Thomas Schwinge --- Resolved via commit r14-6667-g989e67f827b74b76e58abe137ce12d948af2290c "[PR112918][LRA]: Fixing IRA ICE on m68k". *** This bug has been marked as a duplicate of bug 112918 ***
[Bug target/112950] gcc.target/aarch64/sve/acle/general/dupq_5.c fails on aarch64_be-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112950 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |prathamesh3492 at gcc dot gnu.org --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- Sorry for the breakage, will take a look. Thanks, Prathamesh
[Bug target/113090] New: Suboptimal vector permuation for 64-bit vector.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113090
Bug ID: 113090
Summary: Suboptimal vector permuation for 64-bit vector.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Target Milestone: ---
When working on PR113079, loop vectorizer try to reduc sum of v2si with
permuation, x86 backend generates
typedef int v2si __attribute__((vector_size(8)));
v2si
foo (v2si a, v2si b)
{
return __builtin_shufflevector (a, b, 1, 2);
}
foo(int __vector(2), int __vector(2)):
vpshufb xmm0, xmm0, XMMWORD PTR .LC0[rip]
vpshufb xmm1, xmm1, XMMWORD PTR .LC1[rip]
vporxmm0, xmm0, xmm1
But it can be better with
.cfi_startproc
punpcklqdq %xmm1, %xmm0
pshufd $153, %xmm0, %xmm0
ret
[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934 Sam James changed: What|Removed |Added Last reconfirmed|2023-08-07 00:00:00 |2023-12-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #5 from Sam James --- (In reply to Mikael Pettersson from comment #4) > I can reproduce with m68k-unknown-linux-gnu-gcc -Os > -fzero-call-used-regs=all -fPIC. Hence confirmed.
[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code CC||pinskia at gcc dot gnu.org Target Milestone|--- |14.0
[Bug target/113089] New: [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089 Bug ID: 113089 Summary: [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hliu at amperecomputing dot com Target Milestone: --- SPEC2017 525.x264 build failure. Options are: -O3 -mcpu=neoverse-n1 -funroll-loops -flto=32 --param early-inlining-insns=96 --param max-inline-insns-auto=64 --param inline-unit-growth=96 The failure happens while doing LTO optimization: gcc -std=c99 ... -o ldecod_r during RTL pass: ldp_fusion ldecod_src/intra_chroma_pred.c: In function 'intrapred_chroma': ldecod_src/intra_chroma_pred.c:420:1: internal compiler error: in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 420 | } | ^ 0x1ccbbab rtl_ssa::function_info::process_uses_of_deleted_def(rtl_ssa::set_info*) ../../gcc/gcc/rtl-ssa/changes.cc:252 0x1cce34f rtl_ssa::function_info::change_insns(array_slice) ../../gcc/gcc/rtl-ssa/changes.cc:799 0x1371843 ldp_bb_info::fuse_pair(bool, unsigned int, int, rtl_ssa::insn_info*, rtl_ssa::insn_info*, base_cand&, rtl_ssa::insn_range_info const&) ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:1520 0x1374663 ldp_bb_info::try_fuse_pair(bool, unsigned int, rtl_ssa::insn_info*, rtl_ssa::insn_info*) ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2217 0x1374a8f ldp_bb_info::merge_pairs(std::__cxx11::list >&, std::__cxx11::list >&, bool, unsigned int) ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2306 0x1377bfb ldp_bb_info::transform_for_base(int, access_group&) ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2339 0x1377bfb void ldp_bb_info::traverse_base_map, int_hash >, access_group, simple_hashmap_traits, int_hash > >, access_group> > >(ordered_hash_map, int_hash >, access_group, simple_hashmap_traits, int_hash > >, access_group> >&) ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2398 0x136e29b ldp_bb_info::transform() ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2406 0x136e29b ldp_fusion_bb(rtl_ssa::bb_info*) ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2634 0x136ee93 ldp_fusion() ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2643 0x136eefb execute ../../gcc/gcc/config/aarch64/aarch64-ldp-fusion.cc:2693
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #6 from Patrick O'Neill --- (In reply to JuzheZhong from comment #5) > ... > I confirmed it is vsetvl bugs. But I wonder whether you have open source the > random generator ? > > If yes, may be we can dedicate some resources to run random tests too. I use csmith as the random generator and try to fuzz targets that don't have any execution fails/ICEs (currently just rv64gcv/rv64gcv_zvl256b). https://github.com/csmith-project/csmith I was planning on getting the fuzzer and a random config builder running on spare precommit compute but haven't set it up yet. I'll clean up/put the shell scripts I use for csmith here tomorrow: https://github.com/patrick-rivos/gcc-fuzz-ci
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #5 from JuzheZhong --- (In reply to Patrick O'Neill from comment #4) > I can attempt to reduce them however running an iteration of 549 takes > multiple hours so it might be challenging using my current setup (creduce). > Hopefully the random generator stumbles across the same issue and it can get > fixed that way since it's worked for other spec fails previously. I confirmed it is vsetvl bugs. But I wonder whether you have open source the random generator ? If yes, may be we can dedicate some resources to run random tests too.
[Bug rtl-optimization/113002] ICE in commit_one_edge_insertion, at cfgrtl.cc:2095 with new -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- Created attachment 56907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56907=edit candidate patch under test
[Bug c++/108975] [11 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 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #24 from Patrick Palka --- Partially fixed (the non-generic lambda case) for 10.5/11.4/12.3/13.2, more thoroughly fixed (the generic lambda casE) for 11.5/12.4/13.3.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 108975, which changed state. Bug 108975 Summary: [11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/108975] [11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #23 from GCC Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a53f988e36132761c8fe17da421b736e737dec30 commit r11-11161-ga53f988e36132761c8fe17da421b736e737dec30 Author: Patrick Palka Date: Tue Apr 25 15:59:22 2023 -0400 c++: value dependence of by-ref lambda capture [PR108975] We are still ICEing on the generic lambda version of the testcase from this PR, even after r13-6743-g6f90de97634d6f, due to the by-ref capture of the constant local variable 'dim' being considered value-dependent when regenerating the lambda (at which point processing_template_decl is set since the lambda is generic), which prevents us from constant folding its uses. Later during prune_lambda_captures we end up not thoroughly walking the body of the lambda and overlook the (non-folded) uses of 'dim' within the array bound and using-decls. We could fix this by making prune_lambda_captures walk the body of the lambda more thoroughly so that it finds these uses of 'dim', but ideally we should be able to constant fold all uses of 'dim' ahead of time and prune the implicit capture after all. To that end this patch makes value_dependent_expression_p return false for such by-ref captures of constant local variables, allowing their uses to get constant folded ahead of time. It seems we just need to disable the predicate's conservative early exit for reference variables (added by r5-5022-g51d72abe5ea04e) when DECL_HAS_VALUE_EXPR_P. This effectively makes us treat by-value and by-ref captures more consistently when it comes to value dependence. PR c++/108975 gcc/cp/ChangeLog: * pt.c (value_dependent_expression_p) : Suppress conservative early exit for reference variables when DECL_HAS_VALUE_EXPR_P. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-const11a.C: New test. (cherry picked from commit 3d674e29d7f89bf93fcfcc963ff0248c6347586d)
[Bug c++/108975] [11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #22 from GCC Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:035fa0105e8d12ca6750545369dd901cb0a2aff0 commit r12-10063-g035fa0105e8d12ca6750545369dd901cb0a2aff0 Author: Patrick Palka Date: Tue Apr 25 15:59:22 2023 -0400 c++: value dependence of by-ref lambda capture [PR108975] We are still ICEing on the generic lambda version of the testcase from this PR, even after r13-6743-g6f90de97634d6f, due to the by-ref capture of the constant local variable 'dim' being considered value-dependent when regenerating the lambda (at which point processing_template_decl is set since the lambda is generic), which prevents us from constant folding its uses. Later during prune_lambda_captures we end up not thoroughly walking the body of the lambda and overlook the (non-folded) uses of 'dim' within the array bound and using-decls. We could fix this by making prune_lambda_captures walk the body of the lambda more thoroughly so that it finds these uses of 'dim', but ideally we should be able to constant fold all uses of 'dim' ahead of time and prune the implicit capture after all. To that end this patch makes value_dependent_expression_p return false for such by-ref captures of constant local variables, allowing their uses to get constant folded ahead of time. It seems we just need to disable the predicate's conservative early exit for reference variables (added by r5-5022-g51d72abe5ea04e) when DECL_HAS_VALUE_EXPR_P. This effectively makes us treat by-value and by-ref captures more consistently when it comes to value dependence. PR c++/108975 gcc/cp/ChangeLog: * pt.cc (value_dependent_expression_p) : Suppress conservative early exit for reference variables when DECL_HAS_VALUE_EXPR_P. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-const11a.C: New test. (cherry picked from commit 3d674e29d7f89bf93fcfcc963ff0248c6347586d)
[Bug c++/108975] [11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #21 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c563e5d6c5177bedf0dd8fc410f390bb3ec37183 commit r13-8170-gc563e5d6c5177bedf0dd8fc410f390bb3ec37183 Author: Patrick Palka Date: Tue Apr 25 15:59:22 2023 -0400 c++: value dependence of by-ref lambda capture [PR108975] We are still ICEing on the generic lambda version of the testcase from this PR, even after r13-6743-g6f90de97634d6f, due to the by-ref capture of the constant local variable 'dim' being considered value-dependent when regenerating the lambda (at which point processing_template_decl is set since the lambda is generic), which prevents us from constant folding its uses. Later during prune_lambda_captures we end up not thoroughly walking the body of the lambda and overlook the (non-folded) uses of 'dim' within the array bound and using-decls. We could fix this by making prune_lambda_captures walk the body of the lambda more thoroughly so that it finds these uses of 'dim', but ideally we should be able to constant fold all uses of 'dim' ahead of time and prune the implicit capture after all. To that end this patch makes value_dependent_expression_p return false for such by-ref captures of constant local variables, allowing their uses to get constant folded ahead of time. It seems we just need to disable the predicate's conservative early exit for reference variables (added by r5-5022-g51d72abe5ea04e) when DECL_HAS_VALUE_EXPR_P. This effectively makes us treat by-value and by-ref captures more consistently when it comes to value dependence. PR c++/108975 gcc/cp/ChangeLog: * pt.cc (value_dependent_expression_p) : Suppress conservative early exit for reference variables when DECL_HAS_VALUE_EXPR_P. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-const11a.C: New test. (cherry picked from commit 3d674e29d7f89bf93fcfcc963ff0248c6347586d)
[Bug rtl-optimization/113002] ICE in commit_one_edge_insertion, at cfgrtl.cc:2095 with new -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002 Alexandre Oliva changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-12-20 --- Comment #2 from Alexandre Oliva --- Mine. memset gets expanded into a loop and inserted in an edge, and when committing the insertion, we complain that the sequence ends in a jump. AFAICT it's fine if it does during expand, we'll break up blocks at suitable spots only after committing the edge inserts from PHI nodes. Relaxing the assert...
[Bug tree-optimization/113012] [13/14 regression] ICE when building xorg-server with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012 --- Comment #9 from GCC Commits --- The master branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:576c1fc4401a9dae9757ac2e4fa37d05e130fa3d commit r14-6730-g576c1fc4401a9dae9757ac2e4fa37d05e130fa3d Author: Siddhesh Poyarekar Date: Mon Dec 18 09:44:00 2023 -0500 tree-object-size: Always set computed bit for bdos [PR113012] It is always safe to set the computed bit for dynamic object sizes at the end of collect_object_sizes_for because even in case of a dependency loop encountered in nested calls, we have an SSA temporary to actually finish the object size expression. The reexamine pass for dynamic object sizes is only for propagation of unknowns and gimplification of the size expressions, not for loop resolution as in the case of static object sizes. gcc/ChangeLog: PR tree-optimization/113012 * tree-object-size.cc (compute_builtin_object_size): Expand comment for dynamic object sizes. (collect_object_sizes_for): Always set COMPUTED bitmap for dynamic object sizes. gcc/testsuite/ChangeLog: PR tree-optimization/113012 * gcc.dg/ubsan/pr113012.c: New test case. Signed-off-by: Siddhesh Poyarekar
[Bug c++/113088] [12/13/14 Regression] Segmentation fault with empty try/catch following try/catch with returns + noexcept destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113088 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Target Milestone|--- |12.4 Status|UNCONFIRMED |NEW Summary|Segmentation fault with |[12/13/14 Regression] |empty try/catch following |Segmentation fault with |try/catch with returns +|empty try/catch following |noexcept destructor |try/catch with returns + ||noexcept destructor Known to fail||12.3.0, 13.2.0, 14.0 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=33799 Keywords||ice-on-valid-code Last reconfirmed||2023-12-20 Known to work||11.4.0 --- Comment #1 from Patrick Palka --- Confirmed, started with r12-6333-gb10e031458d541.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alexandre Oliva --- Fixed.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #4 from Patrick O'Neill --- I can attempt to reduce them however running an iteration of 549 takes multiple hours so it might be challenging using my current setup (creduce). Hopefully the random generator stumbles across the same issue and it can get fixed that way since it's worked for other spec fails previously.
[Bug c++/113088] New: Segmentation fault with empty try/catch following try/catch with returns + noexcept destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113088
Bug ID: 113088
Summary: Segmentation fault with empty try/catch following
try/catch with returns + noexcept destructor
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: beardsley.matt.j at gmail dot com
Target Milestone: ---
Compiling this works with gcc 11.4, but produces ICE (segv) with 12.1 (and
onwards, including trunk according to compiler explorer)
g++ x.cpp
x.cpp contains the following:
struct X {
~X() {}
};
struct Y {
~Y() noexcept(false) {}
};
X foo() {
try {
return {};
} catch (...) {
Y{};
return {};
}
try {
} catch (...) {
}
}
: In function 'X foo()':
:18:5: internal compiler error: Segmentation fault
18 | } catch (...) {
| ^
0x262852c internal_error(char const*, ...)
???:0
0xb6109c maybe_splice_retval_cleanup(tree_node*, bool)
???:0
0xcbd15f do_poplevel(tree_node*)
???:0
0xcc068d finish_compound_stmt(tree_node*)
???:0
0xc4a0ca c_parse_file()
???:0
0xd9a469 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 tree-optimization/113069] gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113069 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Fixed.
[Bug tree-optimization/113069] gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113069 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:40337cae12051336626d39500485cfc488c9c26e commit r14-6725-g40337cae12051336626d39500485cfc488c9c26e Author: Marek Polacek Date: Tue Dec 19 13:23:17 2023 -0500 sccopy: remove unused data member [PR113069] PR tree-optimization/113069 gcc/ChangeLog: * gimple-ssa-sccopy.cc (scc_discovery): Remove unused member.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #3 from JuzheZhong --- (In reply to Patrick O'Neill from comment #2) > No, this is from a random generator but the 527/549 issues could be related? > I haven't reduced spec fails. I can't reproduce spec fails. We have tested it on both QEMU and K230 with -march=rv64gcv_zvl256b, all passed. Could you reduce spec fails ?
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #2 from Patrick O'Neill --- No, this is from a random generator but the 527/549 issues could be related? I haven't reduced spec fails.
[Bug c++/113047] dereferencing a null pointer in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113047
Nathaniel Shead changed:
What|Removed |Added
CC||nathanieloshead at gmail dot
com
--- Comment #4 from Nathaniel Shead ---
I've pushed a fix for PR102420 (and hence comment #1), but looking at the DR
this isn't sufficient for the result of CWG2823, for which presumably all of
the following should also start erroring as well (note none of these error in
Clang yet either):
struct X {
static constexpr int f() { return 0; }
};
constexpr int g(X* x) { return (*x).f(); } // error
constexpr int a = g(nullptr);
constexpr int h(X* x) { return x->f(); } // error
constexpr int b = h(nullptr);
// and similarly
constexpr int test() {
int* p = nullptr;
*p; // error
return 0;
}
constexpr int t = test();
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #1 from JuzheZhong --- Is this coming from SPEC 527 or 549 ?
[Bug target/113087] New: [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
Bug ID: 113087
Summary: [14] RISC-V rv64gcv vector: Runtime mismatch with
rv64gc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Sorry for the non-descriptive issue title - I'm not sure what's going on here.
Testcase:
int(e)(int g, int h) { return h > 0x10 || g > 0x >> h ? g : g << h; }
struct i {
int j;
int l : 1;
};
struct m {
char k;
int n;
};
char o;
char p;
short s;
int q;
struct m r;
int v;
int t;
short z;
long ac;
int ad;
int ae;
static void ai(struct i bf) {
for (; v; v++)
r.k = 0;
do
ac ^= bf.j;
while (bf.j < 0);
s = 0;
if (bf.l)
q |= 0x800;
}
int main() {
struct i aw = {0xE00, 1};
o = 4;
s = p;
ai(aw);
t = 1;
++p;
for (; t <= 7; t++) {
ad &= 1;
(o &= 1 - e(0x4012, ++ae)) & (z |= 1);
}
for (; r.n;)
;
if (o != 4)
return 1;
}
Analysis:
o = 4;
... Ignore first 7 iterations of loop, only consider last iter (ae = 7)
o &= 1 - e(0x4012, ++ae)
expanded:
o = 4 & (1 - e(0x4012, 8))
expanded:
o = 4 & (1 - (8 > 0x10 || 0x4012 > 0x >> 8 ? 0x4012 :
0x4012 << 8))
partially evaluated:
o = 4 & (1 - (false || 0x4012 > 0xFF ? 0x4012 : 0x...1200))
partially evaluated:
o = 4 & (1 - (false || true ? 0x4012 : 0x...1200))
partially evaluated:
o = 4 & (1 - (true ? 0x4012 : 0x...1200))
partially evaluated:
o = 4 & (1 - (0x4012))
partially evaluated:
o = 4 & (0xBFEF)
evaluated:
o = 4
Commands:
> /scratch/tc-testing/tc-dec-19-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -mabi=lp64d -O3 red.c -o rv64gcv.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true timeout
> --verbose -k 0.1 1
> /scratch/tc-testing/tc-dec-19-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gcv.out
> echo $?
1
> /scratch/tc-testing/tc-dec-19-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gc -mabi=lp64d -O3 red.c -o rv64gc.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true timeout
> --verbose -k 0.1 1
> /scratch/tc-testing/tc-dec-19-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gc.out
> echo $?
0
Behavior found using gcc hash: r14-6716-g1502d724df8
[Bug tree-optimization/113069] gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113069 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-12-19 Status|UNCONFIRMED |ASSIGNED
[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
--- Comment #2 from Marek Polacek ---
Previously we had:
{
return A::A (this);
}
now:
{
return *this = {};
}
[Bug c++/97219] [11 Regression] Generic lambda does not find function declaration from enclosing block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97219 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|11.5|12.0 --- Comment #8 from Jason Merrill --- Fixed for GCC 12, backporting seems too complicated.
[Bug c++/106371] Bogus narrowing conversion reported due to bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106371
Lénárd Szolnoki changed:
What|Removed |Added
CC||leni536 at gmail dot com
--- Comment #4 from Lénárd Szolnoki ---
Rejects valid code when -pedantic-errors is added:
struct S {
long l : 8;
};
int main() {
S s;
int i = {s.l};
}
https://godbolt.org/z/5bq6cMaMx
Produces wrong code when it's used as a constraint:
struct S {
long l : 8;
};
template
requires requires (T t) {
int{t.l};
}
void foo(T); // 1
void foo(...); // 2
int main() {
foo(S{}); // calls 2
}
https://godbolt.org/z/We4M1MP1M
[Bug c++/108099] [12 Regression] ICE with type alias with `signed __int128_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Jason Merrill --- Fixed for 12.4/13.
[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113063 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 14, thanks for the bug report.
[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113063 --- Comment #4 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:fced59166f95e9922a72392955e4fed095afd47e commit r14-6724-gfced59166f95e9922a72392955e4fed095afd47e Author: Patrick Palka Date: Tue Dec 19 16:33:55 2023 -0500 c++: local class memfn synth from uneval context [PR113063] Here we first use and therefore synthesize the local class operator<=> from an unevaluated context, which inadvertently affects synthesization by preventing functions used within the definition (such as the copy constructor of std::strong_ordering) from getting marked as odr-used. This patch fixes this by using maybe_push_to_top_level in synthesize_method which ensures cp_unevaluated_operand gets cleared even in the function-local case. PR c++/113063 gcc/cp/ChangeLog: * method.cc (synthesize_method): Use maybe_push_to_top_level and maybe_pop_from_top_level. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-synth16.C: New test.
[Bug c++/102420] null pointer dereference during constant evaluation not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102420 --- Comment #3 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:5ba949c096f5250aa4efb94fb7c94d1304c1bf39 commit r14-6722-g5ba949c096f5250aa4efb94fb7c94d1304c1bf39 Author: Nathaniel Shead Date: Sun Dec 17 12:46:02 2023 +1100 c++: Check null pointer deref when calling memfn in constexpr [PR102420] Calling a non-static member function on a null pointer is undefined behaviour (see [expr.ref] p8) and should error in constant evaluation, even if the 'this' pointer is never actually accessed within that function. One catch is that currently, the function pointer conversion operator for lambdas passes a null pointer as the 'this' pointer to the underlying 'operator()', so for now we ignore such calls. PR c++/102420 gcc/cp/ChangeLog: * constexpr.cc (cxx_bind_parameters_in_call): Check for calling non-static member functions with a null pointer. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-memfn2.C: New test. Signed-off-by: Nathaniel Shead
[Bug c++/103185] [11/12/13/14 Regression] ind[arr] is rejected when arr is an array prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103185 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-12-19 Status|UNCONFIRMED |ASSIGNED
[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #10 from Jason Merrill --- Fixed for GCC 14.
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|ASSIGNED|RESOLVED --- Comment #13 from Jason Merrill --- So let's call this fixed.
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 Bug 58055 depends on bug 58487, which changed state. Bug 58487 Summary: Missed return value optimization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/58487] Missed return value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |14.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Jason Merrill --- Fixed for GCC 14.
[Bug c++/106213] -Werror=deprecated-copy-dtor does not trigger warning and error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106213 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug c++/108975] [11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #20 from Patrick Palka --- (In reply to Jason Merrill from comment #19) > Patrick, do you want to backport your patch? Sure, will do
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #20 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #19) > (In reply to anlauf from comment #18) > > (In reply to Alex Coplan from comment #17) > > > Just a ping: it would be nice if this could be fixed, I'm currently trying > > > to debug/reduce a miscompiled benchmark which has *.f90 source files but > > > -save-temps isn't useful due to this issue. > > > > The patch in comment#16 seems to work and looks good to me, but it appears > > to never have been submitted for review. > > > > One could also add a mini-section in invoke.texi by borrowing from > > gcc/doc/invoke.texi (-> Developer Options) and add a minimal example > > for -save-temps in the context of gfortran use. > > It seems simple. Shall we post the patch to make sure we dont get any > broader objections? If none, then we commit. I'd say let's first give Rimvydas a chance to complete the patch with a commit message, and to submit to the ML. He's the author, and he has submitted patches which he properly signed-off.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #19 from Jerry DeLisle --- (In reply to anlauf from comment #18) > (In reply to Alex Coplan from comment #17) > > Just a ping: it would be nice if this could be fixed, I'm currently trying > > to debug/reduce a miscompiled benchmark which has *.f90 source files but > > -save-temps isn't useful due to this issue. > > The patch in comment#16 seems to work and looks good to me, but it appears > to never have been submitted for review. > > One could also add a mini-section in invoke.texi by borrowing from > gcc/doc/invoke.texi (-> Developer Options) and add a minimal example > for -save-temps in the context of gfortran use. It seems simple. Shall we post the patch to make sure we dont get any broader objections? If none, then we commit.
[Bug c++/108975] [11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 Jason Merrill changed: What|Removed |Added Assignee|jason at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|11.5|11.4 --- Comment #19 from Jason Merrill --- Patrick, do you want to backport your patch?
[Bug c++/58055] [meta-bug] RVO / NRVO improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055 Bug 58055 depends on bug 51571, which changed state. Bug 51571 Summary: No named return value optimization while adding a dummy scope https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/51571] No named return value optimization while adding a dummy scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571 Jason Merrill changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jason Merrill --- But this particular issue is indeed fixed for 14.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #18 from anlauf at gcc dot gnu.org --- (In reply to Alex Coplan from comment #17) > Just a ping: it would be nice if this could be fixed, I'm currently trying > to debug/reduce a miscompiled benchmark which has *.f90 source files but > -save-temps isn't useful due to this issue. The patch in comment#16 seems to work and looks good to me, but it appears to never have been submitted for review. One could also add a mini-section in invoke.texi by borrowing from gcc/doc/invoke.texi (-> Developer Options) and add a minimal example for -save-temps in the context of gfortran use.
[Bug middle-end/113082] builtin transforms do not honor errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082 --- Comment #5 from joseph at codesourcery dot com --- I think it would be reasonable for glibc to require that audit modules don't change errno, at least when acting for libc function calls where glibc guarantees not changing errno. I think user-provided IFUNC resolvers are only relevant for user-provided functions and so shouldn't be relevant to this issue (if a user declares their own function with a noerrno attribute, and also has an IFUNC resolver for that function, they need to make sure the IFUNC resolver behaves consistently with the attribute). It would also seem reasonable for glibc to guarantee that most string and memory functions (maybe excluding a few that involve the locale or other external state, such as strcoll or strerror, and definitely excluding those such as strdup that involve memory allocation) don't change errno. We may need to be careful about what "obviously" shouldn't affect errno (consider e.g. the ongoing discussions around qsort - where avoiding memory allocation should as a side effect also avoid affecting errno, but it's unclear how we might simultaneously avoid memory allocation, keep a stable sort, achieve O(n log(n)) worst case performance, and keep good performance for typical inputs).
[Bug debug/111735] incorrect BTF representation of forward-declared enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111735 --- Comment #2 from GCC Commits --- The master branch has been updated by David Faust : https://gcc.gnu.org/g:1502d724df85163b14b04e8f67072ca88eac411d commit r14-6716-g1502d724df85163b14b04e8f67072ca88eac411d Author: David Faust Date: Tue Dec 12 13:55:59 2023 -0800 btf: change encoding of forward-declared enums [PR111735] The BTF specification does not formally define a representation for forward-declared enum types such as: enum Foo; Forward-declarations for struct and union types are represented by BTF_KIND_FWD, which has a 1-bit flag distinguishing the two. The de-facto standard format used by other tools like clang and pahole is to represent forward-declared enums as BTF_KIND_ENUM with vlen=0, i.e. as a regular enum type with no enumerators. This patch changes GCC to adopt that format, and makes a couple of minor cleanups in btf_asm_type (). gcc/ PR debug/111735 * btfout.cc (btf_fwd_to_enum_p): New. (btf_asm_type_ref): Special case references to enum forwards. (btf_asm_type): Special case enum forwards. Rename btf_size_type to btf_size, and change chained ifs switching on btf_kind into else ifs. gcc/testsuite/ PR debug/111735 * gcc.dg/debug/btf/btf-forward-2.c: New test.
[Bug d/113081] static linking does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113081 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-12-19 Keywords||link-failure Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/113086] New: m68k: ICE at emit-rtl.cc:2287 with -fzero-call-used-regs=all -fPIE compiling openssh 9.6p1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113086 Bug ID: 113086 Summary: m68k: ICE at emit-rtl.cc:2287 with -fzero-call-used-regs=all -fPIE compiling openssh 9.6p1 Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ats-gccbugs at offog dot org Target Milestone: --- Created attachment 56906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56906=edit Preprocessed source This may be a duplicate of 110934. GCC 13.2.0 running on x86_64-pc-linux-gnu, targeting m68k-linux-gnu. Preprocessed source attached. The code being cross-compiled is misc.c from openssh 9.6p1, cut down to just the bandwidth_limit function - the same ICE comes up in other OpenSSH files too. Removing either -fzero-call-used-regs=used or -fPIE prevents the ICE. $ /gar/bin/m68k-linux-gnu-gcc -v -save-temps -freport-bug -g -O2 -fno-strict-aliasing -ftrapv -fzero-call-used-regs=used -ftrivial-auto-var-init=zero -fno-builtin-memset -fstack-protector-strong -fPIE -I. -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_GNU_SOURCE -DHAVE_CONFIG_H -o misc-cutdown.o -c misc-cutdown.c Using built-in specs. COLLECT_GCC=/gar/bin/m68k-linux-gnu-gcc Target: m68k-linux-gnu Configured with: /src/devel/gcc-m68k/work/gcc-13.2.0/configure --prefix=/gar --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/com --target=m68k-linux-gnu --with-sysroot=/cross/linux-m68k --disable-libssp --disable-libcc1 --disable-multilib --with-system-zlib --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-g' '-O2' '-fno-strict-aliasing' '-ftrapv' '-fzero-call-used-regs=used' '-ftrivial-auto-var-init=zero' '-fno-builtin-memset' '-fstack-protector-strong' '-fPIE' '-I' '.' '-D' '_XOPEN_SOURCE=600' '-D' '_BSD_SOURCE' '-D' '_DEFAULT_SOURCE' '-D' '_GNU_SOURCE' '-D' 'HAVE_CONFIG_H' '-o' 'misc-cutdown.o' '-c' '-mcpu=68020' /gar/packages/gcc-m68k-13.2.0/bin/../libexec/gcc/m68k-linux-gnu/13.2.0/cc1 -E -quiet -v -I . -iprefix /gar/packages/gcc-m68k-13.2.0/bin/../lib/gcc/m68k-linux-gnu/13.2.0/ -D _XOPEN_SOURCE=600 -D _BSD_SOURCE -D _DEFAULT_SOURCE -D _GNU_SOURCE -D HAVE_CONFIG_H misc-cutdown.c -mcpu=68020 -freport-bug -fno-strict-aliasing -ftrapv -fzero-call-used-regs=used -ftrivial-auto-var-init=zero -fno-builtin-memset -fstack-protector-strong -fPIE -g -fworking-directory -O2 -fpch-preprocess -o misc-cutdown.i ignoring duplicate directory "/gar/packages/gcc-m68k-13.2.0/bin/../lib/gcc/../../lib/gcc/m68k-linux-gnu/13.2.0/include" ignoring nonexistent directory "/cross/linux-m68k/usr/local/include" ignoring duplicate directory "/gar/packages/gcc-m68k-13.2.0/bin/../lib/gcc/../../lib/gcc/m68k-linux-gnu/13.2.0/include-fixed" ignoring duplicate directory "/gar/packages/gcc-m68k-13.2.0/bin/../lib/gcc/../../lib/gcc/m68k-linux-gnu/13.2.0/../../../../m68k-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: . /gar/packages/gcc-m68k-13.2.0/bin/../lib/gcc/m68k-linux-gnu/13.2.0/include /gar/packages/gcc-m68k-13.2.0/bin/../lib/gcc/m68k-linux-gnu/13.2.0/include-fixed /gar/packages/gcc-m68k-13.2.0/bin/../lib/gcc/m68k-linux-gnu/13.2.0/../../../../m68k-linux-gnu/include /cross/linux-m68k/usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-g' '-O2' '-fno-strict-aliasing' '-ftrapv' '-fzero-call-used-regs=used' '-ftrivial-auto-var-init=zero' '-fno-builtin-memset' '-fstack-protector-strong' '-fPIE' '-I' '.' '-D' '_XOPEN_SOURCE=600' '-D' '_BSD_SOURCE' '-D' '_DEFAULT_SOURCE' '-D' '_GNU_SOURCE' '-D' 'HAVE_CONFIG_H' '-o' 'misc-cutdown.o' '-c' '-mcpu=68020' /gar/packages/gcc-m68k-13.2.0/bin/../libexec/gcc/m68k-linux-gnu/13.2.0/cc1 -fpreprocessed misc-cutdown.i -quiet -dumpbase misc-cutdown.c -dumpbase-ext .c -mcpu=68020 -g -O2 -version -freport-bug -fno-strict-aliasing -ftrapv -fzero-call-used-regs=used -ftrivial-auto-var-init=zero -fno-builtin-memset -fstack-protector-strong -fPIE -o misc-cutdown.s GNU C17 (GCC) version 13.2.0 (m68k-linux-gnu) compiled by GNU C version 13.2.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3fc6ded084c3f48f4ac8f43a1a9564e4 during RTL pass: zero_call_used_regs misc-cutdown.c: In function ‘bandwidth_limit’: misc-cutdown.c:108:1: internal compiler error: in change_address_1, at emit-rtl.cc:2287 108 | } | ^ 0x7f684ed71c49 __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7f684ed71d04 __libc_start_main_impl ../csu/libc-start.c:360 0xb34c70 _start ../sysdeps/x86_64/start.S:115 Please submit a full bug report,
[Bug target/113040] [14 Regression] libmvec test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/104820] mips: ICE in int_mode_for_mode, at stor-layout.cc:407 with -fzero-call-used-regs=all -mips4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104820 --- Comment #2 from Andrew Pinski --- (In reply to matoro from comment #1) > This also seems to affect ia64 I think: IA64 is most likely a different issue, BImode used there. I would file it as a seperate bug.
[Bug testsuite/113085] New: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085 Bug ID: 113085 Summary: New test case libgomp.c/alloc-pinned-1.c from r14-6499-g348874f0baac0f fails Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:348874f0baac0f22c98ab11abbfa65fd172f6bdd, r14-6499-g348874f0baac0f make -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/alloc-pinned-1.c" FAIL: libgomp.c/alloc-pinned-1.c execution test # of expected passes1 # of unexpected failures1 commit 348874f0baac0f22c98ab11abbfa65fd172f6bdd (HEAD) Author: Andrew Stubbs Date: Tue Jan 4 12:22:01 2022 + libgomp: basic pinned memory on Linux spawn [open ...] unsufficient lockable memory; please increase ulimit FAIL: libgomp.c/alloc-pinned-1.c execution test "Unsufficient"? Is that a typo? In any case I don't think a test should require an unusual ulimit setting. seurer@ltcden2-lp1:~/gcc/git/build/gcc-test$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 3909068 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 3909068 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
[Bug middle-end/113084] aarch64: vget_low blocks tail-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113084 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=14441, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107503 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-19 --- Comment #2 from Andrew Pinski --- Also related to PR 107503 .
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #19 from Mark Wielaard --- (In reply to David Binderman from comment #18) > (In reply to Mark Wielaard from comment #17) > > I am surprised valgrind memcheck doesn't produce more output, normally it > > would tell you why & where it found the address invalid. > > The valgrind output I gave originally looks to be in the usual valgrind > format to me. > Perhaps you are assuming some other debugging tool like asan or ubsan ? Normally valgrind adds something like: Address 0xaa is x bytes inside a block of size y free'd please a stacktrace where that block was allocated/freed In this case I would expect to say something like that the address that is being access is after a block. Assuming it is indeed not accessible. The read of 4 bytes is interesting, it seems to mean that valgrind decided to chop up this read into smaller blocks. > > I assume somehow > > valgrind memcheck believes it is reading past the end of a data buffer, > > while the code assumes this is fine because it will mask off the bits it > > won't use. > > valgrind doesn't normally produce an error for copying around un-initialised > bytes. > > However, it will produce an error if those bytes are used in a decision > like an if statement. Or it will produce an error if it is an unaddressible location. Which seems to be the case here. I would try to figure out which address exactly it is, what the exact arm/neon (?) instruction it is that is being executed. How many bytes it is supposed to read and if that many bytes are actually available. If this is an overread then you might try --partial-loads-ok=yes (although that should be the default these days). If that doesn't work then valgrind might have chopped up the read into smaller blocks, so memcheck cannot see that it is a larger load and the backend (VEX/priv/guest_arm_toIR.c) might have to be adjusted.
[Bug target/104820] mips: ICE in int_mode_for_mode, at stor-layout.cc:407 with -fzero-call-used-regs=all -mips4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104820
matoro changed:
What|Removed |Added
CC||matoro_gcc_bugzilla@matoro.
||tk
--- Comment #1 from matoro ---
This also seems to affect ia64 I think:
# echo 'int t() {}' | ia64-unknown-linux-gnu-gcc -nostdinc
-fzero-call-used-regs=all -x c -
during RTL pass: zero_call_used_regs
: In function ‘t’:
:1:10: internal compiler error: in int_mode_for_mode, at
stor-layout.cc:407
linux-gate.so.1: Bad address
0x4285670f internal_error(char const*, ...)
???:0
0x401c885f fancy_abort(char const*, int, char const*)
???:0
0x411004af int_mode_for_mode(machine_mode)
???:0
0x408290ef emit_move_insn_1(rtx_def*, rtx_def*)
???:0
0x408298bf emit_move_insn(rtx_def*, rtx_def*)
???:0
0x41119e0f default_zero_call_used_regs(HARD_REG_SET)
???: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 middle-end/113084] aarch64: vget_low blocks tail-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113084 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/113084] aarch64: vget_low blocks tail-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113084 Andrew Pinski changed: What|Removed |Added Component|target |middle-end Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- Gcc also currently does not support tail calls if the types change. There is another bug about that.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #18 from David Binderman --- (In reply to Mark Wielaard from comment #17) > I am surprised valgrind memcheck doesn't produce more output, normally it > would tell you why & where it found the address invalid. The valgrind output I gave originally looks to be in the usual valgrind format to me. Perhaps you are assuming some other debugging tool like asan or ubsan ? > I assume somehow > valgrind memcheck believes it is reading past the end of a data buffer, > while the code assumes this is fine because it will mask off the bits it > won't use. valgrind doesn't normally produce an error for copying around un-initialised bytes. However, it will produce an error if those bytes are used in a decision like an if statement. Your unconfirmed assumption agrees with mine, though.
[Bug c++/90679] Template specialization with const: “ambiguous template instantiation” error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90679 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |14.0 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Patrick Palka --- Fixed for GCC 14, thanks for the bug report.
[Bug c++/90679] Template specialization with const: “ambiguous template instantiation” error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90679
--- Comment #2 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:0a37463758dabc9647fa3d675dffdf43a737035d
commit r14-6715-g0a37463758dabc9647fa3d675dffdf43a737035d
Author: Patrick Palka
Date: Tue Dec 19 11:40:15 2023 -0500
c++: partial ordering and dep alias tmpl specs [PR90679]
During partial ordering, we want to look through dependent alias
template specializations within template arguments and otherwise
treat them as opaque in other contexts (see e.g. r7-7116-g0c942f3edab108
and r11-7011-g6e0a231a4aa240). To that end template_args_equal was
given a partial_order flag that controls this behavior. This flag
does the right thing when a dependent alias template specialization
appears as template argument of the partial specialization, e.g. in
template using first_t = T;
template struct traits;
template struct traits> { }; // #1
template struct traits> { }; // #2
we correctly consider #2 to be more specialized than #1. But if the
alias specialization appears as a nested template argument of another
class template specialization, e.g. in
template struct traits>> { }; // #1
template struct traits>> { }; // #2
then we incorrectly consider #1 and #2 to be unordered. This is because
1. we don't propagate the flag to recursive template_args_equal calls
2. we don't use structural equality for class template specializations
written in terms of dependent alias template specializations
This patch fixes the first issue by turning the partial_order flag into
a global. This patch fixes the second issue by making us propagate
structural equality appropriately when building a class template
specialization. In passing this patch also improves hashing of
specializations that use structural equality.
PR c++/90679
gcc/cp/ChangeLog:
* cp-tree.h (comp_template_args): Remove partial_order parameter.
(template_args_equal): Likewise.
* pt.cc (comparing_for_partial_ordering): New global flag.
(iterative_hash_template_arg) : Hash the template
and arguments for specializations that use structural equality.
(template_args_equal): Remove partial order parameter and
use comparing_for_partial_ordering instead.
(comp_template_args): Likewise.
(comp_template_args_porder): Set comparing_for_partial_ordering
instead. Make static.
(any_template_arguments_need_structural_equality_p): Return true
for an argument that's a dependent alias template specialization
or a class template specialization that itself needs structural
equality.
* tree.cc (cp_tree_equal) : Adjust call to
comp_template_args.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-75a.C: New test.
* g++.dg/cpp0x/alias-decl-75b.C: New test.
[Bug c++/90679] Template specialization with const: “ambiguous template instantiation” error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90679 --- Comment #1 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6d27ee7fcc3e31c2142124027dc87e5a0288c9ab commit r14-6714-g6d27ee7fcc3e31c2142124027dc87e5a0288c9ab Author: Patrick Palka Date: Tue Dec 19 11:26:34 2023 -0500 c++: refine dependent_alias_template_spec_p [PR90679] For a (complex) alias template-id, dependent_alias_template_spec_p returns true if any template argument of the template-id is dependent. This predicate indicates that substitution into the template-id may behave differently with respect to SFINAE than substitution into the expanded alias, and so the alias is in a way non-transparent. For example, 'first_t' in template using first_t = T; template first_t f(); is such an alias template-id since first_t doesn't use its second template parameter and so the substitution into the expanded alias would discard the SFINAE effects of the corresponding (dependent) argument 'T&'. But this predicate is overly conservative since what really matters for sake of SFINAE equivalence is whether a template argument corresponding to an _unused_ template parameter is dependent. So the predicate should return false for e.g. 'first_t'. This patch refines the predicate appropriately. We need to be able to efficiently determine which template parameters of a complex alias template are unused, so to that end we add a new out parameter to complex_alias_template_p and cache its result in an on-the-side hash_map that replaces the existing TEMPLATE_DECL_COMPLEX_ALIAS_P flag. PR c++/90679 gcc/cp/ChangeLog: * cp-tree.h (TEMPLATE_DECL_COMPLEX_ALIAS_P): Remove. (most_general_template): Constify parameter. * pt.cc (push_template_decl): Adjust after removing TEMPLATE_DECL_COMPLEX_ALIAS_P. (complex_alias_tmpl_info): New hash_map. (uses_all_template_parms_data::seen): Change type to tree* from bool*. (complex_alias_template_r): Adjust accordingly. (complex_alias_template_p): Add 'seen_out' out parameter. Call most_general_template and check PRIMARY_TEMPLATE_P. Use complex_alias_tmpl_info to cache the result and set '*seen_out' accordigly. (dependent_alias_template_spec_p): Add !processing_template_decl early exit test. Consider dependence of only template arguments corresponding to seen template parameters as per gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-76.C: New test.
[Bug target/113070] [14 regression] [AArch64] [PGO/LTO] Miscompilation of go compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070 Alex Coplan changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org --- Comment #2 from Alex Coplan --- Adding -mno-early-ldp-fusion -mno-late-ldp-fusion to the compile flags fixes the bootstrap, so it seems to be triggered by the new load/store pair fusion pass. I'll take a look.
[Bug target/113084] New: aarch64: vget_low blocks tail-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113084
Bug ID: 113084
Summary: aarch64: vget_low blocks tail-call
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joe.ramsay at arm dot com
Target Milestone: ---
In the following, f could be tail-called.
#include
float32x4_t f(float32x4_t);
float32x2_t g(float32x2_t x) {
return vget_low_f32 (f (vcombine_f32 (x, x)));
}
however GCC 13 emits the following at O1, O2 and O3
g:
ins v0.d[1], v0.d[0]
stp x29, x30, [sp, -16]!
mov x29, sp
bl f
ldp x29, x30, [sp], 16
ret
I observed the same or worse codegen for all versions of Arm64 GCC on Compiler
Explorer
[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #6 from Marek Polacek ---
(In reply to m.cencora from comment #4)
> This also might be a just another symptom of the same root cause:
>
> struct bar
> {
> bar() = default;
>
> bar(const bar&);
> bar(bar&&);
>
> bar& operator=(const bar&);
> bar& operator=(bar&&);
> };
>
> struct foo
> {
> operator const bar& () const &;
>
> operator bar& () &;
>
> operator bar&&() &&;
> };
>
> void test()
> {
> bar a = foo{}; // ok
>
> a = foo{}; // not ok - ambiguous call, but why? &&-qualified looks like
> a better match
>
> foo f;
> a = f; // ok
>
> a = static_cast(foo{}); // ok
> }
Here the error showed up in r9-6486:
commit c7e936dbc7f59ad09c28ef57e5399a4256061747
Author: Jason Merrill
Date: Mon Mar 11 23:19:22 2019 -0400
PR c++/86521 - wrong overload resolution with ref-qualifiers.
Here we were wrongly treating binding a const lvalue ref to an xvalue as
direct binding, which is wrong under [dcl.init.ref] and [over.match.ref].
[Bug target/113076] [14] RISC-V: gfortran.dg/dec_io_1.f90 runtime error after r14-4972-g8aa47713701
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113076 Edwin Lu changed: What|Removed |Added Summary|[14] RISC-V:|[14] RISC-V: |gfortran.dg/dec_io_1.f90|gfortran.dg/dec_io_1.f90 |runtime error after |runtime error after |r14-4971-g0beb1611754 |r14-4972-g8aa47713701 --- Comment #2 from Edwin Lu --- (In reply to Richard Biener from comment #1) > The bisection is highly suspicious since that's a x86 specific change that > doesn't affect riscv. Sorry about that I linked the wrong commit. I bisected it down to r14-4972-g8aa47713701 8aa47713701b1f1878b81169852269a299272e87 is the first bad commit commit 8aa47713701b1f1878b81169852269a299272e87 Author: Vladimir N. Makarov Date: Fri Oct 27 08:28:24 2023 -0400 [RA]: Add cost calculation for reg equivalence invariants My recent patch improving cost calculation for pseudos with equivalence resulted in failure of gcc.target/arm/eliminate.c on aarch64. This patch fixes this failure. gcc/ChangeLog: * ira-costs.cc: (get_equiv_regno, calculate_equiv_gains): Process reg equivalence invariants. gcc/ira-costs.cc | 4 1 file changed, 4 insertions(+)
[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2023-12-19 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Priority|P3 |P1 Ever confirmed|0 |1
[Bug middle-end/113082] builtin transforms do not honor errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #4 from Alexander Monakov ---
re. comment #3, you'd need to be careful to avoid miscompiling
#include
int f(size_t sz, void **out, int *eptr)
{
int e = *eptr;
*out = malloc(sz);
return *eptr - e;
}
to asm that unconditionally returns 0, because that changes the outcome for
errno = 0;
f(SIZE_MAX, , );
IOW, I'm not sure how you can go beyond TBAA since user code can pass around
the address of errno in a plain 'int *' anyway.
re. comment #2, Glibc has
* lazy PLT resolver calling back into the dynamic linker
* LD_AUDIT callbacks
* LD_PROFILE hooks
* IFUNC resolvers
and you'd have to guarantee they won't clobber errno either. For lazy PLT and
LD_PROFILE it is necessary anyway (otherwise it's a Glibc bug), but audit and
ifunc callbacks are provided by the user, not Glibc, and might accidentally
clobber errno.
[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Maybe targetm.cxx.cdtor_returns_this () related?
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #17 from Alex Coplan --- Just a ping: it would be nice if this could be fixed, I'm currently trying to debug/reduce a miscompiled benchmark which has *.f90 source files but -save-temps isn't useful due to this issue.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #17 from Mark Wielaard --- I am surprised valgrind memcheck doesn't produce more output, normally it would tell you why & where it found the address invalid. I assume somehow valgrind memcheck believes it is reading past the end of a data buffer, while the code assumes this is fine because it will mask off the bits it won't use.
[Bug target/113070] [14 regression] [AArch64] [PGO/LTO] Miscompilation of go compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||acoplan at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-12-19 --- Comment #1 from Alex Coplan --- Confirmed, I can reproduce the bootstrap failure. I will investigate further. I'm also looking at another LTO + PGO runtime failure which seems to be triggered by the new load/store pair fusion pass, these might be related.
[Bug c++/113083] [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083 Richard Biener changed: What|Removed |Added Component|target |c++ Target Milestone|--- |14.0
[Bug tree-optimization/113080] Missed optimization of loop invariant elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113080 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/113073] [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113073 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Should be fixed.
[Bug target/113073] [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113073 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:aa2a48984c3d8c7a6a6da10d924e030b141b44cd commit r14-6683-gaa2a48984c3d8c7a6a6da10d924e030b141b44cd Author: Richard Biener Date: Tue Dec 19 09:58:03 2023 +0100 tree-optimization/113073 - amend PR112736 fix The PR112736 testcase fails on RISC-V because the aligned exception uses the wrong check. The alignment support scheme can be dr_aligned even when the access isn't aligned to the vector size but some targets are happy with element alignment. The following fixes that. PR tree-optimization/113073 * tree-vect-stmts.cc (vectorizable_load): Properly ensure to exempt only vector-size aligned overreads.
[Bug tree-optimization/113080] Missed optimization of loop invariant elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113080 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:afd49e663258061a10f0f2c4a8f8aa2bf97bee42 commit r14-6684-gafd49e663258061a10f0f2c4a8f8aa2bf97bee42 Author: Richard Biener Date: Tue Dec 19 10:51:06 2023 +0100 tree-optimization/113080 - missing final value replacement When performing final value replacement we guard against exponential (temporary) code growth due to unsharing of trees (SCEV heavily relies on tree sharing). The following relaxes this a tiny bit to cover some more optimizations and puts in comments as to what the real fix would be. PR tree-optimization/113080 * tree-scalar-evolution.cc (expression_expensive_p): Allow a tiny bit of growth due to expansion of shared trees. (final_value_replacement_loop): Add comment. * gcc.dg/tree-ssa/sccp-3.c: New testcase.
[Bug target/113040] [14 Regression] libmvec test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot gnu.org --- Comment #4 from avieira at gcc dot gnu.org --- Yeah my bad. For cases where we don't expose the definition the new code sequence doesn't add multiple vector parameters for cases where the vector length of the single parameter is less than that of the simdclone's simdlen. Testing a patch now.
[Bug target/113083] New: [14 Regression][arm] ICE in fold_convert_loc, at fold-const.cc:2602 since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
Bug ID: 113083
Summary: [14 Regression][arm] ICE in fold_convert_loc, at
fold-const.cc:2602 since r14-5979-g99d114c15523e0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at suse dot cz
CC: polacek at redhat dot com
Target Milestone: ---
Target: arm
Compiling reduced testcase g++.dg/cpp0x/constexpr-98295.C results in ICE since
r14-5979-g99d114c15523e0.
$ cat constexpr-98295.C
struct A { constexpr A(); };
void f() {
A b;
}
constexpr A::A() {}
$ arm-linux-gnueabi-g++ constexpr-98295.C -Os
constexpr-98295.C: In constructor ‘constexpr A::A()’:
constexpr-98295.C:7:19: internal compiler error: in fold_convert_loc, at
fold-const.cc:2602
7 | constexpr A::A() {}
| ^
0x1517af9 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/home/mjires/git/GCC/master/gcc/fold-const.cc:2602
0x1613814 gimplify_modify_expr
/home/mjires/git/GCC/master/gcc/gimplify.cc:6353
0x16471a1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mjires/git/GCC/master/gcc/gimplify.cc:17640
0x1617f67 gimplify_stmt(tree_node**, gimple**)
/home/mjires/git/GCC/master/gcc/gimplify.cc:7477
0x15ff631 gimplify_and_add(tree_node*, gimple**)
/home/mjires/git/GCC/master/gcc/gimplify.cc:493
0x16045a5 gimplify_return_expr
/home/mjires/git/GCC/master/gcc/gimplify.cc:1883
0x16482da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mjires/git/GCC/master/gcc/gimplify.cc:17902
0x1617f67 gimplify_stmt(tree_node**, gimple**)
/home/mjires/git/GCC/master/gcc/gimplify.cc:7477
0x1605a4d gimplify_statement_list
/home/mjires/git/GCC/master/gcc/gimplify.cc:
0x1649002 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mjires/git/GCC/master/gcc/gimplify.cc:18085
0x1617f67 gimplify_stmt(tree_node**, gimple**)
/home/mjires/git/GCC/master/gcc/gimplify.cc:7477
0x1603668 gimplify_bind_expr
/home/mjires/git/GCC/master/gcc/gimplify.cc:1614
0x1647f13 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/mjires/git/GCC/master/gcc/gimplify.cc:17841
0x1617f67 gimplify_stmt(tree_node**, gimple**)
/home/mjires/git/GCC/master/gcc/gimplify.cc:7477
0x164bdb4 gimplify_body(tree_node*, bool)
/home/mjires/git/GCC/master/gcc/gimplify.cc:18907
0x164c6a9 gimplify_function_tree(tree_node*)
/home/mjires/git/GCC/master/gcc/gimplify.cc:19106
0x13a0cb1 cgraph_node::analyze()
/home/mjires/git/GCC/master/gcc/cgraphunit.cc:685
0x13a2d6d analyze_functions
/home/mjires/git/GCC/master/gcc/cgraphunit.cc:1248
0x13a62f3 symbol_table::finalize_compilation_unit()
/home/mjires/git/GCC/master/gcc/cgraphunit.cc:2555
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ arm-linux-gnueabi-g++ -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/arm-linux-gnueabi/14.0.0/lto-wrapper
Target: arm-linux-gnueabi
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=arm-linux-gnueabi
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231219 (experimental) (GCC)
[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064 --- Comment #5 from m.cencora at gmail dot com --- (In reply to m.cencora from comment #4) > This also might be a just another symptom of the same root cause: This one is actually a regression (worked on gcc 8.3 and older)
[Bug middle-end/90868] Duplicate OpenACC 'declare' directives for `extern` variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90868 --- Comment #2 from GCC Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:cf840a7f7c14242ab7018071310851486a557d4f commit r14-6681-gcf840a7f7c14242ab7018071310851486a557d4f Author: Thomas Schwinge Date: Mon Dec 18 17:25:17 2023 +0100 Unify OpenACC/C and C++ behavior re duplicate OpenACC 'declare' directives for 'extern' variables [PR90868] This likely still isn't what OpenACC actually intends (addressing that is for another day), but at least we now misbehave consistently for C and C++. PR c++/90868 gcc/cp/ * parser.cc (cp_parser_oacc_declare): For "more than once", check the DECL that we're actually setting the attribute on. gcc/testsuite/ * c-c++-common/goacc/declare-1.c: Adjust. * c-c++-common/goacc/declare-2.c: Likewise.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:06ffe577036fa58968960afc62e16349fa43d496 commit r13-8168-g06ffe577036fa58968960afc62e16349fa43d496 Author: Richard Biener Date: Tue Dec 5 14:00:43 2023 +0100 sanitizer/111736 - skip ASAN for globals in alternate address-space PR sanitizer/111736 * asan.cc (asan_protect_global): Do not protect globals in non-generic address-space. (cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #8 from Richard Biener --- (In reply to Uroš Bizjak from comment #7) > (In reply to GCC Commits from comment #5) > > The master branch has been updated by Richard Biener : > > Can this patch be backported to gcc-13 branch? Sure - I'll test/push it.
[Bug tree-optimization/113080] Missed optimization of loop invariant elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113080
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-12-19
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
Confirmed. We're considering the final value replacement of the 't' reduction
expensive. It's
((b_lsm.10_8 + a_lsm.9_9) + t_10(D)) + (b_lsm.10_8 + a_lsm.9_9) * 99
and since there's a shared tree (b_lsm.10_8 + a_lsm.9_9) which we'd
duplicate (materializing as GIMPLE fails to immediately CSE).
bool
expression_expensive_p (tree expr, bool *cond_overflow_p)
{
hash_map cache;
uint64_t expanded_size = 0;
*cond_overflow_p = false;
return (expression_expensive_p (expr, cond_overflow_p, cache, expanded_size)
|| expanded_size > cache.elements ());
}
where expanded_size is 5 but cache.elements () is 4 (we grow because
of unsharing).
Allowing a little bit of unsharing fixes this. Even better would be of
course an unsharing mechanism that would "save" the shared parts to
a gimple sequence (we need to unshare because gimplification is destructive
and the SCEV result contains trees that can be part of the SCEV cache
which we may not alter).
[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #21 from Jakub Jelinek --- Should be fixed now.
[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 --- Comment #20 from GCC Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d9b7e78dae13945dd9b296f2cca67650da0f869d commit r11-11159-gd9b7e78dae13945dd9b296f2cca67650da0f869d Author: Jakub Jelinek Date: Tue Dec 19 10:24:33 2023 +0100 i386: Fix mmx.md signbit expanders [PR112816] Apparently when looking for "signbit2" vector expanders, I've only looked at sse.md and forgot mmx.md, which has another one and the following patch still ICEd. 2023-12-19 Jakub Jelinek PR target/112816 * config/i386/mmx.md (signbitv2sf2): Force operands[1] into a REG. * gcc.target/i386/sse2-pr112816-2.c: New test. (cherry picked from commit 80e1375ed7a7a05a5a60a57e72c5ad5eba005798)
[Bug middle-end/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113077 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-12-19 Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org --- Comment #3 from Alex Coplan --- Confirmed, started with my r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45, I can take a look.
[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 --- Comment #19 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:08a9df82bc2958df1c5508a0352d31a29c0ebe74 commit r12-10061-g08a9df82bc2958df1c5508a0352d31a29c0ebe74 Author: Jakub Jelinek Date: Tue Dec 19 10:24:33 2023 +0100 i386: Fix mmx.md signbit expanders [PR112816] Apparently when looking for "signbit2" vector expanders, I've only looked at sse.md and forgot mmx.md, which has another one and the following patch still ICEd. 2023-12-19 Jakub Jelinek PR target/112816 * config/i386/mmx.md (signbitv2sf2): Force operands[1] into a REG. * gcc.target/i386/sse2-pr112816-2.c: New test. (cherry picked from commit 80e1375ed7a7a05a5a60a57e72c5ad5eba005798)
[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 --- Comment #18 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0cf251fba0f0a374225a81021af5ec6c6ccceb5b commit r13-8167-g0cf251fba0f0a374225a81021af5ec6c6ccceb5b Author: Jakub Jelinek Date: Tue Dec 19 10:24:33 2023 +0100 i386: Fix mmx.md signbit expanders [PR112816] Apparently when looking for "signbit2" vector expanders, I've only looked at sse.md and forgot mmx.md, which has another one and the following patch still ICEd. 2023-12-19 Jakub Jelinek PR target/112816 * config/i386/mmx.md (signbitv2sf2): Force operands[1] into a REG. * gcc.target/i386/sse2-pr112816-2.c: New test. (cherry picked from commit 80e1375ed7a7a05a5a60a57e72c5ad5eba005798)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #7 from Uroš Bizjak --- (In reply to GCC Commits from comment #5) > The master branch has been updated by Richard Biener : Can this patch be backported to gcc-13 branch?
[Bug target/113062] [14 Regression][aarch64] ICE in fuse_pair, at config/aarch64/aarch64-ldp-fusion.cc:1456 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113062 Alex Coplan changed: What|Removed |Added Keywords||patch --- Comment #3 from Alex Coplan --- Candidate fix: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640957.html
[Bug target/113061] [14 Regression][aarch64] ICE in lra_create_new_reg_with_unique_value, at lra.cc:192 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113061 Alex Coplan changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Alex Coplan --- Should be fixed, thanks for the report.
[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 --- Comment #17 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:80e1375ed7a7a05a5a60a57e72c5ad5eba005798 commit r14-6679-g80e1375ed7a7a05a5a60a57e72c5ad5eba005798 Author: Jakub Jelinek Date: Tue Dec 19 10:24:33 2023 +0100 i386: Fix mmx.md signbit expanders [PR112816] Apparently when looking for "signbit2" vector expanders, I've only looked at sse.md and forgot mmx.md, which has two further ones and the following patch still ICEd. 2023-12-19 Jakub Jelinek PR target/112816 * config/i386/mmx.md (signbitv2sf2, signbit2): Force operands[1] into a REG. * gcc.target/i386/sse2-pr112816-2.c: New test.
[Bug target/113061] [14 Regression][aarch64] ICE in lra_create_new_reg_with_unique_value, at lra.cc:192 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113061 --- Comment #3 from GCC Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:2cd55480857bf310c9be7daea39ea266772d3666 commit r14-6678-g2cd55480857bf310c9be7daea39ea266772d3666 Author: Alex Coplan Date: Tue Dec 19 09:22:20 2023 + aarch64: Fix parens in aarch64_stp_reg_operand [PR113061] In r14-6603-gfcdd2757c76bf925115b8e1ba4318d6366dd6f09 I messed up the parentheses in aarch64_stp_reg_operand, the indentation shows the intended nesting of the conditions. This patch fixes that. This fixes PR113061 which shows IRA substituting (const_int 1) into a writeback stp pattern as a result (and LRA failing to reload the constant). gcc/ChangeLog: PR target/113061 * config/aarch64/predicates.md (aarch64_stp_reg_operand): Fix parentheses to match intent. gcc/testsuite/ChangeLog: PR target/113061 * gfortran.dg/PR113061.f90: New test.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #16 from Jonathan Wakely --- Not sheer fluke, it was the same ^d4ba3b369c commit both times, because that was the oldest commit in your clone.
[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
--- Comment #4 from m.cencora at gmail dot com ---
This also might be a just another symptom of the same root cause:
struct bar
{
bar() = default;
bar(const bar&);
bar(bar&&);
bar& operator=(const bar&);
bar& operator=(bar&&);
};
struct foo
{
operator const bar& () const &;
operator bar& () &;
operator bar&&() &&;
};
void test()
{
bar a = foo{}; // ok
a = foo{}; // not ok - ambiguous call, but why? &&-qualified looks like a
better match
foo f;
a = f; // ok
a = static_cast(foo{}); // ok
}
[Bug target/113079] [x86] Fails to generate dot_prod instructions for 64-bit vector.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113079 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-12-19 --- Comment #2 from Richard Biener --- It's includes a lane reduction so we need to have those zero at least on GIMPLE (if we'd do it there) because the tree codes do not specify which lanes are reduced. The actual x86 instruction is probably fine so if you make V8QI operation available in the backend that should work without zeroing.
