[Bug middle-end/110673] [14 regression] ICE when buliding opus (internal compiler error: in gimple_phi_arg_def_from_edge, at gimple.h:4699)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673 --- Comment #2 from Sam James --- Created attachment 55548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55548=edit reduced.i
[Bug tree-optimization/110666] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110666 --- Comment #6 from Andrew Pinski --- (In reply to Zhendong Su from comment #5) > A couple of very likely related tests (especially #2 and #3): > > *** (1) wrong code at -O2, -O3, and -Os case 1 is a phiopt issue (PR 110252). > *** (2) wrong code at -O1 and above Case 2 is this issue. > > *** (3) wrong code at -O1 and above Case 3 is this issue too.
[Bug tree-optimization/110666] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110666
--- Comment #5 from Zhendong Su ---
A couple of very likely related tests (especially #2 and #3):
*** (1) wrong code at -O2, -O3, and -Os
[539] % gcctk -O1 small.c; ./a.out
[540] % gcctk -O2 small.c
[541] % timeout -s 9 5 ./a.out
Killed
[542] % cat small.c
int a, b = -1, c, d = -1;
int main() {
if (a)
goto L2;
L1:
a = 0;
L2:
b && c;
c = ~c * (d ^ (0 || a) || d & b);
if (c)
goto L1;
return 0;
}
*** (2) wrong code at -O1 and above
[558] % gcctk -O0 small.c; ./a.out
[559] % gcctk -O1 small.c
[560] % ./a.out
Floating point exception
[561] % cat small.c
int a = 1, b, c;
void f(int d) {
for (; c < 2; c++) {
if (!a)
b = -1;
a = (d != 4) == d;
b = 1 % ~b;
}
}
int main() { f(1 || b); }
*** (3) wrong code at -O1 and above
[577] % gcctk -O0 small.c; ./a.out
[578] % gcctk -O1 small.c
[579] % timeout -s 9 5 ./a.out
Killed
[580] % cat small.c
int a = 1, b, c, d;
void e(int f) {
for (; c < 2; c++) {
if (b)
d = c;
c = d;
b = f;
}
}
int main() { e(((a != 2) != a) != 1); }
[Bug middle-end/110673] [14 regression] ICE when buliding opus (internal compiler error: in gimple_phi_arg_def_from_edge, at gimple.h:4699)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673 --- Comment #1 from Sam James --- Created attachment 55547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55547=edit test_unit_entropy.c.i This is what cvise popped out, it's borderline invalid though, so let me touch it up.
[Bug middle-end/110673] New: [14 regression] ICE when buliding opus (internal compiler error: in gimple_phi_arg_def_from_edge, at gimple.h:4699)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673
Bug ID: 110673
Summary: [14 regression] ICE when buliding opus (internal
compiler error: in gimple_phi_arg_def_from_edge, at
gimple.h:4699)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Created attachment 55546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55546=edit
test_unit_entropy.c.i
Hit with opus-1.4.
```
# aarch64-unknown-linux-gnu-gcc -Icelt/tests/test_unit_entropy.p -Icelt/tests
-I../opus-1.4/celt/tests -I. -I../opus-1.4 -Iinclude -I../opus-1.4/include
-Icelt -I../opus-1.4/celt -Isilk -I../opus-1.4/silk -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu99 -DOPUS_BUILD
-DHAVE_CONFIG_H -fvisibility=hidden -Wcast-align -Wnested-externs -Wshadow
-Wstrict-prototypes -fstack-protector-strong -O3 -pipe -mcpu=native
-fdiagnostics-color=always -ggdb3 -MD -MQ
celt/tests/test_unit_entropy.p/test_unit_entropy.c.o -MF
celt/tests/test_unit_entropy.p/test_unit_entropy.c.o.d -o
celt/tests/test_unit_entropy.p/test_unit_entropy.c.o -c
../opus-1.4/celt/tests/test_unit_entropy.c -save-temps
aarch64-unknown-linux-gnu-gcc: warning: ‘-pipe’ ignored because ‘-save-temps’
specified
during GIMPLE pass: sccp
../opus-1.4/celt/tests/test_unit_entropy.c: In function ‘main’:
../opus-1.4/celt/tests/test_unit_entropy.c:53:5: internal compiler error: in
gimple_phi_arg_def_from_edge, at gimple.h:4699
53 | int main(int _argc,char **_argv){
| ^~~~
0xd781675b gimple_phi_arg_def_from_edge(gphi const*, edge_def const*)
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimple.h:4699
0xd8160f8b gimple_phi_arg_def_from_edge(gphi const*, edge_def const*)
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/gimple-iterator.h:133
0xd8160f8b final_value_replacement_loop(loop*)
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-scalar-evolution.cc:3732
0xd822566b execute
/usr/src/debug/sys-devel/gcc-14.0.0./gcc-14.0.0./gcc/tree-ssa-loop.cc:411
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/110204] [14 Regression] Suspicous warning when compiling ranges-v3 using GCC trunk (iteration 9223372036854775807 invokes undefined behavior)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110204 Andrew Pinski changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- Replaced _40 - _41 with pretmp_163 in all uses of _42 = _40 - _41; Replaced _42 /[ex] 4 with pretmp_162 in all uses of _43 = _42 /[ex] 4; Replaced (long unsigned int) _43 with pretmp_161 in all uses of _44 = (long unsigned int) _43; Removing unexecutable edge from if (_42 != 0) Removing dead stmt _44 = (long unsigned int) _43; Removing dead stmt _43 = _42 /[ex] 4; Removing dead stmt _42 = _40 - _41; Removing dead stmt _41 = MEM[(const struct vector *)_3(D)].D.214899._M_impl.D.214244._M_start; Removing dead stmt _40 = MEM[(const struct vector *)_3(D)].D.214899._M_impl.D.214244._M_finish; What is interesting is before PRE we had: ``` [local count: 19488414]: if (_42 != 0) goto ; [59.00%] else goto ; [41.00%] [local count: 11498164]: __n_154 = _43 + -1; if (_42 != 0) goto ; [89.00%] else goto ; [11.00%] ``` After we got: ``` [local count: 19488414]: if (pretmp_163 != 0) goto ; [59.00%] else goto ; [41.00%] [local count: 7990250]: goto ; [100.00%] [local count: 11498164]: __n_154 = pretmp_162 + -1; ``` That is only the second condition based on _42 was removed and not the first ...
[Bug tree-optimization/110204] [14 Regression] Suspicous warning when compiling ranges-v3 using GCC trunk (iteration 9223372036854775807 invokes undefined behavior)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110204 --- Comment #3 from Andrew Pinski --- PRE leaves around: [local count: 118111600]: ... pretmp_163 = 0; [local count: 19488414]: if (pretmp_163 != 0) goto ; [59.00%] else goto ; [41.00%]
[Bug tree-optimization/110204] [14 Regression] Suspicous warning when compiling ranges-v3 using GCC trunk (iteration 9223372036854775807 invokes undefined behavior)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110204 --- Comment #2 from Andrew Pinski --- The preprocessed source that is produced by GCC 13 is warning free.
[Bug tree-optimization/110252] [14 Regression] Wrong code at -O2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252 --- Comment #16 from Andrew Pinski --- Updated patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624563.html (depends on: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624562.html )
[Bug tree-optimization/110672] vec.h:1023:9: error: 'new_temp' may be used uninitialized [-Werror=maybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110672 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 110652 ***
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 Andrew Pinski changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- *** Bug 110672 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/110672] New: vec.h:1023:9: error: 'new_temp' may be used uninitialized [-Werror=maybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110672 Bug ID: 110672 Summary: vec.h:1023:9: error: 'new_temp' may be used uninitialized [-Werror=maybe-uninitialized] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 In stage2, /home/dave/gnu/gcc/objdir64/./prev-gcc/xg++ -B/home/dave/gnu/gcc/objdir64/./prev-gcc/ -B/opt/gnu64/gcc/gcc-14/hppa64-hp-hpux11.11/bin/ -nostdinc++ -B/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -B/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -I/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir64/prev-hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -fno-PIE -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I/opt/gnu64/gcc/gmp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -I/opt/gnu64/gcc/gmp/include -o tree-vect-slp.o -MT tree-vect-slp.o -MMD -MP -MF ./.deps/tree-vect-slp.TPo ../../gcc/gcc/tree-vect-slp.cc In file included from ../../gcc/gcc/hash-table.h:248, from ../../gcc/gcc/coretypes.h:486, from ../../gcc/gcc/tree-vect-stmts.cc:24: In member function 'T* vec::quick_push(const T&) [with T = tree_node*; A = va_heap]', inlined from 'T* vec::quick_push(const T&) [with T = tree_node*]' at ../../gcc/gcc/vec.h:1987:28, inlined from 'bool vectorizable_load(vec_info*, stmt_vec_info, gimple_stmt_iterator*, gimple**, slp_tree, stmt_vector_for_cost*)' at ../../gcc/gcc/tree-vect-stmts.cc:10962:23: ../../gcc/gcc/vec.h:1023:9: error: 'new_temp' may be used uninitialized [-Werror=maybe-uninitialized] 1023 | *slot = obj; | ~~^ ../../gcc/gcc/tree-vect-stmts.cc: In function 'bool vectorizable_load(vec_info*, stmt_vec_info, gimple_stmt_iterator*, gimple**, slp_tree, stmt_vector_for_cost*)': ../../gcc/gcc/tree-vect-stmts.cc:9300:8: note: 'new_temp' was declared here 9300 | tree new_temp; |^~~~ cc1plus: all warnings being treated as errors Initializing new_temp to NULL_TREE fixes warning.
[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110206 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|14.0|12.4 Status|ASSIGNED|RESOLVED --- Comment #20 from Uroš Bizjak --- Fixed for gcc-12.4+.
[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110206
--- Comment #19 from CVS Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:eeb8e9a36d7aa9bc4ac8b0d7abe1e84e9afc4250
commit r12-9774-geeb8e9a36d7aa9bc4ac8b0d7abe1e84e9afc4250
Author: Uros Bizjak
Date: Fri Jul 14 11:46:22 2023 +0200
cprop: Do not set REG_EQUAL note when simplifying paradoxical subreg
[PR110206]
cprop1 pass does not consider paradoxical subreg and for (insn 22) claims
that it equals 8 elements of HImodeby setting REG_EQUAL note:
(insn 21 19 22 4 (set (reg:V4QI 98)
(mem/u/c:V4QI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0 S4 A32]))
"pr110206.c":12:42 1530 {*movv4qi_internal}
(expr_list:REG_EQUAL (const_vector:V4QI [
(const_int -52 [0xffcc]) repeated x4
])
(nil)))
(insn 22 21 23 4 (set (reg:V8HI 100)
(zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V4QI 98) 0)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
] "pr110206.c":12:42 7471
{sse4_1_zero_extendv8qiv8hi2}
(expr_list:REG_EQUAL (const_vector:V8HI [
(const_int 204 [0xcc]) repeated x8
])
(expr_list:REG_DEAD (reg:V4QI 98)
(nil
We rely on the "undefined" vals to have a specific value (from the earlier
REG_EQUAL note) but actual code generation doesn't ensure this (it doesn't
need to). That said, the issue isn't the constant folding per-se but that
we do not actually constant fold but register an equality that doesn't
hold.
PR target/110206
gcc/ChangeLog:
* fwprop.cc (contains_paradoxical_subreg_p): Move to ...
* rtlanal.cc (contains_paradoxical_subreg_p): ... here.
* rtlanal.h (contains_paradoxical_subreg_p): Add prototype.
* cprop.cc (try_replace_reg): Do not set REG_EQUAL note
when the original source contains a paradoxical subreg.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110206.c: New test.
(cherry picked from commit 1815e313a8fb519a77c94a908eb6dafc4ce51ffe)
[Bug c++/110344] [C++26] P2738R1 - constexpr cast from void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8d344146727da02eb5c62fbf6cee97a4e96d63db commit r14-2535-g8d344146727da02eb5c62fbf6cee97a4e96d63db Author: Jason Merrill Date: Fri Jul 14 09:37:21 2023 -0400 c++: c++26 regression fixes Apparently I wasn't actually running the testsuite in C++26 mode like I thought I was, so there were some failures I wasn't seeing. The constexpr hunk fixes regressions with the P2738 implementation; we still need to use the old handling for casting from void pointers to heap variables. PR c++/110344 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_expression): Move P2738 handling after heap handling. * name-lookup.cc (get_cxx_dialect_name): Add C++26. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-cast2.C: Adjust for P2738. * g++.dg/ipa/devirt-45.C: Handle -fimplicit-constexpr.
[Bug middle-end/87944] Wrong code with LRA pushing stack local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87944
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Andrew Pinski ---
(In reply to Mikael Pettersson from comment #5)
> Appears to have been fixed for gcc-14.0 by
>
> 30038a207c10a2783fa2695b62c7c8458ef05e73 is the first new commit
> commit 30038a207c10a2783fa2695b62c7c8458ef05e73
> Author: Vladimir N. Makarov
> Date: Tue May 30 15:54:28 2023 -0400
>
> LRA: Update insn sp offset if its input reload changes SP
>
> which mentions a problem switching the h8300 to lra, but there's no PR
> reference in either the commit message or the mailing-list post.
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620128.html
This is definitely the fix here.
In this case we had:
(insn 12 10 13 2 (set (mem/f:HI (pre_dec:HI (reg/f:HI 6 sp)) [1 S2 A16])
(reg/f:HI 24)) "../../testarg.c":9:12 25 {movhi}
(expr_list:REG_DEAD (reg/f:HI 24)
(expr_list:REG_ARGS_SIZE (const_int 2 [0x2])
(nil
Which then would turn into incorrectly what is described in both the bug report
here and in fact the same as what is described in the email.
[Bug tree-optimization/110666] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110666 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-July/62 ||4551.html --- Comment #4 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624551.html
[Bug ipa/93385] [11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 Andrew Pinski changed: What|Removed |Added CC||19373742 at buaa dot edu.cn --- Comment #51 from Andrew Pinski --- *** Bug 110662 has been marked as a duplicate of this bug. ***
[Bug ipa/110662] [11 Regression] Segmentation fault with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110662 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 93385. *** This bug has been marked as a duplicate of bug 93385 ***
[Bug ipa/110662] [11 Regression] Segmentation fault with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110662 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 Summary|Segmentation fault with |[11 Regression] |'-O3' |Segmentation fault with ||'-O3'
[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110206
--- Comment #18 from CVS Commits ---
The releases/gcc-13 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:bef95ba085b0ae9bf3eb79a8eed685236d773116
commit r13-7565-gbef95ba085b0ae9bf3eb79a8eed685236d773116
Author: Uros Bizjak
Date: Fri Jul 14 11:46:22 2023 +0200
cprop: Do not set REG_EQUAL note when simplifying paradoxical subreg
[PR110206]
cprop1 pass does not consider paradoxical subreg and for (insn 22) claims
that it equals 8 elements of HImodeby setting REG_EQUAL note:
(insn 21 19 22 4 (set (reg:V4QI 98)
(mem/u/c:V4QI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0 S4 A32]))
"pr110206.c":12:42 1530 {*movv4qi_internal}
(expr_list:REG_EQUAL (const_vector:V4QI [
(const_int -52 [0xffcc]) repeated x4
])
(nil)))
(insn 22 21 23 4 (set (reg:V8HI 100)
(zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V4QI 98) 0)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
] "pr110206.c":12:42 7471
{sse4_1_zero_extendv8qiv8hi2}
(expr_list:REG_EQUAL (const_vector:V8HI [
(const_int 204 [0xcc]) repeated x8
])
(expr_list:REG_DEAD (reg:V4QI 98)
(nil
We rely on the "undefined" vals to have a specific value (from the earlier
REG_EQUAL note) but actual code generation doesn't ensure this (it doesn't
need to). That said, the issue isn't the constant folding per-se but that
we do not actually constant fold but register an equality that doesn't
hold.
PR target/110206
gcc/ChangeLog:
* fwprop.cc (contains_paradoxical_subreg_p): Move to ...
* rtlanal.cc (contains_paradoxical_subreg_p): ... here.
* rtlanal.h (contains_paradoxical_subreg_p): Add prototype.
* cprop.cc (try_replace_reg): Do not set REG_EQUAL note
when the original source contains a paradoxical subreg.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110206.c: New test.
(cherry picked from commit 1815e313a8fb519a77c94a908eb6dafc4ce51ffe)
[Bug target/59172] pdp11-aout makes a wrong code at the epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59172 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #3 from Mikael Pettersson --- For completeness, this was fixed for gcc-9.1.0 by commit 442fcea74d0c7797fc083fa7e5543268c0ff54a6 Author: Paul Koning Date: Thu Nov 8 13:56:58 2018 -0500 The commit message mentions PR c/87795 but that seems like an error; the mailing-list message just mentions it being a collection of fixes.
[Bug libstdc++/108556] std::sort changes objects' member values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108556 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski --- dup *** This bug has been marked as a duplicate of bug 553 ***
[Bug libstdc++/553] Call to sort () results in segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=553 Andrew Pinski changed: What|Removed |Added CC||gnu.iodaj at simplelogin dot com --- Comment #9 from Andrew Pinski --- *** Bug 108556 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/110671] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in gimple_phi_arg_def_from_edge, at gimple.h:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110671
Bug ID: 110671
Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu:
in gimple_phi_arg_def_from_edge, at gimple.h:4699
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a very recent regression.
[631] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230714 (experimental) (GCC)
[632] %
[632] % gcctk -O2 -c small.c
during GIMPLE pass: sccp
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in gimple_phi_arg_def_from_edge, at
gimple.h:4699
3 | int main() {
| ^~~~
0x80ec9d gimple_phi_arg_def_from_edge(gphi const*, edge_def const*)
../../gcc-trunk/gcc/gimple.h:4699
0x8101ae gimple_phi_arg_def_from_edge(gphi const*, edge_def const*)
../../gcc-trunk/gcc/tree.h:3700
0x8101ae final_value_replacement_loop(loop*)
../../gcc-trunk/gcc/tree-scalar-evolution.cc:3732
0x118a1a5 execute
../../gcc-trunk/gcc/tree-ssa-loop.cc:411
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.
[633] %
[633] % cat small.c
extern void f();
int a;
int main() {
int *b = , c = 1, d;
L:
if (a)
for (; d < 1; d++) {
if (a)
f();
*b |= c;
}
c = 0;
if (a)
goto L;
return 0;
}
[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.5.0, 11.4.0, 12.3.0, ||13.1.0 Known to work||14.0 --- Comment #7 from anlauf at gcc dot gnu.org --- Updating known-to-work/known to fail version. Paul/Steve: do you want to assign this PR to one of you?
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 Jose E. Marchesi changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jose E. Marchesi --- Thanks for confirming. Resolving as fixed.
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 --- Comment #7 from Kris Van Hees --- Confirmed that it resolves the issue Thanks!
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from anlauf at gcc dot gnu.org --- Fixed for gcc-14, and backported to affected branches. Closing. Thanks for the report!
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a348245bfb018f02b36d22575380b34aef58f52c commit r11-10910-ga348245bfb018f02b36d22575380b34aef58f52c Author: Harald Anlauf Date: Tue Jul 11 21:21:25 2023 +0200 Fortran: formal symbol attributes for intrinsic procedures [PR110288] gcc/fortran/ChangeLog: PR fortran/110288 * symbol.c (gfc_copy_formal_args_intr): When deriving the formal argument attributes from the actual ones for intrinsic procedure calls, take special care of CHARACTER arguments that we do not wrongly treat them formally as deferred-length. gcc/testsuite/ChangeLog: PR fortran/110288 * gfortran.dg/findloc_10.f90: New test. (cherry picked from commit 3b2c523ae31b68fc3b8363b458a55eec53a44365)
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:995c717500c368c5aec7889dfa047cff7cb0139b commit r12-9773-g995c717500c368c5aec7889dfa047cff7cb0139b Author: Harald Anlauf Date: Tue Jul 11 21:21:25 2023 +0200 Fortran: formal symbol attributes for intrinsic procedures [PR110288] gcc/fortran/ChangeLog: PR fortran/110288 * symbol.cc (gfc_copy_formal_args_intr): When deriving the formal argument attributes from the actual ones for intrinsic procedure calls, take special care of CHARACTER arguments that we do not wrongly treat them formally as deferred-length. gcc/testsuite/ChangeLog: PR fortran/110288 * gfortran.dg/findloc_10.f90: New test. (cherry picked from commit 3b2c523ae31b68fc3b8363b458a55eec53a44365)
[Bug c/110654] inconsistent error message in presence of unexpected encoded characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110654 --- Comment #2 from Ulrich Drepper --- (In reply to Andrew Pinski from comment #1) > So this is due to differences in the languages themselves rather than due to > C vs C++ front-end ... This is certainly true for the validation. But the standard never says anything about how an error should be reported. I don't think there is a reason to make this more obscure than necessary.
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 --- Comment #8 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:447dd2924e43884d798d8c40765cbfddd0fde0ae commit r13-7564-g447dd2924e43884d798d8c40765cbfddd0fde0ae Author: Harald Anlauf Date: Tue Jul 11 21:21:25 2023 +0200 Fortran: formal symbol attributes for intrinsic procedures [PR110288] gcc/fortran/ChangeLog: PR fortran/110288 * symbol.cc (gfc_copy_formal_args_intr): When deriving the formal argument attributes from the actual ones for intrinsic procedure calls, take special care of CHARACTER arguments that we do not wrongly treat them formally as deferred-length. gcc/testsuite/ChangeLog: PR fortran/110288 * gfortran.dg/findloc_10.f90: New test. (cherry picked from commit 3b2c523ae31b68fc3b8363b458a55eec53a44365)
[Bug ada/110668] gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668 Dennis Clarke changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Dennis Clarke --- Lets call this invalid !
[Bug other/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669
--- Comment #2 from David Binderman ---
Reduced C code seems to be:
int g_29, func_47_p_48, func_47_p_51_l_129;
void func_47_p_51() {
for (;;) {
func_47_p_51_l_129 = 0;
for (; func_47_p_51_l_129 <= 1; func_47_p_51_l_129 += 1) {
short *l_160 = func_47_p_48 || *l_160;
*l_160 &= g_29;
}
}
}
$ ~/gcc/results/bin/gcc -c -Ofast bug942.c
bug942.c: In function ‘func_47_p_51’:
bug942.c:6:22: warning: initialization of ‘short int *’ from ‘int’ makes
pointer from integer without a cast [-Wint-conversion]
6 | short *l_160 = func_47_p_48 || *l_160;
| ^~~~
during GIMPLE pass: sccp
bug942.c:2:6: internal compiler error: in gimple_phi_arg_def_from_edge, at
gimple.h:4699
2 | void func_47_p_51() {
| ^~~~
0xf4f20f final_value_replacement_loop(loop*)
../../trunk.year/gcc/tree-scalar-evolution.cc:0
[Bug target/110647] [14 Regression] 66% TSVC/s2712 regressoin on N1-neoverse between g:620a35b24a2b6edb (2023-07-01 07:24) and g:80ae426a195a0d03 (2023-07-02 01:37)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110647
--- Comment #2 from Jan Hubicka ---
This is a testcase based on our testuiste version so it can be copied to
compiler explorer
#define iterations 1
#define LEN_1D 32000
#define LEN_2D 256
#define ARRAY_ALIGNMENT 64
typedef float real_t;
#define ABS fabsf
__attribute__((aligned(ARRAY_ALIGNMENT)))
real_t flat_2d_array[LEN_2D * LEN_2D];
__attribute__((aligned(ARRAY_ALIGNMENT))) real_t x[LEN_1D];
__attribute__((aligned(ARRAY_ALIGNMENT))) real_t a[LEN_1D], b[LEN_1D],
c[LEN_1D], d[LEN_1D], e[LEN_1D], aa[LEN_2D][LEN_2D], bb[LEN_2D][LEN_2D],
cc[LEN_2D][LEN_2D], tt[LEN_2D][LEN_2D];
__attribute__((aligned(ARRAY_ALIGNMENT))) int indx[LEN_1D];
int dummy(real_t[LEN_1D], real_t[LEN_1D], real_t[LEN_1D], real_t[LEN_1D],
real_t[LEN_1D], real_t[LEN_2D][LEN_2D], real_t[LEN_2D][LEN_2D],
real_t[LEN_2D][LEN_2D], real_t);
real_t s2712(struct args_t * func_args)
{
//control flow
//if to elemental min
for (int nl = 0; nl < 4*iterations; nl++) {
for (int i = 0; i < LEN_1D; i++) {
if (a[i] >= b[i]) {
a[i] += b[i] * c[i];
}
}
dummy(a, b, c, d, e, aa, bb, cc, 0.);
}
return 0;
}
So with GCC 13 I get:
s2712(args_t*):
stp x29, x30, [sp, -96]!
mov x29, sp
stp x19, x20, [sp, 16]
adrpx19, a
adrpx20, b
add x19, x19, :lo12:a
add x20, x20, :lo12:b
stp x21, x22, [sp, 32]
adrpx22, c
mov x21, 62464
add x22, x22, :lo12:c
stp x23, x24, [sp, 48]
adrpx24, e
adrpx23, d
add x24, x24, :lo12:e
add x23, x23, :lo12:d
stp x25, x26, [sp, 64]
adrpx26, bb
adrpx25, aa
add x26, x26, :lo12:bb
add x25, x25, :lo12:aa
stp x27, x28, [sp, 80]
adrpx27, cc
add x27, x27, :lo12:cc
mov w28, 4
movkx21, 0x1, lsl 16
.L2:
mov x0, 0
.L5:
ldr s0, [x19, x0]
ldr s1, [x20, x0]
fcmpe s0, s1
bge .L7
.L3:
add x0, x0, 4
cmp x0, x21
bne .L5
moviv0.2s, #0
mov x7, x27
mov x6, x26
mov x5, x25
mov x4, x24
mov x3, x23
mov x2, x22
mov x1, x20
mov x0, x19
bl dummy(float*, float*, float*, float*, float*, float (*) [256],
float (*) [256], float (*) [256], float)
subsw28, w28, #1
bne .L2
ldp x19, x20, [sp, 16]
moviv0.2s, #0
ldp x21, x22, [sp, 32]
ldp x23, x24, [sp, 48]
ldp x25, x26, [sp, 64]
ldp x27, x28, [sp, 80]
ldp x29, x30, [sp], 96
ret
.L7:
ldr s2, [x22, x0]
fmadd s0, s1, s2, s0
str s0, [x19, x0]
b .L3
and trunk:
s2712(args_t*):
stp x29, x30, [sp, -96]!
mov x29, sp
stp x19, x20, [sp, 16]
adrpx19, a
adrpx20, b
add x19, x19, :lo12:a
add x20, x20, :lo12:b
stp x21, x22, [sp, 32]
adrpx22, c
mov x21, 62464
add x22, x22, :lo12:c
stp x23, x24, [sp, 48]
adrpx24, e
adrpx23, d
add x24, x24, :lo12:e
add x23, x23, :lo12:d
stp x25, x26, [sp, 64]
adrpx26, bb
adrpx25, aa
add x26, x26, :lo12:bb
add x25, x25, :lo12:aa
stp x27, x28, [sp, 80]
adrpx27, cc
add x27, x27, :lo12:cc
mov w28, 4
movkx21, 0x1, lsl 16
.L2:
mov x0, 0
.L5:
ldr s31, [x19, x0]
ldr s30, [x20, x0]
fcmpe s31, s30
bge .L7
.L3:
add x0, x0, 4
cmp x0, x21
bne .L5
moviv0.2s, #0
mov x7, x27
mov x6, x26
mov x5, x25
mov x4, x24
mov x3, x23
mov x2, x22
mov x1, x20
mov x0, x19
bl dummy(float*, float*, float*, float*, float*, float (*) [256],
float (*) [256], float (*) [256], float)
subsw28, w28, #1
bne .L2
ldp x19, x20, [sp, 16]
moviv0.2s, #0
ldp x21, x22, [sp, 32]
ldp x23, x24, [sp, 48]
ldp x25, x26, [sp, 64]
ldp x27, x28, [sp, 80]
ldp x29, x30, [sp], 96
ret
.L7:
ldr s29, [x22, x0]
fmadd s31, s30, s29, s31
str s31, [x19, x0]
b .L3
The only difference seems to be:
.L2:
mov x0, 0
.L5:
-ldr s31, [x19, x0]
-ldr s30, [x20, x0]
-fcmpe s31, s30
+ldr s0, [x19, x0]
+
[Bug ada/110668] gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668 --- Comment #3 from Mikael Pettersson --- https://gcc.gnu.org/install/prerequisites.html, GNAT section, 4th paragraph.
[Bug other/110669] [24 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #1 from David Binderman --- I also see this. Reduction running now.
[Bug other/110669] New: [24 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 Bug ID: 110669 Summary: [24 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:b77161e60bce7b4416319defe5f141f14fd375c4, r14-2515-gb77161e60bce7b make -k check-gcc RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr105132.c" FAIL: gcc.dg/torture/pr105132.c -O1 (internal compiler error: in gimple_phi_arg_def_from_edge, at gimple.h:4699) FAIL: gcc.dg/torture/pr105132.c -O1 (test for excess errors) # of expected passes7 # of unexpected failures2 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr105132.c -fdiagnostics-plain-output -O1 -S -o pr105132.s during GIMPLE pass: sccp /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr105132.c: In function 'd': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr105132.c:7:6: internal compiler error: in gimple_phi_arg_def_from_edge, at gimple.h:4699 0x10e0f357 gimple_phi_arg_def_from_edge(gphi const*, edge_def const*) /home/seurer/gcc/git/gcc-test/gcc/gimple.h:4699 0x10e0f357 gimple_phi_arg_def_from_edge(gphi const*, edge_def const*) /home/seurer/gcc/git/gcc-test/gcc/gimple.h:4697 0x10e0f357 final_value_replacement_loop(loop*) /home/seurer/gcc/git/gcc-test/gcc/tree-scalar-evolution.cc:3732 0x10f0e01f execute /home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop.cc:411 commit b77161e60bce7b4416319defe5f141f14fd375c4 (HEAD) Author: Richard Biener Date: Fri Jul 14 10:01:39 2023 +0200 Provide extra checking for phi argument access from edge
[Bug c/110670] New: tree-vect-stmts.cc:9733:11: warning: variable 'offvar' is sometimes initialised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110670 Bug ID: 110670 Summary: tree-vect-stmts.cc:9733:11: warning: variable 'offvar' is sometimes initialised Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- >From today's build of gcc trunk, clang says: tree-vect-stmts.cc:9733:11: warning: variable 'offvar' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] $ grep -n offvar ../trunk.year/gcc/tree-vect-stmts.cc 8377: tree offvar; 8495:, NULL); 8504: running_off = offvar; 9692: tree offvar; 9767:, NULL); 9772: running_off = offvar; $ It might be worthwhile initialising offvar to something sensible for both its declarations.
[Bug target/110588] btl (on x86_64) not always generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110588 --- Comment #3 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:43a0a5cd57eefd5a5bbead606ec4f6959af31802 commit r14-2528-g43a0a5cd57eefd5a5bbead606ec4f6959af31802 Author: Roger Sayle Date: Fri Jul 14 18:21:56 2023 +0100 PR target/110588: Add *bt_setncqi_2 to generate btl on x86. This patch resolves PR target/110588 to catch another case in combine where the i386 backend should be generating a btl instruction. This adds another define_insn_and_split to recognize the RTL representation for this case. I also noticed that two related define_insn_and_split weren't using the preferred string style for single statement preparation-statements, so I've reformatted these to be consistent in style with the new one. 2023-07-14 Roger Sayle gcc/ChangeLog PR target/110588 * config/i386/i386.md (*bt_setcqi): Prefer string form preparation statement over braces for a single statement. (*bt_setncqi): Likewise. (*bt_setncqi_2): New define_insn_and_split. gcc/testsuite/ChangeLog PR target/110588 * gcc.target/i386/pr110588.c: New test case.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Attachment #55542|0 |1 is obsolete|| --- Comment #81 from Jakub Jelinek --- Created attachment 55545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55545=edit gcc14-bitint-wip.patch _BitInt -> double conversion (float, long double, __float128, _Float16 and __bf16 conversions still to be implemented).
[Bug c++/109876] [11/12/13 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Marek Polacek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |initializer_list not usable |initializer_list not usable |in constant expressions in |in constant expressions in |a template |a template --- Comment #14 from Marek Polacek --- Fixed on trunk so far. I want to wait a bit before backporting this.
[Bug ada/110668] gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668 --- Comment #2 from Dennis Clarke --- Oh darn. Is this documented anywhere in the build instructions?
[Bug c++/109876] [11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #13 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:b5138df96a93d3b5070c88b8617eabd38cb24ab6
commit r14-2527-gb5138df96a93d3b5070c88b8617eabd38cb24ab6
Author: Marek Polacek
Date: Thu May 25 18:54:18 2023 -0400
c++: wrong error with static constexpr var in tmpl [PR109876]
Since r8-509, we'll no longer create a static temporary var for
the initializer '{ 1, 2 }' for num in the attached test because
the code in finish_compound_literal is now guarded by
'&& fcl_context == fcl_c99' but it's fcl_functional here. This
causes us to reject num as non-constant when evaluating it in
a template.
Jason's idea was to treat num as value-dependent even though it
actually isn't. This patch implements that suggestion.
We weren't marking objects whose type is an empty class type
constant. This patch changes that so that v_d_e_p doesn't need
to check is_really_empty_class.
Co-authored-by: Jason Merrill
PR c++/109876
gcc/cp/ChangeLog:
* decl.cc (cp_finish_decl): Set TREE_CONSTANT when initializing
an object of empty class type.
* pt.cc (value_dependent_expression_p) : Treat a
constexpr-declared non-constant variable as value-dependent.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-template12.C: New test.
* g++.dg/cpp1z/constexpr-template1.C: New test.
* g++.dg/cpp1z/constexpr-template2.C: New test.
[Bug middle-end/88873] missing vectorization for decomposed operations on a vector type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873
--- Comment #8 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:8911879415d6c2a7baad88235554a912887a1c5c
commit r14-2526-g8911879415d6c2a7baad88235554a912887a1c5c
Author: Roger Sayle
Date: Fri Jul 14 18:10:05 2023 +0100
i386: Improved insv of DImode/DFmode {high,low}parts into TImode.
This is the next piece towards a fix for (the x86_64 ABI issues affecting)
PR 88873. This patch generalizes the recent tweak to ix86_expand_move
for setting the highpart of a TImode reg from a DImode source using
*insvti_highpart_1, to handle both DImode and DFmode sources, and also
use the recently added *insvti_lowpart_1 for setting the lowpart.
Although this is another intermediate step (not yet a fix), towards
enabling *insvti and *concat* patterns to be candidates for TImode STV
(by using V2DI/V2DF instructions), it already improves things a little.
For the test case from PR 88873
typedef struct { double x, y; } s_t;
typedef double v2df __attribute__ ((vector_size (2 * sizeof(double;
s_t foo (s_t a, s_t b, s_t c)
{
return (s_t) { fma(a.x, b.x, c.x), fma (a.y, b.y, c.y) };
}
With -O2 -march=cascadelake, GCC currently generates:
Before (29 instructions):
vmovq %xmm2, -56(%rsp)
movq-56(%rsp), %rdx
vmovq %xmm4, -40(%rsp)
movq$0, -48(%rsp)
movq%rdx, -56(%rsp)
movq-40(%rsp), %rdx
vmovq %xmm0, -24(%rsp)
movq%rdx, -40(%rsp)
movq-24(%rsp), %rsi
movq-56(%rsp), %rax
movq$0, -32(%rsp)
vmovq %xmm3, -48(%rsp)
movq-48(%rsp), %rcx
vmovq %xmm5, -32(%rsp)
vmovq %rax, %xmm6
movq-40(%rsp), %rax
movq$0, -16(%rsp)
movq%rsi, -24(%rsp)
movq-32(%rsp), %rsi
vpinsrq $1, %rcx, %xmm6, %xmm6
vmovq %rax, %xmm7
vmovq %xmm1, -16(%rsp)
vmovapd %xmm6, %xmm3
vpinsrq $1, %rsi, %xmm7, %xmm7
vfmadd132pd -24(%rsp), %xmm7, %xmm3
vmovapd %xmm3, -56(%rsp)
vmovsd -48(%rsp), %xmm1
vmovsd -56(%rsp), %xmm0
ret
After (20 instructions):
vmovq %xmm2, -56(%rsp)
movq-56(%rsp), %rax
vmovq %xmm3, -48(%rsp)
vmovq %xmm4, -40(%rsp)
movq-48(%rsp), %rcx
vmovq %xmm5, -32(%rsp)
vmovq %rax, %xmm6
movq-40(%rsp), %rax
movq-32(%rsp), %rsi
vpinsrq $1, %rcx, %xmm6, %xmm6
vmovq %xmm0, -24(%rsp)
vmovq %rax, %xmm7
vmovq %xmm1, -16(%rsp)
vmovapd %xmm6, %xmm2
vpinsrq $1, %rsi, %xmm7, %xmm7
vfmadd132pd -24(%rsp), %xmm7, %xmm2
vmovapd %xmm2, -56(%rsp)
vmovsd -48(%rsp), %xmm1
vmovsd -56(%rsp), %xmm0
ret
2023-07-14 Roger Sayle
gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_move): Generalize special
case inserting of 64-bit values into a TImode register, to handle
both DImode and DFmode using either *insvti_lowpart_1
or *isnvti_highpart_1.
[Bug ada/110668] gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- Ada only supports being built by the same or older releases, while you're trying to bootstrap gcc-10.5 using gcc-13.1. That won't work in general. (For Canadian crosses it must be the exact same version.)
[Bug tree-optimization/110666] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110666 --- Comment #3 from Andrew Pinski --- Created attachment 55544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55544=edit Full testcase to make sure we don't create wrong code
[Bug ada/110668] New: gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110668 Bug ID: 110668 Summary: gcc/ada/gcc-interface/Make-lang.in:1012: ada/b_gnat1.adb] Error 5 Product: gcc Version: 10.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Not sure where this arrived from however here are the particulars : System is very off the shelf devuan/debian with a lean kernel : d# uname -a Linux dev 6.4.2-genunix #1 SMP PREEMPT_DYNAMIC Fri Jul 7 18:41:16 UTC 2023 x86_64 GNU/Linux d# Compiler used for the bootstrap : d# which gcc /opt/bw/gcc13/bin/gcc d# d# gcc --version gcc (GENUNIX Mon Jun 26 19:37:30 UTC 2023) 13.1.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. see https://gcc.gnu.org/pipermail/gcc-testresults/2023-June/788747.html So I suspect that compiler to be good stuff. With gnat in there also : d# ls /opt/bw/gcc13/bin/ c++ gfortran gnatprep cpp gnat lto-dump g++ gnatbind x86_64-pc-linux-gnu-c++ gcc gnatchop x86_64-pc-linux-gnu-g++ gcc-ar gnatclean x86_64-pc-linux-gnu-gcc gcc-nm gnatkr x86_64-pc-linux-gnu-gcc-13.1.0 gcc-ranlib gnatlink x86_64-pc-linux-gnu-gcc-ar gcovgnatls x86_64-pc-linux-gnu-gcc-nm gcov-dump gnatmake x86_64-pc-linux-gnu-gcc-ranlib gcov-tool gnatname x86_64-pc-linux-gnu-gfortran d# So imagine my total surprise when configure looks so nice and the whole compile/bootstrap takes off nicely but then falls over quickly : d# d# pwd /opt/bw/build/gcc-10.5.0_linux-6.4.2_x86_64.001 d# date -u Fri Jul 14 14:14:46 UTC 2023 d# ../gcc-10.5.0/configure --prefix=/opt/imed/gcc10 \ > --enable-languages=c,ada,c++,fortran,objc,obj-c++ \ > --enable-shared --without-included-gettext \ > --enable-threads=posix --enable-bootstrap --with-system-zlib \ > --enable-checking=misc --disable-multilib --disable-nls \ > --enable-__cxa_atexit --enable-tls \ > --with-pkgversion='GENUNIX Fri Jul 14 14:14:46 UTC 2023' 2>&1 | tee > ../gcc-10.5.0_linux-6.4.2_x86_64.001.config.log checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... no checking for mawk... mawk checking for libatomic support... yes checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... yes checking for libhsail-rt support... yes checking for libphobos support... yes checking for gcc... /opt/bw/gcc13/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/bw/gcc13/bin/gcc accepts -g... yes checking for /opt/bw/gcc13/bin/gcc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether /opt/bw/gcc13/bin/g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check The following languages will be built: c,ada,c++,fortran,lto,objc,obj-c++ *** This configuration is not supported in the following subdirectories: zlib gotools target-libhsail-rt target-libphobos target-zlib target-libgo target-libffi target-liboffloadmic (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... ar checking for as... as checking for dlltool... no checking for dsymutil... no checking for ld... ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... objcopy checking for objdump...
[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102854 --- Comment #4 from Tobias Burnus --- The testcase of comment 2 seems to be the same as the one of bug 106449 comment 4, which went in as r13-1887-g97d32048c04e97 openmp: Fix up handling of non-rectangular simd loops with pointer type iterators [PR106449] A slightly modified variant of that testcase went in follow-up commit r13-1893-g85fe7e7dd1f146 Add libgomp.c-c++-common/pr106449-2.c * * * >From the bug comments, it seems as if the following remains: "Non-rectangular loops with class random access iterators remain broken, that is something to be fixed incrementally." * * * However, given the commit for PR106449 (see above) and the earlier commit r12-4733-g2084b5f42a4432 openmp: Allow non-rectangular loops with pointer iterators (committed right after the commit of comment 3): I wonder whether the only thing that remains to be done is to add a real C++ testcase for random access iterator non-rect loops - assuming that the pointer patches cover all what's needed in terms of compiler support.
[Bug tree-optimization/110666] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110666
--- Comment #2 from Andrew Pinski ---
I totally messed up the !=1/!=0 cases for the outer eq case:
Patch
diff --git a/gcc/match.pd b/gcc/match.pd
index 351d9285e92..3de30df8b06 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -6431,8 +6431,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* x != (typeof x)(x == CST) -> CST == 0 ? 1 : (CST == 1 ? (x!=0&!=1) : x !=
0) */
/* x != (typeof x)(x != CST) -> CST == 1 ? 1 : (CST == 0 ? (x!=0&!=1) : x !=
1) */
-/* x == (typeof x)(x == CST) -> CST == 0 ? 0 : (CST == 1 ? (x==0||x==1) : x !=
0) */
-/* x == (typeof x)(x != CST) -> CST == 1 ? 0 : (CST == 0 ? (x==0||x==1) : x !=
1) */
+/* x == (typeof x)(x == CST) -> CST == 0 ? 0 : (CST == 1 ? (x==0||x==1) : x ==
0) */
+/* x == (typeof x)(x != CST) -> CST == 1 ? 0 : (CST == 0 ? (x==0||x==1) : x ==
1) */
(for outer (ne eq)
(for inner (ne eq)
(simplify
@@ -6457,9 +6457,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
)
)
)
-(if (innereq)
- (ne @0 { build_zero_cst (TREE_TYPE (@0)); }))
-(ne @0 { build_one_cst (TREE_TYPE (@0)); }))
+(with {
+ tree value = build_int_cst (TREE_TYPE (@0), !innereq);
+ }
+ (if (outereq)
+ (eq @0 { value; })
+ (ne @0 { value; })
+ )
+)
)
)
)
[Bug middle-end/110667] gcc-14, ICE: internal compiler error: in replace_reg, at reg-stack.cc:722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110667 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-07-14 Depends on||69899 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. All GCC I can get my hands on have ICEd (even though most hide it with "confused by earlier errors, bailing out"). `-O2 -ffinite-math-only` is enough to reproduce the ICE. So I almost think this is a dup of bug 69899 . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899 [Bug 69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"
[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110206
--- Comment #17 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:1815e313a8fb519a77c94a908eb6dafc4ce51ffe
commit r14-2525-g1815e313a8fb519a77c94a908eb6dafc4ce51ffe
Author: Uros Bizjak
Date: Fri Jul 14 11:46:22 2023 +0200
cprop: Do not set REG_EQUAL note when simplifying paradoxical subreg
[PR110206]
cprop1 pass does not consider paradoxical subreg and for (insn 22) claims
that it equals 8 elements of HImodeby setting REG_EQUAL note:
(insn 21 19 22 4 (set (reg:V4QI 98)
(mem/u/c:V4QI (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [0 S4 A32]))
"pr110206.c":12:42 1530 {*movv4qi_internal}
(expr_list:REG_EQUAL (const_vector:V4QI [
(const_int -52 [0xffcc]) repeated x4
])
(nil)))
(insn 22 21 23 4 (set (reg:V8HI 100)
(zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V4QI 98) 0)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
] "pr110206.c":12:42 7471
{sse4_1_zero_extendv8qiv8hi2}
(expr_list:REG_EQUAL (const_vector:V8HI [
(const_int 204 [0xcc]) repeated x8
])
(expr_list:REG_DEAD (reg:V4QI 98)
(nil
We rely on the "undefined" vals to have a specific value (from the earlier
REG_EQUAL note) but actual code generation doesn't ensure this (it doesn't
need to). That said, the issue isn't the constant folding per-se but that
we do not actually constant fold but register an equality that doesn't
hold.
PR target/110206
gcc/ChangeLog:
* fwprop.cc (contains_paradoxical_subreg_p): Move to ...
* rtlanal.cc (contains_paradoxical_subreg_p): ... here.
* rtlanal.h (contains_paradoxical_subreg_p): Add prototype.
* cprop.cc (try_replace_reg): Do not set REG_EQUAL note
when the original source contains a paradoxical subreg.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr110206.c: New test.
[Bug tree-optimization/110666] [14 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110666 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Target Milestone|--- |14.0 Last reconfirmed||2023-07-14 Ever confirmed|0 |1 Summary|wrong code at -O1 and above |[14 Regression] wrong code |on x86_64-linux-gnu |at -O1 and above on ||x86_64-linux-gnu Version|unknown |14.0 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine. Let me look at what I did wrong.
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 --- Comment #9 from Rich Townsend --- OK, I managed to get things working by setting export LDFLAGS='-Wl,--no-eh-frame-hdr' prior to configuring. I'm hoping this won't affect the functionality of the built compiler.
[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649 --- Comment #4 from Jan Hubicka --- We also have PR98782 that is about sphinx being sensitive to LRA decisions. Reducing loopback probability might trigger LRA adding a spill to the loop.
[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=10647
Ever confirmed|0 |1
Last reconfirmed||2023-07-14
Status|UNCONFIRMED |NEW
--- Comment #3 from Jan Hubicka ---
Thanks for bisecting this! We also have PR10647 which is tracked to this
change.
The change correct loop profile after header copying:
test()
{
for (int i = 0; i < 10; i++)
test2();
}
has probability of exit conditional 90.9% before loop header copying (since it
technically iterates 10 times) while after loop header copying and optimizing
out the constant "if (0<10)" test it has only 90% loopback probability.
So probably fixing the bug above triggers something else.
I will first look at PR10647 and see if I can figure out what is going on
there.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 Alexander Klepikov changed: What|Removed |Added Attachment #55503|0 |1 is obsolete|| Attachment #55513|0 |1 is obsolete|| --- Comment #102 from Alexander Klepikov --- Created attachment 55543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55543=edit Arithmetic right shift late expanding v2 Here's the patch. I hope I did not miss anything. Now considering regexp. I remade it using 'check-function-bodies' command and now it looks less confusing. I also found that in this testcase right shift expands to 'shad' instructions early on platforms that have dynamic shift support, so I deleted checks for those CPUs. I don't like that 'check-function-bodies' ignores asm labels but it's better than nothing.
[Bug c/110667] New: gcc-14, ICE: internal compiler error: in replace_reg, at reg-stack.cc:722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110667
Bug ID: 110667
Summary: gcc-14, ICE: internal compiler error: in replace_reg,
at reg-stack.cc:722
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
When compiling below program using gcc-14 with option `gcc-14 -Ofast a.c`,
gcc-14 crashes:
```
#include
#include
void f() {
long double res = 0;
asm("" : "="(res) : "f"(40.), "f"(2.));
assert(res == 42.);
}
```
GCC's output is pasted below:
```
: In function 'f':
:6:3: error: output constraint 0 must specify a single register
6 | asm("" : "="(res) : "f"(40.), "f"(2.));
| ^~~
during RTL pass: stack
:8:1: internal compiler error: in replace_reg, at reg-stack.cc:722
8 | }
| ^
0x214e13e internal_error(char const*, ...)
???:0
0x9cd8e8 fancy_abort(char const*, int, char const*)
???: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/110666] New: wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110666
Bug ID: 110666
Summary: wrong code at -O1 and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression.
Compiler Explorer: https://godbolt.org/z/xG14vrs6K
[501] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230714 (experimental) (GCC)
[502] %
[502] % gcctk -O0 small.c; ./a.out
[503] % gcctk -O1 small.c; ./a.out
Aborted
[504] % cat small.c
int a;
int main() {
if ((a != 2) == a)
__builtin_abort();
return 0;
}
[Bug target/110665] RISC-V do not preserve vector registers in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110665 --- Comment #2 from Lehua Ding --- I just found the relevant specification and the specification seems to require that the vector registers used be saved. > The interrupt attribute specifies that a function is an interrupt handler. > The compiler will save/restore all used registers in the prologue/epilogue > regardless of the ABI, all used registers including floating point > register/vector register if F extension/vector extension is enabled. From https://github.com/riscv-non-isa/riscv-c-api-doc/blob/master/riscv-c-api.md#__attribute__interrupt-__attribute__interruptuser-__attribute__interruptsupervisor-__attribute__interruptmachine
[Bug target/110665] RISC-V do not preserve vector registers in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110665 --- Comment #1 from Lehua Ding --- If it's a problem, I'm willing to fix it.
[Bug target/110665] New: RISC-V do not preserve vector registers in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110665 Bug ID: 110665 Summary: RISC-V do not preserve vector registers in interrupt handler Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: lehua.ding at rivai dot ai Target Milestone: --- When an interrupt handler uses vector registers or calls other functions, the handler needs to preserve the content in vector registers like GP or FP registers. Currently, the GCC fully ignores the existence of vector registers for this case even using -march=rv64gcv option. Issue on Compiler Explorer: https://godbolt.org/z/nTGzr4o5P
[Bug tree-optimization/109112] [[assume(...)]] is not taken into account for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112
--- Comment #8 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #7)
> Why don't the existing optimizations work on the artificial function the
> same as any other function? i.e. like
>
> struct S { bool x; };
> void do_something();
> inline void assumption_1 (const S& s) noexcept {
> if (s.x) __builtin_unreachable ();
> }
> void fn(S s) {
> assumption_1 (s);
> if (s.x) do_something();
> }
>
> which is also optimized as expected.
Because the assumptions have different representation in the IL.
While normal calls look like:
ret = foo (arg1, arg2, arg3);
and we can inline those etc., because the assumptions potentially contain
side-effects which shouldn't be evaluated and therefore should e.g. not be
inlined nor assumed that they are actually called, the representation is like:
.ASSUME (, arg1, arg2, arg3);
where foo is that artificial assumption function which takes arg1, arg2, arg3.
The above behaves like if (!foo (arg1, arg2, arg3)) __builtin_unreachable ();
except that the function actually isn't called (nor emitted into assembly
etc.).
The assumption is if this function would be called and returned false at this
spot,
it would be UB.
So, VRP walks the assumption function (after optimizations are performed on it,
e.g. inlining into those and various other optimizations) backwards from the
return value starting with [1, 1] and from that derives ranges for the
arguments.
Similarly to how for functions which aren't inlined but can be e.g. cloned it
is essential to get IPA SRA and IPA CP etc. optimizations to tweak the
arguments of functions (scalarize them, remove unneeded ones, replace others),
it is needed
that we optimize the assumptions similarly. The assumption functions should be
always static and often will have a single reference (unless inlined multiple
times / loop unrolled), so it is just fine to tweak them, just those
optimizations will need
to special case the IFN_ASSUME internal calls and treat
.ASSUME (, arg1, arg2, arg3);
more like
foo (arg1, arg2, arg3);
(i.e. off by one argument and treat it as if there was a call edge from the
.ASSUME
caller to foo.
[Bug middle-end/87944] Wrong code with LRA pushing stack local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87944 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #5 from Mikael Pettersson --- Appears to have been fixed for gcc-14.0 by 30038a207c10a2783fa2695b62c7c8458ef05e73 is the first new commit commit 30038a207c10a2783fa2695b62c7c8458ef05e73 Author: Vladimir N. Makarov Date: Tue May 30 15:54:28 2023 -0400 LRA: Update insn sp offset if its input reload changes SP which mentions a problem switching the h8300 to lra, but there's no PR reference in either the commit message or the mailing-list post.
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 --- Comment #6 from Jose E. Marchesi --- Hello Kris. The commit above (now in gcc master) should fix the issue. Can you please confirm? Thanks!
[Bug target/110657] BPF verifier rejects generated code due to invalid stack access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657 --- Comment #5 from CVS Commits --- The master branch has been updated by Jose E. Marchesi : https://gcc.gnu.org/g:53d12ecd624ec901d8449cfa1917f6f90e910927 commit r14-2522-g53d12ecd624ec901d8449cfa1917f6f90e910927 Author: Jose E. Marchesi Date: Fri Jul 14 13:54:06 2023 +0200 bpf: enable instruction scheduling This patch adds a dummy FSM to bpf.md in order to get INSN_SCHEDULING defined. If the later is not defined, the `combine' pass generates paradoxical subregs of mems, which seems to then be mishandled by LRA, resulting in invalid code. Tested in bpf-unknown-none. gcc/ChangeLog: 2023-07-14 Jose E. Marchesi PR target/110657 * config/bpf/bpf.md: Enable instruction scheduling.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #20 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:71e4d568b1264bca46d30c5fc4933f137d05ca24 commit r14-2520-g71e4d568b1264bca46d30c5fc4933f137d05ca24 Author: Mikael Morin Date: Fri Jul 14 14:15:21 2023 +0200 fortran: Factor data references for scalar class argument wrapping [PR92178] In the case of a scalar actual arg passed to a polymorphic assumed-rank dummy with INTENT(OUT) attribute, avoid repeatedly evaluating the actual argument reference by saving a pointer to it. This is non-optimal, but may also be invalid, because the data reference may depend on its own content. In that case the expression can't be evaluated after the data has been deallocated. There are two ways redundant expressions are generated: - parmse.expr, which contains the actual argument expression, is reused to get or set subfields in gfc_conv_class_to_class. - gfc_conv_class_to_class, to get the virtual table pointer associated with the argument, generates a new expression from scratch starting with the frontend expression. The first part is fixed by saving parmse.expr to a pointer and using the pointer instead of the original expression. The second part is fixed by adding a separate field to gfc_se that is set to the class container expression when the expression to evaluate is polymorphic. This needs the same field in gfc_ss_info so that its value can be propagated to gfc_conv_class_to_class which is modified to use that value. Finally gfc_conv_procedure saves the expression in that field to a pointer in between to avoid the same problem as for the first part. PR fortran/92178 gcc/fortran/ChangeLog: * trans.h (struct gfc_se): New field class_container. (struct gfc_ss_info): Ditto. (gfc_evaluate_data_ref_now): New prototype. * trans.cc (gfc_evaluate_data_ref_now): Implement it. * trans-array.cc (gfc_conv_ss_descriptor): Copy class_container field from gfc_se struct to gfc_ss_info struct. (gfc_conv_expr_descriptor): Copy class_container field from gfc_ss_info struct to gfc_se struct. * trans-expr.cc (gfc_conv_class_to_class): Use class container set in class_container field if available. (gfc_conv_variable): Set class_container field on encountering class variables or components, clear it on encountering non-class components. (gfc_conv_procedure_call): Evaluate data ref to a pointer now, and replace later references by usage of the pointer. gcc/testsuite/ChangeLog: * gfortran.dg/intent_out_20.f90: New test.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #21 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:9206641d0899e4bae3ad6765129661ff3bcc423a commit r14-2521-g9206641d0899e4bae3ad6765129661ff3bcc423a Author: Mikael Morin Date: Fri Jul 14 14:15:51 2023 +0200 fortran: Reorder array argument evaluation parts [PR92178] In the case of an array actual arg passed to a polymorphic array dummy with INTENT(OUT) attribute, reorder the argument evaluation code to the following: - first evaluate arguments' values, and data references, - deallocate data references associated with an allocatable, intent(out) dummy, - create a class container using the freed data references. The ordering used to be incorrect between the first two items, when one argument was deallocated before a later argument evaluated its expression depending on the former argument. r14-2395-gb1079fc88f082d3c5b583c8822c08c5647810259 fixed it by treating arguments associated with an allocatable, intent(out) dummy in a separate, later block. This, however, wasn't working either if the data reference of such an argument was depending on its own content, as the class container initialization was trying to use deallocated content. This change generates class container initialization code in a separate block, so that it is moved after the deallocation block without moving the rest of the argument evaluation code. This alone is not sufficient to fix the problem, because the class container generation code repeatedly uses the full expression of the argument at a place where deallocation might have happened already. This is non-optimal, but may also be invalid, because the data reference may depend on its own content. In that case the expression can't be evaluated after the data has been deallocated. As in the scalar case previously treated, this is fixed by saving the data reference to a pointer before any deallocation happens, and then only refering to the pointer. gfc_reset_vptr is updated to take into account the already evaluated class container if it's available. Contrary to the scalar case, one hunk is needed to wrap the parameter evaluation in a conditional, to avoid regressing in optional_class_2.f90. This used to be handled by the class wrapper construction which wrapped the whole code in a conditional. With this change the class wrapper construction can't see the parameter evaluation code, so the latter is updated with an additional handling for optional arguments. PR fortran/92178 gcc/fortran/ChangeLog: * trans.h (gfc_reset_vptr): Add class_container argument. * trans-expr.cc (gfc_reset_vptr): Ditto. If a valid vptr can be obtained through class_container argument, bypass evaluation of e. (gfc_conv_procedure_call): Wrap the argument evaluation code in a conditional if the associated dummy is optional. Evaluate the data reference to a pointer now, and replace later references with usage of the pointer. gcc/testsuite/ChangeLog: * gfortran.dg/intent_out_21.f90: New test.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #19 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:e93452a5712e87ba624562ba7164b1e1394d18fb commit r14-2519-ge93452a5712e87ba624562ba7164b1e1394d18fb Author: Mikael Morin Date: Fri Jul 14 14:15:07 2023 +0200 fortran: defer class wrapper initialization after deallocation [PR92178] If an actual argument is associated with an INTENT(OUT) dummy, and code to deallocate it is generated, generate the class wrapper initialization after the actual argument deallocation. This is achieved by passing a cleaned up expression to gfc_conv_class_to_class, so that the class wrapper initialization code can be isolated and moved independently after the deallocation. PR fortran/92178 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): Use a separate gfc_se struct, initalized from parmse, to generate the class wrapper. After the class wrapper code has been generated, copy it back depending on whether parameter deallocation code has been generated. gcc/testsuite/ChangeLog: * gfortran.dg/intent_out_19.f90: New test.
[Bug bootstrap/110550] libintl build without -fPIC even though --enable-shared is configured
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110550 --- Comment #2 from Sascha Wilde --- (please excuse my late reply) Indeed without jit the build works as expected. However, jit is the primary reason I'm building gcc on NetBSD. Building relocateable code also in the supporting libraries is essential for jit to work. (see also #100096 for reference)
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55538|0 |1
is obsolete||
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #80 from Jakub Jelinek ---
Created attachment 55542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55542=edit
gcc14-bitint-wip.patch
Now float,double,long double,__float128 -> {signed,unsigned} _BitInt(N)
conversions seem to work (at least on the testsuite coverage).
[Bug c/110664] New: -std=c2x -pedantic-errors pedwarns on _Float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110664 Bug ID: 110664 Summary: -std=c2x -pedantic-errors pedwarns on _Float128 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- _Float128 f = 1.0F128; gcc -S -std=c2x -o /dev/null test.c -pedantic-errors test.c:1:1: error: ISO C does not support the ‘_Float128’ type [-Wpedantic] 1 | _Float128 f = 1.0F128; | ^ test.c:1:1: error: non-standard suffix on floating constant [-Wpedantic] doesn't seem right to me, shouldn't those pedwarns be skipped for flag_isoc2x?
[Bug tree-optimization/109156] Support Absolute Difference detection in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109156 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Tamar Christina --- This is now implemented
[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86486 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Tamar Christina --- GCC 8 is long gone
[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #67 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:9ed4fcfe47f28b36c73d74109898514ef4da00fb commit r14-2517-g9ed4fcfe47f28b36c73d74109898514ef4da00fb Author: Tamar Christina Date: Fri Jul 14 11:21:46 2023 +0100 ifcvt: Sort PHI arguments not only occurrences but also complexity [PR109154] This patch builds on the previous patch by fixing another issue with the way ifcvt currently picks which branches to test. The issue with the current implementation is while it sorts for occurrences of the argument, it doesn't check for complexity of the arguments. As an example: [local count: 528603100]: ... if (distbb_75 >= 0.0) goto ; [59.00%] else goto ; [41.00%] [local count: 216727269]: ... goto ; [100.00%] [local count: 311875831]: ... if (distbb_75 < iftmp.0_98) goto ; [20.00%] else goto ; [80.00%] [local count: 62375167]: ... [local count: 528603100]: # prephitmp_175 = PHI <_173(18), 0.0(17), _174(16)> All tree arguments to the PHI have the same number of occurrences, namely 1, however it makes a big difference which comparison we test first. Sorting only on occurrences we'll pick the compares coming from BB 18 and BB 17, This means we end up generating 4 comparisons, while 2 would have been enough. By keeping track of the "complexity" of the COND in each BB, (i.e. the number of comparisons needed to traverse from the start [BB 15] to end [BB 19]) and using a key tuple of we end up selecting the compare from BB 16 and BB 18 first. BB 16 only requires 1 compare, and BB 18, after we test BB 16 also only requires one additional compare. This change paired with the one previous above results in the optimal 2 compares. For deep nesting, i.e. for ... _79 = vr_15 > 20; _80 = _68 & _79; _82 = vr_15 <= 20; _83 = _68 & _82; _84 = vr_15 < -20; _85 = _73 & _84; _87 = vr_15 >= -20; _88 = _73 & _87; _ifc__111 = _55 ? 10 : 12; _ifc__112 = _70 ? 7 : _ifc__111; _ifc__113 = _85 ? 8 : _ifc__112; _ifc__114 = _88 ? 9 : _ifc__113; _ifc__115 = _45 ? 1 : _ifc__114; _ifc__116 = _63 ? 3 : _ifc__115; _ifc__117 = _65 ? 4 : _ifc__116; _ifc__118 = _83 ? 6 : _ifc__117; _ifc__119 = _60 ? 2 : _ifc__118; _ifc__120 = _43 ? 13 : _ifc__119; _ifc__121 = _75 ? 11 : _ifc__120; vw_1 = _80 ? 5 : _ifc__121; Most of the comparisons are still needed because the chain of occurrences to not negate eachother. i.e. _80 is _73 & vr_15 >= -20 and _85 is _73 & vr_15 < -20. clearly given _73 needs to be true in both branches, the only additional test needed is on vr_15, where the one test is the negation of the other. So we don't need to do the comparison of _73 twice. The changes in the patch reduces the overall number of compares by one, but has a bigger effect on the dependency chain. Previously we would generate 5 instructions chain: cmple p7.s, p4/z, z29.s, z30.s cmpne p7.s, p7/z, z29.s, #0 cmple p6.s, p7/z, z31.s, z30.s cmpge p6.s, p6/z, z27.s, z25.s cmplt p15.s, p6/z, z28.s, z21.s as the longest chain. With this patch we generate 3: cmple p7.s, p3/z, z27.s, z30.s cmpne p7.s, p7/z, z27.s, #0 cmpgt p7.s, p7/z, z31.s, z30.s and I don't think (x <= y) && (x != 0) && (z > y) can be reduced further. gcc/ChangeLog: PR tree-optimization/109154 * tree-if-conv.cc (INCLUDE_ALGORITHM): Include. (struct bb_predicate): Add no_predicate_stmts. (set_bb_predicate): Increase predicate count. (set_bb_predicate_gimplified_stmts): Conditionally initialize no_predicate_stmts. (get_bb_num_predicate_stmts): New. (init_bb_predicate): Initialzie no_predicate_stmts. (release_bb_predicate): Cleanup no_predicate_stmts. (insert_gimplified_predicates): Preserve no_predicate_stmts. gcc/testsuite/ChangeLog: PR tree-optimization/109154 * gcc.dg/vect/vect-ifcvt-20.c: New test.
[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #66 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:d8f5e349772b6652bddb0620bb178290905998b9
commit r14-2516-gd8f5e349772b6652bddb0620bb178290905998b9
Author: Tamar Christina
Date: Fri Jul 14 11:21:12 2023 +0100
ifcvt: Reduce comparisons on conditionals by tracking truths [PR109154]
Following on from Jakub's patch in
g:de0ee9d14165eebb3d31c84e98260c05c3b33acb
these two patches finishes the work fixing the regression and improves
codegen.
As explained in that commit, ifconvert sorts PHI args in increasing number
of
occurrences in order to reduce the number of comparisons done while
traversing the tree.
The remaining task that this patch fixes is dealing with the long chain of
comparisons that can be created from phi nodes, particularly when they
share
any common successor (classical example is a diamond node).
on a PHI-node the true and else branches carry a condition, true will
carry `a` and false `~a`. The issue is that at the moment GCC tests both
`a`
and `~a` when the phi node has more than 2 arguments. Clearly this isn't
needed. The deeper the nesting of phi nodes the larger the repetition.
As an example, for
foo (int *f, int d, int e)
{
for (int i = 0; i < 1024; i++)
{
int a = f[i];
int t;
if (a < 0)
t = 1;
else if (a < e)
t = 1 - a * d;
else
t = 0;
f[i] = t;
}
}
after Jakub's patch we generate:
_7 = a_10 < 0;
_21 = a_10 >= 0;
_22 = a_10 < e_11(D);
_23 = _21 & _22;
_ifc__42 = _23 ? t_13 : 0;
t_6 = _7 ? 1 : _ifc__42
but while better than before it is still inefficient, since in the false
branch, where we know ~_7 is true, we still test _21.
This leads to superfluous tests for every diamond node. After this patch
we
generate
_7 = a_10 < 0;
_22 = a_10 < e_11(D);
_ifc__42 = _22 ? t_13 : 0;
t_6 = _7 ? 1 : _ifc__42;
Which correctly elides the test of _21. This is done by borrowing the
vectorizer's helper functions to limit predicate mask usages. Ifcvt will
chain
conditionals on the false edge (unless specifically inverted) so this patch
on
creating cond a ? b : c, will register ~a when traversing c. If c is a
conditional then c will be simplified to the smaller possible predicate
given
the assumptions we already know to be true.
gcc/ChangeLog:
PR tree-optimization/109154
* tree-if-conv.cc (gen_simplified_condition,
gen_phi_nest_statement): New.
(gen_phi_arg_condition, predicate_scalar_phi): Use it.
gcc/testsuite/ChangeLog:
PR tree-optimization/109154
* gcc.dg/vect/vect-ifcvt-19.c: New test.
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #14 from YunQiang Su ---
New patch:
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index fbd4ce2d42f..66d45da67df 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -850,6 +850,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
since that case is valid for any mode. The following cases are only
valid for integral modes. */
opt_scalar_int_mode op0_mode = int_mode_for_mode (GET_MODE (op0));
+ opt_scalar_int_mode str_mode = int_mode_for_mode (GET_MODE (str_rtx));
scalar_int_mode imode;
if (!op0_mode.exists () || imode != GET_MODE (op0))
{
@@ -881,8 +882,15 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
op0 = gen_lowpart (op0_mode.require (), op0);
}
- return store_integral_bit_field (op0, op0_mode, ibitsize, ibitnum,
- bitregion_start, bitregion_end,
+ bool use_str_mode = false;
+ if (GET_MODE_CLASS(GET_MODE (str_rtx)) == MODE_INT
+ && GET_MODE_CLASS(GET_MODE (op0)) == MODE_INT
+ && known_gt (GET_MODE_SIZE(GET_MODE(op0)),
GET_MODE_SIZE(GET_MODE(str_rtx
+use_str_mode = true;
+
+ return store_integral_bit_field (use_str_mode ? str_rtx : op0,
+ use_str_mode ? str_mode : op0_mode,
+ ibitsize, ibitnum, bitregion_start,
bitregion_end,
fieldmode, value, reverse, fallback_p);
}
[Bug libgomp/110663] [OpenMP] Use 'affinity' clause for node placement for the 'task' construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110663 --- Comment #1 from Tobias Burnus --- Carry on of Jakub's comment in PR99666 about implementing this: "Yeah, but not really sure if we want to do anything with it other than accept it / verify the restrictions. "The tasking is already overly complicated and the right way is to make it more scalable (have per thread task queues with work stealing rather than the 3 different queues we currently have with per-team lock)."
[Bug middle-end/99666] [OpenMP][5.0] Support 'affinity' clause in 'omp task'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99666 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tobias Burnus --- 'affinity' including iterator is parsed since r12-1108-g9a5de4d5af1c10 - with a bunch of follow-up commits fixing various issues. However, it is ignored after parsing and not used for thread placement. The latter is tracked as PR110663 Hence, this PR can be closed as FIXED (in/since GCC 12).
[Bug libgomp/110663] New: [OpenMP] Use 'affinity' clause for node placement for the 'task' construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110663 Bug ID: 110663 Summary: [OpenMP] Use 'affinity' clause for node placement for the 'task' construct Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization, openmp Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Follow up to PR99666. We currently accept the affinity clause (since r12-1108-g9a5de4d5af1c10 with a couple of follow-up commits) – however, after evaluation it is ignored. HPC indicated that it would be useful it would actually be useful to place threads on the node where the data is present. libnuma (→ https://github.com/numactl/numactl ) defines a function (get_mempolicy) which calls the Linux kernel (syscall) to determine on which node a given pointer address is located (allocated or moved to). This data can then be used to find the associated CPUs using the /sys data (e.g. via libnuma, which caches that data). (Note that get_mempolicy will only return the node for the address; the storage might span multiple nodes, e.g. with allocation 'blocked'/'interleaved'. The affinity clause knows about the size and not only about the first address. (Cf also https://gcc.gnu.org/onlinedocs/libgomp/Memory-allocation.html ) * * * >From the OpenMP spec: "affinity Clause "The affinity clause specifies a hint to indicate data affinity of tasks generated by the construct on which it appears. The hint recommends to execute generated tasks close to the location of the original list items. A program that relies on the task execution location being determined by this list may have unspecified behavior. "The list items that appear in the affinity clause may also appear in data-environment clauses. The list items may reference any iterators-identifier that is defined in the same clause and may include array sections. "[C/C++] The list items that appear in the affinity clause may use shape-operators."
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #10 from Jonathan Wakely ---
And this should fix it:
--- a/libstdc++-v3/include/c_global/cstdlib
+++ b/libstdc++-v3/include/c_global/cstdlib
@@ -256,6 +256,20 @@ namespace std
using ::__gnu_cxx::strtold;
} // namespace std
+#else // ! _GLIBCXX_USE_C99_STDLIB
+
+// We also check for strtof and strtold separately from
_GLIBCXX_USE_C99_STDLIB
+
+#if _GLIBCXX_HAVE_STRTOF
+#undef strtof
+namespace std { using ::strtof; }
+#endif
+
+#if _GLIBCXX_HAVE_STRTOLD
+#undef strtold
+namespace std { using ::strtold; }
+#endif
+
#endif // _GLIBCXX_USE_C99_STDLIB
} // extern "C++"
[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625 --- Comment #3 from Hao Liu --- Sorry, it seems this case can not be fixed by only adjusting the calculation of "reduction latency". Even it becomes smaller, the case still can not be vectorized as the "general operations" count is still too large: Original vector body cost = 51 Scalar issue estimate: ... general operations = 8 reduction latency = 2 estimated min cycles per iteration = 2.00 estimated cycles per vector iteration (for VF 2) = 4.00 Vector issue estimate: ... general operations = 15 <-- Too large reduction latency = 2 <-- from 8 to 2 estimated min cycles per iteration = 7.50 Increasing body cost to 96 because scalar code would issue more quickly ... missed: cost model: the vector iteration cost = 96 divided by the scalar iteration cost = 44 is greater or equal to the vectorization factor = 2. missed: not vectorized: vectorization not profitable.
[Bug middle-end/110660] conditional length reduction optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110660
--- Comment #3 from rguenther at suse dot de ---
On Fri, 14 Jul 2023, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110660
>
> --- Comment #2 from JuzheZhong ---
> (In reply to Richard Biener from comment #1)
> > The vectorizer itself could do the merging which means it could also more
> > accurately cost things.
> >
>
> It's similar with ARM SVE:
>
> https://godbolt.org/z/8cn5j1zTr
>
> vect.dump:
>
> vect__ifc__33.15_53 = VEC_COND_EXPR }>;
> vect__34.16_54 = .COND_ADD (loop_mask_43, vect_res_19.7_40,
> vect__ifc__33.15_53, vect_res_19.7_40);
>
>
> optimized.dump:
>
> vect__34.16_54 = .COND_ADD (vec_mask_and_49, vect_res_19.7_40, vect__7.14_50,
> vect_res_19.7_40);
>
> No vcond_mask
>
> GCC can fuse vec_cond_expr with COND_ADD, I think this pattern in match.pd
> helps:
>
> /* Detect cases in which a VEC_COND_EXPR effectively replaces the
>"else" value of an IFN_COND_*. */
> (for cond_op (COND_BINARY)
> (simplify
> (vec_cond @0 (view_convert? (cond_op @0 @1 @2 @3)) @4)
> (with { tree op_type = TREE_TYPE (@3); }
>(if (element_precision (type) == element_precision (op_type))
> (view_convert (cond_op @0 @1 @2 (view_convert:op_type @4))
> (simplify
> (vec_cond @0 @1 (view_convert? (cond_op @2 @3 @4 @5)))
> (with { tree op_type = TREE_TYPE (@5); }
>(if (inverse_conditions_p (@0, @2)
> && element_precision (type) == element_precision (op_type))
> (view_convert (cond_op @2 @3 @4 (view_convert:op_type @1)))
>
>
>
> > Otherwise think about whether/how such a situation might arise from people
> > using RVV intrinsics - how are those exposed to GIMPLE / RTL and at which
> > level could that be optimized? Is it possible to write an intrinsic
> > testcase with such opportunity?
>
> This piece code, users can easily write intrinsics to produce that but I
> don't think compiler should help users to optimize that:
>
> user can write this code:
>
> size_t vl = vsetvl;
> vbool32_t mask = comparison;
> vbool32_t dummy_mask = vmset;
> vint32m1_t dummy_else_value = {0};
> vint32m1_t op1_1 = vload;
> vint32m1_t op1_2 = vmerge (op1_1,dummy_else_value,mask)
> vint32m1_t result = vadd (dummy_mask,op0,op1_2,op0,vl);
>
> Writing the intrinsics as above will generate the same codegen as the
> this example auto-vectorization codegen.
>
> However, I don't think compiler should optimize this intrinsic codes since
> this intentional codes written by uers. If user want to optimize this codegen,
> user can easily modify these intrinsic as follows:
>
> size_t vl = vsetvl;
> vbool32_t mask = comparison;
> vint32m1_t op1_1 = vload;
> vint32m1_t result = vadd (mask,op0,op1_1,op0,vl);
>
> Then user can get optimal codegen.
Sure. For that to reliably work the intrinsics need to stay target
builtins and UNSPECS, but I'm not entirely convinced this is always
what users want.
> So, I am not sure whether such optimization for auto-vectorization should be
> done in middle-end (match.pd) or backend (combine pass).
>
> Are you suggesting me doing this in the backend?
If there's a match.pd pattern doing this for SVE try to extend that.
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 --- Comment #6 from rguenther at suse dot de --- On Fri, 14 Jul 2023, linkw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 > > Kewen Lin changed: > >What|Removed |Added > > CC||rguenth at gcc dot gnu.org > > --- Comment #5 from Kewen Lin --- > I can reproduce this on cfarm x86 machine, the complained line is exactly the > one in comment #c4, I believe it's a false positive. > > How do we work around this normally? Just initializing new_temp with > NULL_TREE > as below? Yes, possibly with a comment refering to this PR.
[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653 --- Comment #9 from Jonathan Wakely --- (In reply to dave.anglin from comment #8) > or maybe "using::strtold" additions are needed to various cstdlib files in > gcc. Yes, that's the problem.
[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649 --- Comment #2 from Hao Liu --- Hi, I bisected the following 3 commits (sequantial): [v3] 3a61ca1b925 - Improve profile updates after loop-ch and cunroll (2023-07-06) [v2] d4c2e34deef - Improve scale_loop_profile (2023-07-06) [v1] 224fd59b2dc - Vect: use a small step to calculate induction for the unrolled loop (PR tree-optimization/110449) (2023-07-06) Tests the time in seconds of 1-copy performance of 482.sphinx3 on zen2: v3: 261s v2: 231s v1: 231s So the regression should be caused by 3a61ca1b925, i.e. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3a61ca1b9256535e1bfb19b2d46cde21f3908a5d
[Bug rtl-optimization/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110206 --- Comment #16 from Uroš Bizjak --- v2 patch at [1]. [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624491.html
[Bug middle-end/110660] conditional length reduction optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110660
--- Comment #2 from JuzheZhong ---
(In reply to Richard Biener from comment #1)
> The vectorizer itself could do the merging which means it could also more
> accurately cost things.
>
It's similar with ARM SVE:
https://godbolt.org/z/8cn5j1zTr
vect.dump:
vect__ifc__33.15_53 = VEC_COND_EXPR ;
vect__34.16_54 = .COND_ADD (loop_mask_43, vect_res_19.7_40,
vect__ifc__33.15_53, vect_res_19.7_40);
optimized.dump:
vect__34.16_54 = .COND_ADD (vec_mask_and_49, vect_res_19.7_40, vect__7.14_50,
vect_res_19.7_40);
No vcond_mask
GCC can fuse vec_cond_expr with COND_ADD, I think this pattern in match.pd
helps:
/* Detect cases in which a VEC_COND_EXPR effectively replaces the
"else" value of an IFN_COND_*. */
(for cond_op (COND_BINARY)
(simplify
(vec_cond @0 (view_convert? (cond_op @0 @1 @2 @3)) @4)
(with { tree op_type = TREE_TYPE (@3); }
(if (element_precision (type) == element_precision (op_type))
(view_convert (cond_op @0 @1 @2 (view_convert:op_type @4))
(simplify
(vec_cond @0 @1 (view_convert? (cond_op @2 @3 @4 @5)))
(with { tree op_type = TREE_TYPE (@5); }
(if (inverse_conditions_p (@0, @2)
&& element_precision (type) == element_precision (op_type))
(view_convert (cond_op @2 @3 @4 (view_convert:op_type @1)))
> Otherwise think about whether/how such a situation might arise from people
> using RVV intrinsics - how are those exposed to GIMPLE / RTL and at which
> level could that be optimized? Is it possible to write an intrinsic
> testcase with such opportunity?
This piece code, users can easily write intrinsics to produce that but I
don't think compiler should help users to optimize that:
user can write this code:
size_t vl = vsetvl;
vbool32_t mask = comparison;
vbool32_t dummy_mask = vmset;
vint32m1_t dummy_else_value = {0};
vint32m1_t op1_1 = vload;
vint32m1_t op1_2 = vmerge (op1_1,dummy_else_value,mask)
vint32m1_t result = vadd (dummy_mask,op0,op1_2,op0,vl);
Writing the intrinsics as above will generate the same codegen as the
this example auto-vectorization codegen.
However, I don't think compiler should optimize this intrinsic codes since
this intentional codes written by uers. If user want to optimize this codegen,
user can easily modify these intrinsic as follows:
size_t vl = vsetvl;
vbool32_t mask = comparison;
vint32m1_t op1_1 = vload;
vint32m1_t result = vadd (mask,op0,op1_1,op0,vl);
Then user can get optimal codegen.
So, I am not sure whether such optimization for auto-vectorization should be
done in middle-end (match.pd) or backend (combine pass).
Are you suggesting me doing this in the backend?
Thanks.
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 Kewen Lin changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #5 from Kewen Lin --- I can reproduce this on cfarm x86 machine, the complained line is exactly the one in comment #c4, I believe it's a false positive. How do we work around this normally? Just initializing new_temp with NULL_TREE as below? diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc index c08d0ef951f..124caab5c1f 100644 --- a/gcc/tree-vect-stmts.cc +++ b/gcc/tree-vect-stmts.cc @@ -9297,7 +9297,7 @@ vectorizable_load (vec_info *vinfo, class loop *containing_loop = gimple_bb (stmt_info->stmt)->loop_father; bool nested_in_vect_loop = false; tree elem_type; - tree new_temp; + tree new_temp = NULL_TREE; machine_mode mode; tree dummy; tree dataref_ptr = NULL_TREE;
[Bug ipa/110662] Segmentation fault with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110662 Richard Biener changed: What|Removed |Added Keywords||wrong-code Known to fail||11.3.0 Known to work||12.3.0 CC||marxin at gcc dot gnu.org Last reconfirmed||2023-07-14 Component|c |ipa Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Likely a duplicate of one of the IPA bugs where we assume some code is DCEd but isn't. Later compilers manually forced DCEing there. For this testcase -fno-ipa-sra fixes it. Fixed in GCC 12.
[Bug c/110662] Segmentation fault with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110662 --- Comment #2 from CTC <19373742 at buaa dot edu.cn> --- The reduced sequence is -O3 -fno-dce -fno-tree-dce -fno-tree-sink
