public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits @ 2021-10-15 20:09 seurer at gcc dot gnu.org 2021-10-15 20:10 ` [Bug libgomp/102789] " seurer at gcc dot gnu.org ` (15 more replies) 0 siblings, 16 replies; 17+ messages in thread From: seurer at gcc dot gnu.org @ 2021-10-15 20:09 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Bug ID: 102789 Summary: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- g:fab2f61dc1b195fec9161be15635b87d312e4626, r12-4340 make -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32}' c++.exp=libgomp.c++/simd-3.C" FAIL: libgomp.c++/simd-3.C execution test # of expected passes 1 # of unexpected failures 1 I couldn't get a traceback of where it failed other than it was in main. commit fab2f61dc1b195fec9161be15635b87d312e4626 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Oct 12 09:28:10 2021 +0200 vectorizer: Fix up -fsimd-cost-model= handling ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug libgomp/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org @ 2021-10-15 20:10 ` seurer at gcc dot gnu.org 2021-10-18 6:29 ` [Bug libgomp/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 " rguenth at gcc dot gnu.org ` (14 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: seurer at gcc dot gnu.org @ 2021-10-15 20:10 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 seurer at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Target| |powerpc64-linux-gnu Host| |powerpc64-linux-gnu Build| |powerpc64-linux-gnu --- Comment #1 from seurer at gcc dot gnu.org --- Oh, seen on a power 7 BE host. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug libgomp/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org 2021-10-15 20:10 ` [Bug libgomp/102789] " seurer at gcc dot gnu.org @ 2021-10-18 6:29 ` rguenth at gcc dot gnu.org 2021-10-18 10:05 ` [Bug target/102789] " jakub at gcc dot gnu.org ` (13 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: rguenth at gcc dot gnu.org @ 2021-10-18 6:29 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |12.0 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org 2021-10-15 20:10 ` [Bug libgomp/102789] " seurer at gcc dot gnu.org 2021-10-18 6:29 ` [Bug libgomp/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 " rguenth at gcc dot gnu.org @ 2021-10-18 10:05 ` jakub at gcc dot gnu.org 2021-10-18 10:20 ` jakub at gcc dot gnu.org ` (12 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu.org @ 2021-10-18 10:05 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Component|libgomp |target Status|UNCONFIRMED |NEW Last reconfirmed| |2021-10-18 CC| |dje at gcc dot gnu.org, | |segher at gcc dot gnu.org --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Ok, I can reproduce, but only with -mcpu=power7. The cost model patch just uncovered a latent power7 vectorization bug (backend or vectorizer) I'd say. I've instrumented the testcase a little bit: // { dg-do run } // { dg-additional-options "-msse2" { target sse2_runtime } } // { dg-additional-options "-mavx" { target avx_runtime } } extern "C" void abort (); int a[1024] __attribute__((aligned (32))) = { 1 }; int b[1024] __attribute__((aligned (32))) = { 1 }; unsigned char c[1024] __attribute__((aligned (32))) = { 1 }; int k, m; __UINTPTR_TYPE__ u, u2, u3; __attribute__((noinline, noclone)) int foo (int *p) { int i, s = 0, s2 = 0, t, t2; #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \ lastprivate (t2) for (i = 0; i < 512; i++) { a[i] *= p[i]; t2 = k + p[i]; k += m + 1; s += p[i] + k; c[i]++; } #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \ lastprivate (t, u, u2, u3) for (i = 512; i < 1024; i++) { a[i] *= p[i]; k += m + 1; t = k + p[i]; u = (__UINTPTR_TYPE__) &k; u2 = (__UINTPTR_TYPE__) &s2; u3 = (__UINTPTR_TYPE__) &t; s2 += t; c[i]++; } __builtin_printf ("foo %d %d %d %d\n", s, s2, t, t2); return s + s2 + t + t2; } __attribute__((noinline, noclone)) long int bar (int *p, long int n, long int o) { long int i, s = 0, s2 = 0, t, t2; #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \ lastprivate (t2) for (i = 0; i < n; i++) { a[i] *= p[i]; t2 = k + p[i]; k += m + 1; s += p[i] + k; c[i]++; } #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \ lastprivate (t, u, u2, u3) for (i = n; i < o; i++) { a[i] *= p[i]; k += m + 1; t = k + p[i]; u = (__UINTPTR_TYPE__) &k; u2 = (__UINTPTR_TYPE__) &s2; u3 = (__UINTPTR_TYPE__) &t; s2 += t; c[i]++; } __builtin_printf ("bar %d %d %d %d\n", s, s2, t, t2); return s + s2 + t + t2; } int main () { #if __SIZEOF_INT__ >= 4 int i; k = 4; m = 2; for (i = 0; i < 1024; i++) { a[i] = i - 512; b[i] = (i - 51) % 39; c[i] = (unsigned char) i; } int s = foo (b); for (i = 0; i < 1024; i++) { if (b[i] != (i - 51) % 39 || a[i] != (i - 512) * b[i] || c[i] != (unsigned char) (i + 1)) { __builtin_printf ("#1 %d %d %d %d\n", i, b[i], a[i], c[i]); abort (); } a[i] = i - 512; } if (k != 4 + 3 * 1024 || s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023])) { __builtin_printf ("#2 %d %d\n", k, s); abort (); } k = 4; s = bar (b, 512, 1024); for (i = 0; i < 1024; i++) { if (b[i] != (i - 51) % 39 || a[i] != (i - 512) * b[i] || c[i] != (unsigned char) (i + 2)) { __builtin_printf ("#3 %d %d %d %d\n", i, b[i], a[i], c[i]); abort (); } a[i] = i - 512; } if (k != 4 + 3 * 1024 || s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023])) { __builtin_printf ("#4 %d %d\n", k, s); abort (); } k = 4; s = bar (b, 511, 1021); for (i = 0; i < 1021; i++) { if (b[i] != (i - 51) % 39 || a[i] != (i - 512) * b[i] || c[i] != (unsigned char) (i + 3)) { __builtin_printf ("#5 %d %d %d %d\n", i, b[i], a[i], c[i]); abort (); } a[i] = i - 512; } for (i = 1021; i < 1024; i++) if (b[i] != (i - 51) % 39 || a[i] != i - 512 || c[i] != (unsigned char) (i + 2)) { __builtin_printf ("#6 %d %d %d %d\n", i, b[i], a[i], c[i]); abort (); } if (k != 4 + 3 * 1021 || s != 1586803 + (4 + 3 * 510 + b[510]) + (4 + 3 * 1021 + b[1020])) { __builtin_printf ("#7 %d %d %d %d\n", k, s, b[510], b[1020]); abort (); } #endif return 0; } When compiled with -O2 -m32 -fopenmp -mcpu=power6, this prints: foo 403860 1192267 3112 1568 bar 403860 1192267 3112 1568 bar 402289 1184514 3100 1564 while with -O2 -m32 -fopenmp -mcpu=power7 it prints: foo 403860 1192267 3112 1568 bar 403860 1192267 3112 1568 bar 402289 919217 3100 1564 #7 3067 1326170 30 33 Aborted which seems to suggest it is the: #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \ lastprivate (t, u, u2, u3) for (i = n; i < o; i++) { a[i] *= p[i]; k += m + 1; t = k + p[i]; u = (__UINTPTR_TYPE__) &k; u2 = (__UINTPTR_TYPE__) &s2; u3 = (__UINTPTR_TYPE__) &t; s2 += t; c[i]++; } loop that is miscompiled and miscomputes s2. Now, the loop is invoked twice, once with n = 512 and o = 1024 and in that case it works fine, and then with n = 511 and o = 1021 and in that case it misbehaves, so I bet it must be related to the prologue or epilogue loops. Now, if I compile with -O2 -m32 -fopenmp -mcpu=power7 -fvect-cost-model=unlimited -fsimd-cost-model=unlimited, it is miscompiled the same way already in r9-1520-g42c5d1212ff6544be1061d488aa7ebee9463c375 (haven't bisected fully), but certainly r5-370-ged15c5984e10f6556dffdf397accff804bf60a7c through r9-1052-gfa725532c41ae543fd0078263ea348aa5af3997d have been ICEing on it instead: simd-3.C: In function ‘long int bar(int*, long int, long int)’: simd-3.C:44:1: internal compiler error: in vect_get_store_cost, at tree-vect-stmts.c:1123 bar (int *p, long int n, long int o) ^~~ 0x1510f87 vect_get_store_cost(_stmt_vec_info*, int, unsigned int*, vec<stmt_info_for_cost, va_heap, vl_ptr>*) ../../gcc/tree-vect-stmts.c:1123 0x1510da0 vect_model_store_cost ../../gcc/tree-vect-stmts.c:1057 0x152200b vectorizable_store ../../gcc/tree-vect-stmts.c:6396 0x152cbf2 vect_analyze_stmt(gimple*, bool*, _slp_tree*, _slp_instance*, vec<stmt_info_for_cost, va_heap, vl_ptr>*) ../../gcc/tree-vect-stmts.c:9550 0x153a01f vect_analyze_loop_operations ../../gcc/tree-vect-loop.c:1655 0x153ad28 vect_analyze_loop_2 ../../gcc/tree-vect-loop.c:2050 0x153bd78 vect_analyze_loop(loop*, _loop_vec_info*) ../../gcc/tree-vect-loop.c:2343 0x157062a vectorize_loops() ../../gcc/tree-vectorizer.c:758 0x14196b5 execute ../../gcc/tree-ssa-loop.c:414 Note, r5-370 would ICE with it even with just -O3 -fopenmp -m32 -mcpu=power7 or -O2 -fopenmp -m32 -mcpu=power7 -fvect-cost-model=unlimited. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (2 preceding siblings ...) 2021-10-18 10:05 ` [Bug target/102789] " jakub at gcc dot gnu.org @ 2021-10-18 10:20 ` jakub at gcc dot gnu.org 2021-10-19 6:51 ` linkw at gcc dot gnu.org ` (11 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu.org @ 2021-10-18 10:20 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- On the trunk, -O2 -fopenmp -mcpu=power6 -maltivec -m32 works fine, while -O2 -fopenmp -mcpu=power6 -mvsx -m32 is miscompiled too. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (3 preceding siblings ...) 2021-10-18 10:20 ` jakub at gcc dot gnu.org @ 2021-10-19 6:51 ` linkw at gcc dot gnu.org 2021-10-20 6:24 ` linkw at gcc dot gnu.org ` (10 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: linkw at gcc dot gnu.org @ 2021-10-19 6:51 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Kewen Lin <linkw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org CC| |linkw at gcc dot gnu.org --- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> --- I'll have a look first. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (4 preceding siblings ...) 2021-10-19 6:51 ` linkw at gcc dot gnu.org @ 2021-10-20 6:24 ` linkw at gcc dot gnu.org 2021-10-25 3:08 ` linkw at gcc dot gnu.org ` (9 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: linkw at gcc dot gnu.org @ 2021-10-20 6:24 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Kewen Lin <linkw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bergner at gcc dot gnu.org, | |rguenth at gcc dot gnu.org, | |wschmidt at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> --- As Jakub noted, r12-4340 just exposed one latent bug, even without r12-4340 but with -fvect-cost-model=dynamic, the issue still exists. The key is if it will do the peeling for alignment in prologue. unsigned max_allowed_peel = param_vect_max_peeling_for_alignment; if (flag_vect_cost_model <= VECT_COST_MODEL_CHEAP) max_allowed_peel = 0; --param vect-max-peeling-for-alignment=14 make the peeling disabled and it passes. I think this is a bug in vectorizer, reduced the culprit loop to (also move the first loop out of function): for (i = n; i < o; i++) { k += m + 1; t = k + p[i]; s2 += t; c[i]++; } we have some temporary storages for the omp clause such as: int D.3802[16]; // for k int D.3800[16]; // for s2 int D.3799[16]; // for t After having the peeling (one prologue), the addresses of k,s2,t become to: _187 = prolog_loop_niters.27_88 * 4; vectp.37_186 = &D.3802 + _187; _213 = prolog_loop_niters.27_88 * 4; vectp.46_212 = &D.3799 + _213; _222 = prolog_loop_niters.27_88 * 4; vectp.48_221 = &D.3800 + _222; then the main vectorized loop body acts on the biased addresses which is wrong: vect__61.49_223 = MEM <vector(4) int> [(int *)vectp.48_221]; vectp.48_224 = vectp.48_221 + 16; vect__61.50_225 = MEM <vector(4) int> [(int *)vectp.48_224]; vectp.48_226 = vectp.48_221 + 32; vect__61.51_227 = MEM <vector(4) int> [(int *)vectp.48_226]; vectp.48_228 = vectp.48_221 + 48; vect__61.52_229 = MEM <vector(4) int> [(int *)vectp.48_228]; _61 = D.3800[_56]; vect__62.53_230 = vect__59.44_208 + vect__61.49_223; vect__62.53_231 = vect__59.44_209 + vect__61.50_225; vect__62.53_232 = vect__59.44_210 + vect__61.51_227; vect__62.53_233 = vect__59.44_211 + vect__61.52_229; _62 = _59 + _61; MEM <vector(4) int> [(int *)vectp.55_234] = vect__62.53_230; vectp.55_237 = vectp.55_234 + 16; MEM <vector(4) int> [(int *)vectp.55_237] = vect__62.53_231; vectp.55_239 = vectp.55_234 + 32; MEM <vector(4) int> [(int *)vectp.55_239] = vect__62.53_232; vectp.55_241 = vectp.55_234 + 48; MEM <vector(4) int> [(int *)vectp.55_241] = vect__62.53_233; A fix looks to avoid the address biasing for these kinds of DRs for omp clause specific storage. These DRs are mainly used in the main loop (lanes?), for this case it's for reduction, in prologues we use element 0, in epilogue we use the last one or reduc_op all elements according to the type. The below small fix can make it pass: diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c index 4988c93fdb6..a447f457f93 100644 --- a/gcc/tree-vect-loop-manip.c +++ b/gcc/tree-vect-loop-manip.c @@ -1820,7 +1820,7 @@ vect_update_inits_of_drs (loop_vec_info loop_vinfo, tree niters, FOR_EACH_VEC_ELT (datarefs, i, dr) { dr_vec_info *dr_info = loop_vinfo->lookup_dr (dr); - if (!STMT_VINFO_GATHER_SCATTER_P (dr_info->stmt)) + if (!STMT_VINFO_GATHER_SCATTER_P (dr_info->stmt) && !STMT_VINFO_SIMD_LANE_ACCESS_P (dr_info->stmt)) vect_update_init_of_dr (dr_info, niters, code); } } I've not looked into the meaning for different values (1,2,3,4) for STMT_VINFO_SIMD_LANE_ACCESS_P (stmt_info), it seems for the different omp clauses? The assumption of the above fix is that for all cases of STMT_VINFO_SIMD_LANE_ACCESS_P > 0, the related DR would be used mainly in vectorized loop body, we don't need any updates for it in prologue. I'm going to do one broader testing to see if we need more restrictions on that. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (5 preceding siblings ...) 2021-10-20 6:24 ` linkw at gcc dot gnu.org @ 2021-10-25 3:08 ` linkw at gcc dot gnu.org 2021-10-26 3:18 ` cvs-commit at gcc dot gnu.org ` (8 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: linkw at gcc dot gnu.org @ 2021-10-25 3:08 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> --- The proposed patch was tested and just posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582453.html. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (6 preceding siblings ...) 2021-10-25 3:08 ` linkw at gcc dot gnu.org @ 2021-10-26 3:18 ` cvs-commit at gcc dot gnu.org 2021-10-26 3:21 ` [Bug tree-optimization/102789] " linkw at gcc dot gnu.org ` (7 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2021-10-26 3:18 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>: https://gcc.gnu.org/g:f3dbd3f36d55178d0a9e4431043cbc950524969a commit r12-4697-gf3dbd3f36d55178d0a9e4431043cbc950524969a Author: Kewen Lin <linkw@linux.ibm.com> Date: Mon Oct 25 21:05:02 2021 -0500 vect: Don't update inits for simd_lane_access DRs [PR102789] As PR102789 shows, when vectorizer does some peelings for alignment in prologues, function vect_update_inits_of_drs would update the inits of some drs. But as the failed case, we shouldn't update the dr for simd_lane_access, it has the fixed-length storage mainly for the main loop, the update can make the access out of bound and access the unexpected element. gcc/ChangeLog: PR tree-optimization/102789 * tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not update inits of simd_lane_access. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug tree-optimization/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (7 preceding siblings ...) 2021-10-26 3:18 ` cvs-commit at gcc dot gnu.org @ 2021-10-26 3:21 ` linkw at gcc dot gnu.org 2021-10-26 3:28 ` linkw at gcc dot gnu.org ` (6 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: linkw at gcc dot gnu.org @ 2021-10-26 3:21 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Kewen Lin <linkw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|target |tree-optimization Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> --- Thanks Jakub for the review, this should be fixed on latest trunk. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug tree-optimization/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (8 preceding siblings ...) 2021-10-26 3:21 ` [Bug tree-optimization/102789] " linkw at gcc dot gnu.org @ 2021-10-26 3:28 ` linkw at gcc dot gnu.org 2021-11-05 13:57 ` [Bug tree-optimization/102789] " rguenth at gcc dot gnu.org ` (5 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: linkw at gcc dot gnu.org @ 2021-10-26 3:28 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Kewen Lin <linkw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> --- Oops, forgot to ask that whether we want this backport? ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (9 preceding siblings ...) 2021-10-26 3:28 ` linkw at gcc dot gnu.org @ 2021-11-05 13:57 ` rguenth at gcc dot gnu.org 2021-11-05 14:00 ` jakub at gcc dot gnu.org ` (4 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: rguenth at gcc dot gnu.org @ 2021-11-05 13:57 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Known to work| |12.0 Target Milestone|12.0 |--- Summary|[12 regression] |libgomp.c++/simd-3.C fails |libgomp.c++/simd-3.C fails |after r12-4340 for 32 bits |after r12-4340 for 32 bits | --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> --- If older releases are affected then yes. Not a 12 regression anymore. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (10 preceding siblings ...) 2021-11-05 13:57 ` [Bug tree-optimization/102789] " rguenth at gcc dot gnu.org @ 2021-11-05 14:00 ` jakub at gcc dot gnu.org 2021-11-08 5:31 ` cvs-commit at gcc dot gnu.org ` (3 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: jakub at gcc dot gnu.org @ 2021-11-05 14:00 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Kewen Lin from comment #9) > Oops, forgot to ask that whether we want this backport? Yes, please. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (11 preceding siblings ...) 2021-11-05 14:00 ` jakub at gcc dot gnu.org @ 2021-11-08 5:31 ` cvs-commit at gcc dot gnu.org 2021-11-08 5:33 ` cvs-commit at gcc dot gnu.org ` (2 subsequent siblings) 15 siblings, 0 replies; 17+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2021-11-08 5:31 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-9 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>: https://gcc.gnu.org/g:6cce26752d8431a1ef6d3f9a97fa0ee2e9f96816 commit r9-9815-g6cce26752d8431a1ef6d3f9a97fa0ee2e9f96816 Author: Kewen Lin <linkw@linux.ibm.com> Date: Mon Oct 25 21:05:02 2021 -0500 vect: Don't update inits for simd_lane_access DRs [PR102789] As PR102789 shows, when vectorizer does some peelings for alignment in prologues, function vect_update_inits_of_drs would update the inits of some drs. But as the failed case, we shouldn't update the dr for simd_lane_access, it has the fixed-length storage mainly for the main loop, the update can make the access out of bound and access the unexpected element. gcc/ChangeLog: PR tree-optimization/102789 * tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not update inits of simd_lane_access. (cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a) ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (12 preceding siblings ...) 2021-11-08 5:31 ` cvs-commit at gcc dot gnu.org @ 2021-11-08 5:33 ` cvs-commit at gcc dot gnu.org 2021-11-08 5:34 ` cvs-commit at gcc dot gnu.org 2021-11-08 5:36 ` linkw at gcc dot gnu.org 15 siblings, 0 replies; 17+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2021-11-08 5:33 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-10 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>: https://gcc.gnu.org/g:4f024c99a05f1c6852d1e5daad4a172f4cdd24a1 commit r10-10257-g4f024c99a05f1c6852d1e5daad4a172f4cdd24a1 Author: Kewen Lin <linkw@linux.ibm.com> Date: Mon Oct 25 21:05:02 2021 -0500 vect: Don't update inits for simd_lane_access DRs [PR102789] As PR102789 shows, when vectorizer does some peelings for alignment in prologues, function vect_update_inits_of_drs would update the inits of some drs. But as the failed case, we shouldn't update the dr for simd_lane_access, it has the fixed-length storage mainly for the main loop, the update can make the access out of bound and access the unexpected element. gcc/ChangeLog: PR tree-optimization/102789 * tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not update inits of simd_lane_access. (cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a) ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (13 preceding siblings ...) 2021-11-08 5:33 ` cvs-commit at gcc dot gnu.org @ 2021-11-08 5:34 ` cvs-commit at gcc dot gnu.org 2021-11-08 5:36 ` linkw at gcc dot gnu.org 15 siblings, 0 replies; 17+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2021-11-08 5:34 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-11 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>: https://gcc.gnu.org/g:7cb3b868f702e63e53ee1880c6b8a61676144395 commit r11-9219-g7cb3b868f702e63e53ee1880c6b8a61676144395 Author: Kewen Lin <linkw@linux.ibm.com> Date: Mon Oct 25 21:05:02 2021 -0500 vect: Don't update inits for simd_lane_access DRs [PR102789] As PR102789 shows, when vectorizer does some peelings for alignment in prologues, function vect_update_inits_of_drs would update the inits of some drs. But as the failed case, we shouldn't update the dr for simd_lane_access, it has the fixed-length storage mainly for the main loop, the update can make the access out of bound and access the unexpected element. gcc/ChangeLog: PR tree-optimization/102789 * tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not update inits of simd_lane_access. (cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a) ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org ` (14 preceding siblings ...) 2021-11-08 5:34 ` cvs-commit at gcc dot gnu.org @ 2021-11-08 5:36 ` linkw at gcc dot gnu.org 15 siblings, 0 replies; 17+ messages in thread From: linkw at gcc dot gnu.org @ 2021-11-08 5:36 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Kewen Lin <linkw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|REOPENED |RESOLVED --- Comment #15 from Kewen Lin <linkw at gcc dot gnu.org> --- Thanks for both replies! Backported and bootstrapped on active branches 9/10/11. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-11-08 5:36 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-15 20:09 [Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits seurer at gcc dot gnu.org 2021-10-15 20:10 ` [Bug libgomp/102789] " seurer at gcc dot gnu.org 2021-10-18 6:29 ` [Bug libgomp/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 " rguenth at gcc dot gnu.org 2021-10-18 10:05 ` [Bug target/102789] " jakub at gcc dot gnu.org 2021-10-18 10:20 ` jakub at gcc dot gnu.org 2021-10-19 6:51 ` linkw at gcc dot gnu.org 2021-10-20 6:24 ` linkw at gcc dot gnu.org 2021-10-25 3:08 ` linkw at gcc dot gnu.org 2021-10-26 3:18 ` cvs-commit at gcc dot gnu.org 2021-10-26 3:21 ` [Bug tree-optimization/102789] " linkw at gcc dot gnu.org 2021-10-26 3:28 ` linkw at gcc dot gnu.org 2021-11-05 13:57 ` [Bug tree-optimization/102789] " rguenth at gcc dot gnu.org 2021-11-05 14:00 ` jakub at gcc dot gnu.org 2021-11-08 5:31 ` cvs-commit at gcc dot gnu.org 2021-11-08 5:33 ` cvs-commit at gcc dot gnu.org 2021-11-08 5:34 ` cvs-commit at gcc dot gnu.org 2021-11-08 5:36 ` linkw at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).