[Bug c++/109247] New: [13 Regression] error: converting to ‘optional’ from initializer list would use explicit constructor ‘optional<_Tp>::optional(_Up) [with _Up = int; _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247
Bug ID: 109247
Summary: [13 Regression] error: converting to
‘optional’ from
initializer list would use explicit constructor
‘optional<_Tp>::optional(_Up) [with _Up = int; _Tp =
WebCore::SourceBrush::Brush]’ since
r13-6765-ga226590fefb35ed6
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
The following is reduced from webkit2gtk3:gtk3 package:
$ cat webcore13.ii
template struct optional {
template explicit optional(_Up);
template void operator=(_Up);
};
namespace WebCore {
int setPattern_pattern;
struct SourceBrush {
struct Brush {
int brush;
};
void setPattern() { m_brush = {setPattern_pattern}; }
optional m_brush;
};
} // namespace WebCore
$ clang++ webcore13.ii -c && g++-12 webcore13.ii -c
$ g++ webcore13.ii -c
webcore13.ii: In member function ‘void WebCore::SourceBrush::setPattern()’:
webcore13.ii:11:52: error: converting to
‘optional’ from initializer list would use
explicit constructor ‘optional<_Tp>::optional(_Up) [with _Up = int; _Tp =
WebCore::SourceBrush::Brush]’
11 | void setPattern() { m_brush = {setPattern_pattern}; }
|^
[Bug c/109233] [12/13 Regression] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 Uroš Bizjak changed: What|Removed |Added Attachment #54729|0 |1 is obsolete|| Attachment #54731|0 |1 is obsolete|| --- Comment #6 from Uroš Bizjak --- Created attachment 54733 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54733=edit Minimized testcase Minimized testcase for the testsuite.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 Jakub Jelinek changed: What|Removed |Added Attachment #54718|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- Created attachment 54732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54732=edit gcc13-pr109176.patch Now as full untested patch.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176
--- Comment #14 from Jakub Jelinek ---
So, e.g. in the gcc.target/i386/sse4_1-pr88547-1.c testcase, we have before
veclower21:
v2di f13 (v2di x, v2di y)
{
vector(2) _1;
v2di _4;
[local count: 1073741824]:
_1 = x_2(D) <= y_3(D);
_4 = VEC_COND_EXPR <_1, { -1, -1 }, { 0, 0 }>;
return _4;
}
And the problem is quite obvious. We do have vcond_mask_v2div2di optab,
so with the changed code expand_vector_condition just returns true.
But, expand_vector_comparison has:
/* As seen in PR95830, we should not expand comparisons that are only
feeding a VEC_COND_EXPR statement. */
auto_vec uses;
FOR_EACH_IMM_USE_FAST (use_p, iterator, lhs)
{
gimple *use = USE_STMT (use_p);
if (is_gimple_debug (use))
continue;
if (is_gimple_assign (use)
&& gimple_assign_rhs_code (use) == VEC_COND_EXPR
&& gimple_assign_rhs1 (use) == lhs
&& gimple_assign_rhs2 (use) != lhs
&& gimple_assign_rhs3 (use) != lhs)
uses.safe_push (use);
else
vec_cond_expr_only = false;
}
if (vec_cond_expr_only)
for (gimple *use : uses)
{
gimple_stmt_iterator it = gsi_for_stmt (use);
if (!expand_vector_condition (, dce_ssa_names))
{
vec_cond_expr_only = false;
break;
}
}
if (!uses.is_empty () && vec_cond_expr_only)
return NULL_TREE;
So, it effectively relies on expand_vector_condition doing its previous job
when the def stmt of a is a comparison, as nothing else checks it in that case,
and here x86 doesn't have V2DImode comparison instruction for this case.
Thus, I think we should instead of the tree-vect-generic.cc changes do:
--- gcc/tree-vect-generic.cc.jj 2023-03-21 13:28:21.354671095 +0100
+++ gcc/tree-vect-generic.cc2023-03-22 12:53:27.853986127 +0100
@@ -1063,6 +1063,15 @@ expand_vector_condition (gimple_stmt_ite
return true;
}
+ /* If a has vector boolean type and is a comparison, above
+ expand_vec_cond_expr_p might fail, even if both the comparison and
+ VEC_COND_EXPR could be supported individually. See PR109176. */
+ if (a_is_comparison
+ && VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (a))
+ && expand_vec_cond_expr_p (type, TREE_TYPE (a), SSA_NAME)
+ && expand_vec_cmp_expr_p (TREE_TYPE (a1), TREE_TYPE (a), code))
+return true;
+
/* Handle vector boolean types with bitmasks. If there is a comparison
and we can expand the comparison into the vector boolean bitmask,
or otherwise if it is compatible with type, we can transform
i.e. always look at the comparison and always try to handle it together, and if
that
fails, try to handle this special case by handling both stmts individually, and
only
if not do the piecewise etc. lowering.
At least, with the above patch, all FAILs I got in the x86_64-linux bootstrap
got fixed
(tested just those for now and nothing else).
[Bug ada/109212] Ada "for" expression generates gcc error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109212 --- Comment #4 from Eric Botcazou --- > Thanks for the quick check. Do I need to do anything on this bug report to > close it? No, it has already been closed.
[Bug middle-end/109246] New: Missed optimization for 2-dimensional array with equal values accessed through Enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109246
Bug ID: 109246
Summary: Missed optimization for 2-dimensional array with equal
values accessed through Enums
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andre.schackier at gmail dot com
Target Milestone: ---
Given the following code:
enum class E {
A = 0,
B = 1,
};
constexpr int t[2][2]{{1, 1}, {1, 1}};
int f1(E a) { return t[static_cast(a)][static_cast(a)]; }
int f2(E a, E b) { return t[static_cast(a)][static_cast(b)]; }
and compiling with '-O3 -fstrict-enums' gives:
- https://godbolt.org/z/s8jssnqq5
f1(E):
movsx rdi, edi
lea rax, [rdi+rdi*2]
mov eax, DWORD PTR t[0+rax*4]
ret
f2(E, E):
movsx rsi, esi
movsx rdi, edi
lea rax, [rsi+rdi*2]
mov eax, DWORD PTR t[0+rax*4]
ret
t:
.long 1
.long 1
.long 1
.long 1
gcc should be able to determine that in all cases both 'f1' and 'f2' can only
ever return 1.
The same is happening for
3x3 - https://godbolt.org/z/7v7hfq357
4x4 - https://godbolt.org/z/fTejK8YKb
5x5 - https://godbolt.org/z/31GcKPG6c
arrays.
Also explicitly telling the compiler about the valid values for 'a' and 'b'
using '__builtin_unreachable()' like this:
enum class E {
A = 0,
B = 1,
};
constexpr int t[2][2]{{1, 1}, {1, 1}};
int f1(E a) {
if (a != E::A && a != E::B) {
__builtin_unreachable();
}
return t[static_cast(a)][static_cast(a)];
}
int f2(E a, E b) {
if (a != E::A && a != E::B) {
__builtin_unreachable();
}
if (b != E::A && b != E::B) {
__builtin_unreachable();
}
return t[static_cast(a)][static_cast(b)];
}
does not help - https://godbolt.org/z/6x7xKo1xj
[Bug c/109233] [12/13 Regression] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 --- Comment #5 from Uroš Bizjak --- Created attachment 54731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54731=edit Even more minimized testcase.
[Bug c/109233] [12/13 Regression] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.3 Last reconfirmed||2023-03-22 Status|UNCONFIRMED |NEW Summary|warning: array subscript 5 |[12/13 Regression] warning: |is above array bounds of|array subscript 5 is above |‘struct tg3_napi[5]’ since |array bounds of ‘struct |r12-2591|tg3_napi[5]’ since r12-2591 Priority|P3 |P2
[Bug c/109233] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 Jakub Jelinek changed: What|Removed |Added Summary|warning: array subscript 5 |warning: array subscript 5 |is above array bounds of|is above array bounds of |‘struct tg3_napi[5]’|‘struct tg3_napi[5]’ since ||r12-2591 CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Both the original and minimized testcase started to warn with r12-2591-g2e96b5f14e4025691b57d2301d71a
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #23 from Costas Argyris --- Created attachment 54730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54730=edit Make symbol optional Could you please try this patch?
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #5 from avieira at gcc dot gnu.org --- Im slightly confused here, on entry to BB 5 we know the opposite of _1 < 0.0 no? if we branch to BB 5 we know !(_1 < 0.0) so we can't fold _1 <= 1.0, we just know that the range of _1 is >= 0.0 . Or am I misreading, I've not tried compiling myself just going off the code both of you posted here.
[Bug c/109233] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 --- Comment #3 from Uroš Bizjak --- Created attachment 54729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54729=edit Minimized testcase WIP, but *substantially* minimized. gcc -O2 -Warray-bounds: tg3-6.c: In function ‘tg3_init_one’: tg3-6.c:51:37: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds=] 51 | struct tg3_napi *tnapi = >napi[i]; | ^~~ tg3-6.c:22:19: note: while referencing ‘napi’ 22 | struct tg3_napi napi[(4 + 1)]; | ^~~~ tg3-6.c:51:37: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds=] 51 | struct tg3_napi *tnapi = >napi[i]; | ^~~ tg3-6.c:22:19: note: while referencing ‘napi’ 22 | struct tg3_napi napi[(4 + 1)]; | ^~~~
[Bug libgcc/109245] aarch64 gcc defaults to -moutline-atomics but symbol ‘__aarch64_swp4_sync’ is hidden in libgcc.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109245 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-03-22 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com, ||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #4 from Aldy Hernandez --- (In reply to Tamar Christina from comment #3) > Aldy, any thoughts here? We need a "real" threading expert on this one, as the decision by ranger is correct. It looks like this is a profitability issue in the threader. The problem can be seen with -O2 --param=threader-debug=all, on the threadfull1 dump: The threaded path is: path: 4->5->7 SUCCESS ranger can fold the conditional in BB5: if (_1 < 1.0e+0) goto ; [41.00%] else goto ; [59.00%] ...because on entry to BB5 we know _1 < 0.0: [local count: 955630225]: _1 = (float) l_9; _2 = _1 < 0.0; zone1_15 = (int) _2; if (_1 < 0.0) goto ; [41.00%] else goto ; [59.00%] [local count: 391808389]: [local count: 955630225]: # iftmp.0_10 = PHI fasten_main_natpro_chrg_init.2_3 = fasten_main_natpro_chrg_init; _4 = fasten_main_natpro_chrg_init.2_3 * iftmp.0_10; _5 = (float) _4; if (_1 < 1.0e+0) goto ; [41.00%] else goto ; [59.00%] If this shouldn't be threaded because of a hot/cold issue, perhaps the code goes in back_threader_profitability::profitable_path_p() where there's already logic wrt hot blocks.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 LIU Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #22 from LIU Hao --- This causes x86_64-w64-mingw32 to fail: ``` C:/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/13.0.1/../../../../x86_64-w64-mingw32/bin/ld.exe: required symbol `HOST_EXTRA_OBJS_SYMBOL' not defined collect2.exe: error: ld returned 1 exit status ```
[Bug debug/109237] csmith: another timeout with -g -O3 this time since r12-156-g8d4c374c4419a875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 --- Comment #10 from Richard Biener --- There's similar issues with GIMPLE uses of last_stmt () which generally (but not always) want to look at a possible control transfer stmt. It looks like we're not guaranteed to have no debug stmts after such, in particular CFG cleanup seems to be ready to remove debug stmts after a noreturn call. But GIMPLE verify_flow_info should already choke on that, so it might be only a temporary thing to accept?
[Bug libgcc/109245] aarch64 gcc defaults to -moutline-atomics but symbol ‘__aarch64_swp4_sync’ is hidden in libgcc.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109245 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That means one or more of your shared libraries has been linked incorrectly, e.g. by using ld -shared by hand instead of gcc -shared, or with -nostdlib or something similar.
[Bug libgcc/109245] New: aarch64 gcc defaults to -moutline-atomics but symbol ‘__aarch64_swp4_sync’ is hidden in libgcc.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109245 Bug ID: 109245 Summary: aarch64 gcc defaults to -moutline-atomics but symbol ‘__aarch64_swp4_sync’ is hidden in libgcc.a Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: songmz1999 at foxmail dot com Target Milestone: --- I found an issue when compiling the connection process using the toolchain aarch64_gcc12.2.0_glibc2.31.0_fp with the error message： ~/aarch64_gcc12.2.0_glibc2.31.0_fp/aarch64-unknown-linux-gnueabi/bin/.ld: ../../../deploy/oms/bin/omsservice: hidden symbol `__aarch64_swp4_sync' in ~/aarch64_gcc12.2.0_glibc2.31.0_fp/bin/../lib/gcc/aarch64-unknown-linux-gnueabi/12.2.0/libgcc.a(swp_4_5.o) is referenced by DSO ~/aarch64_gcc12.2.0_glibc2.31.0_fp/aarch64-unknown-linux-gnueabi/bin/.ld: final link failed: bad value The solution I've found so far is to enable the -mno-outline-atomics parameter at compile time. But why does gcc have -moutline-atomics enabled by default, but when calling the function '__aarch64_swp4_sync', it is hidden in libgcc.a? Is there a better solution？
[Bug tree-optimization/109240] Missed fneg/fsub optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109240 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-03-22 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 54728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54728=edit gcc13-pr109240.patch Actually, I think using manual operand_equal_p isn't that bad.
[Bug debug/109237] csmith: another timeout with -g -O3 this time since r12-156-g8d4c374c4419a875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 --- Comment #9 from Richard Biener --- Samples: 289K of event 'cycles:u', Event count (approx.): 384226334976 Overhead Samples Command Shared Object Symbol 3.52% 9747 cc1 cc1 [.] bb_is_just_return # 2.94% 8241 cc1 cc1 [.] df_note_compute # 2.92% 8085 cc1 cc1 [.] init_alias_analysis # 2.55% 7035 cc1 cc1 [.] delete_trivially_dead_insns # 2.28% 6372 cc1 cc1 [.] contains_no_active_insn_p # 2.16% 6288 cc1 cc1 [.] get_ref_base_and_extent # 2.02% 5785 cc1 cc1 [.] ggc_set_mark # 1.55% 4308 cc1 cc1 [.] fast_dce # I see that bb_is_just_return is high in the profile and looking at its implementation I wonder whether on RTL we can scan insns backwards and stop if the last (real?) insn isn't ANY_RETURN_P ()? Using FOR_BB_INSNS_REVERSE puts it off the profile completely. Will test a patch. Similar contains_no_active_insn_p is high up in the profile and it looks like micro-optimizing it a bit would help. Using NONDEBUG_INSN_P to guard the flow_active_insn_p call doesn't seem to help (but perf is always noisy).
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008 --- Comment #50 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:81295d445ec569c6413fd6f7921e27420167f8fa commit r13-6797-g81295d445ec569c6413fd6f7921e27420167f8fa Author: Aldy Hernandez Date: Wed Mar 8 10:58:01 2023 +0100 frange: Implement nan_state class [PR109008] This patch implements a nan_state class, that allows us to query or pass around the NANness of an frange. We can store +NAN, -NAN, +-NAN, or not-a-NAN with it. I tried to touch as little as possible, leaving other cleanups to the next release. For example, we should replace the m_*_nan fields in frange with nan_state, and provide relevant accessors to nan_state (isnan, etc). PR tree-optimization/109008 gcc/ChangeLog: * value-range.cc (frange::set): Add nan_state argument. * value-range.h (class nan_state): New. (frange::get_nan_state): New.
[Bug debug/109237] csmith: another timeout with -g -O3 this time since r12-156-g8d4c374c4419a875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 Martin Liška changed: What|Removed |Added Summary|csmith: another timeout |csmith: another timeout |with -g -O3 this time |with -g -O3 this time since ||r12-156-g8d4c374c4419a875 Keywords|needs-bisection | CC||marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- I think it started with r12-156-g8d4c374c4419a875.
[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 --- Comment #13 from Jakub Jelinek --- Unfortunately the patch breaks quite a lot of tests on x86_64: +FAIL: c-c++-common/goacc/firstprivate-mappings-1.c (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: gcc.target/i386/sse2-pr88547-1.c (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281) +FAIL: gcc.target/i386/sse2-pr88547-2.c (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281) +FAIL: gcc.target/i386/sse4_1-pr88547-1.c (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281) +FAIL: gcc.target/i386/sse4_1-pr88547-2.c (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281) +FAIL: gdc.dg/torture/simd_blendvector.d -O0 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281) +FAIL: gdc.dg/torture/simd_blendvector.d -O0 -g (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281) +FAIL: g++.dg/tree-ssa/pr88152-1.C (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281) +FAIL: c-c++-common/goacc/firstprivate-mappings-1.c -std=c++11 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: c-c++-common/goacc/firstprivate-mappings-1.c -std=c++14 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: c-c++-common/goacc/firstprivate-mappings-1.c -std=c++17 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: c-c++-common/goacc/firstprivate-mappings-1.c -std=c++20 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: c-c++-common/goacc/firstprivate-mappings-1.c -std=c++2b (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: c-c++-common/goacc/firstprivate-mappings-1.c -std=c++98 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: g++.dg/goacc/firstprivate-mappings-1.C -std=c++11 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: g++.dg/goacc/firstprivate-mappings-1.C -std=c++14 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: g++.dg/goacc/firstprivate-mappings-1.C -std=c++17 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: g++.dg/goacc/firstprivate-mappings-1.C -std=c++20 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: g++.dg/goacc/firstprivate-mappings-1.C -std=c++2b (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: g++.dg/goacc/firstprivate-mappings-1.C -std=c++98 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/firstprivate-mappings-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/firstprivate-mappings-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249) +FAIL: libgomp.oacc-c++/firstprivate-mappings-1.C -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:249)
[Bug debug/109237] csmith: another timeout with -g -O3 this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 --- Comment #7 from Richard Biener --- Created attachment 54727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54727=edit patch for delete_trivially_dead_insns The attached improves that to trivially dead code: 2.16 ( 3%) I've verified the set of debug insns kept is the same as before.
[Bug target/109244] internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244 --- Comment #3 from JuzheZhong --- (In reply to Mathieu Malaterre from comment #2) > Thanks for the quick update. I'll stop my test until this is merged. > > As a side note, I am also seeing this one in my log: > > internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471 > 133 | } > | ^ > 0xf6b49f rtl_ssa::function_info::finalize_new_accesses(rtl_ssa::insn_change&) > ../../src/gcc/rtl-ssa/changes.cc:471 > 0xf656cd > rtl_ssa::function_info::change_insns(array_slice) > ../../src/gcc/rtl-ssa/changes.cc:659 > 0xf6551f rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&) > ../../src/gcc/rtl-ssa/changes.cc:717 > 0x57eeb1 change_insn > ../../src/gcc/config/riscv/riscv-vsetvl.cc:1027 > 0x57eeb1 pass_vsetvl::cleanup_insns() const > ../../src/gcc/config/riscv/riscv-vsetvl.cc:3929 > 0x59070b pass_vsetvl::lazy_vsetvl() > ../../src/gcc/config/riscv/riscv-vsetvl.cc:4189 > 0x590891 pass_vsetvl::execute(function*) > ../../src/gcc/config/riscv/riscv-vsetvl.cc:4219 Is this ICE also comes from compiling the codes that you attach in this PR? If yes, I am pretty sure this issue has been fixed since I compile the attachment you gave with no fails now. Let's wait for kito to merge all the bug fix patches (there are about 5 bug fix patches pending in the GCC mail list) Thanks.
[Bug debug/109237] csmith: another timeout with -g -O3 this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237
--- Comment #6 from Richard Biener ---
For delete_trivially_dead_insns we have
for (insn = get_last_insn (); insn; insn = prev)
{
int live_insn = 0;
prev = PREV_INSN (insn);
if (!INSN_P (insn))
continue;
live_insn = insn_live_p (insn, counts);
/* If this is a dead insn, delete it and show registers in it aren't
being used. */
if (! live_insn && dbg_cnt (delete_trivial_dead))
{
if (DEBUG_INSN_P (insn))
...
but insn_live_p has "interesting" behavior for debug_insns:
else if (DEBUG_INSN_P (insn))
{
rtx_insn *next;
if (DEBUG_MARKER_INSN_P (insn))
return true;
for (next = NEXT_INSN (insn); next; next = NEXT_INSN (next))
if (NOTE_P (next))
continue;
else if (!DEBUG_INSN_P (next))
return true;
/* If we find an inspection point, such as a debug begin stmt,
we want to keep the earlier debug insn. */
else if (DEBUG_MARKER_INSN_P (next))
return true;
else if (INSN_VAR_LOCATION_DECL (insn) == INSN_VAR_LOCATION_DECL
(next))
return false;
return true;
that's ending up doing quadratic work that would have been better done
by keeping track of some state during the backwards walk of the insn
stream.
[Bug target/109244] internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244 --- Comment #2 from Mathieu Malaterre --- Thanks for the quick update. I'll stop my test until this is merged. As a side note, I am also seeing this one in my log: internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471 133 | } | ^ 0xf6b49f rtl_ssa::function_info::finalize_new_accesses(rtl_ssa::insn_change&) ../../src/gcc/rtl-ssa/changes.cc:471 0xf656cd rtl_ssa::function_info::change_insns(array_slice) ../../src/gcc/rtl-ssa/changes.cc:659 0xf6551f rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&) ../../src/gcc/rtl-ssa/changes.cc:717 0x57eeb1 change_insn ../../src/gcc/config/riscv/riscv-vsetvl.cc:1027 0x57eeb1 pass_vsetvl::cleanup_insns() const ../../src/gcc/config/riscv/riscv-vsetvl.cc:3929 0x59070b pass_vsetvl::lazy_vsetvl() ../../src/gcc/config/riscv/riscv-vsetvl.cc:4189 0x590891 pass_vsetvl::execute(function*) ../../src/gcc/config/riscv/riscv-vsetvl.cc:4219
[Bug tree-optimization/109240] Missed fneg/fsub optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109240 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- You can try if match.pd is "preprocessed enough" to make use of macros. vec_perm:c cannot be done, "selective" :c on a for iterator is also not possible. If you have an idea for a syntax to express the "iteration" please share it.
[Bug target/109244] internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244 --- Comment #1 from JuzheZhong --- Hi, thank you for reporting it. After several tries. I am pretty sure this issue has been fixed by this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614393.html I have several bug fix patches pending in the GCC mail list. Let's me ping @Kito to merge patches. Thank you so much.
[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109238 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- I will have a look.
[Bug debug/109237] csmith: another timeout with -g -O3 this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-03-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Confirmed. Maybe the only suspicious thing is trivially dead code: 10.65 ( 13%) and tree CFG cleanup : 5.06 ( 6%) cfg cleanup: 5.41 ( 7%) But yes, we're likely facing a lot of debug stmts, csmith tends to leave around tons of dead code.
[Bug c/80528] reimplement gnulib's "useless-if-before-free" script as a compiler warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80528 Eric Gallager changed: What|Removed |Added CC||rep.dot.nop at gmail dot com --- Comment #6 from Eric Gallager --- Recent patchset for fixing problems in GCC based on this same principle: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613116.html
[Bug c++/109244] New: internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244 Bug ID: 109244 Summary: internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: malat at debian dot org Target Milestone: --- Created attachment 54726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54726=edit Preprocessed source I cannot compile highway project on riscv64/Debian. It fails with: hwy/contrib/sort/vqsort-inl.h:1386:1: internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892 Compilation line: /usr/lib/gcc-snapshot/bin/g++ -freport-bug -DHWY_SHARED_DEFINE -Dhwy_contrib_EXPORTS -I/home/mathieu/debian/highway -g -O2 -ffile-prefix-map=/home/mathieu/debian/highway=. -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -march=rv64gcv1p0 -Werror -MD -MT CMakeFiles/hwy_contrib.dir/hwy/contrib/sort/vqsort_f32d.cc.o -MF CMakeFiles/hwy_contrib.dir/hwy/contrib/sort/vqsort_f32d.cc.o.d -o CMakeFiles/hwy_contrib.dir/hwy/contrib/sort/vqsort_f32d.cc.o -c /home/mathieu/debian/highway/hwy/contrib/sort/vqsort_f32d.cc
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #7 from Jakub Jelinek --- >> No luck reproducing this using a cross. > > Ok, so I'll continue with the reghunt. It's finished now and identified your patch commit 24c06560a7fa39049911eeb8777325d112e0deb9 Author: Jakub Jelinek Date: Fri Mar 17 18:59:56 2023 +0100 tree-inline: Fix up multiversioning with vector arguments [PR105554] as the culprit.
[Bug target/106543] [10/11/12 Regression] *sge_ uses operand 2 but there is no operand 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106543 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-03-22 Known to work||7.1.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|*sge_ |[10/11/12 Regression] |uses operand 2 but there is |*sge_ |no operand 2|uses operand 2 but there is ||no operand 2 Known to fail||8.1.0 Target Milestone|--- |10.5 --- Comment #1 from Andrew Pinski --- It broke with r8-4335-g0791ac186bdddf so it is a regression as riscv was added in GCC 7 and was correct then.
