* [Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
2023-09-13 10:46 [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd xry111 at gcc dot gnu.org
@ 2023-09-13 10:48 ` xry111 at gcc dot gnu.org
2023-10-08 8:45 ` guojie at loongson dot cn
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-13 10:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
CC| |chenglulu at loongson dot cn,
| |chenxiaolong at loongson dot cn
Target| |loongarch*-*-*
--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
FWIW the test case is reduced from g++.dg/vect/simd-2.cc. And interestingly if
we remove the definition S::operator= the issue no longer happens.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
2023-09-13 10:46 [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd xry111 at gcc dot gnu.org
2023-09-13 10:48 ` [Bug target/111403] " xry111 at gcc dot gnu.org
@ 2023-10-08 8:45 ` guojie at loongson dot cn
2024-01-31 10:44 ` xry111 at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: guojie at loongson dot cn @ 2023-10-08 8:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
Guo Jie <guojie at loongson dot cn> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |guojie at loongson dot cn
--- Comment #2 from Guo Jie <guojie at loongson dot cn> ---
It seems that “omp simd reduction” cannot collaborate well with “loop peeling”,
which will result in a probability error in this test case.
LoongArch tree vect pass dump:
# “omp simd” temporary arrays.
struct S D.3833[8];
struct S D.3832[8];
...
# prologue loop.
<bb 20> [local count: 723433550]:
MEM <struct S[32]> [(struct S *)&D.3832][0].s = 0;
_44 = D.3832[0].s;
_41 = (long unsigned int) i_1;
_58 = _41 * 4;
_59 = a_18(D) + _58;
_60 = _59->s;
_61 = _44 + _60;
D.3832[0].s = _61;
_64 = D.3833[0].s;
_65 = D.3832[0].s;
_66 = _64 + _65;
D.3833[0].s = _66; # Save temporary reduction results.
MEM <struct S[32]> [(struct S *)&D.3832][0].s = _66;
_69 = b_28(D) + _58;
_70 = MEM <struct S[32]> [(const struct S &)&D.3832][0].s;
_69->s = _70;
i_72 = i_1 + 1;
ivtmp_73 = ivtmp_2 - 1;
ivtmp_78 = ivtmp_77 + 1;
if (ivtmp_78 < prolog_loop_niters.42_7)
goto <bb 21>; [85.71%]
else
goto <bb 18>; [14.29%]
<bb 21> [local count: 620085901]:
goto <bb 20>; [100.00%]
# vector body loop.
<bb 5> [local count: 118111599]:
# i_48 = PHI <i_30(12), i_79(22)>
# ivtmp_55 = PHI <ivtmp_45(12), ivtmp_81(22)>
# vectp_a.50_126 = PHI <vectp_a.50_127(12), vectp_a.51_123(22)>
# vectp_b.58_158 = PHI <vectp_b.58_159(12), vectp_b.59_155(22)>
# ivtmp_161 = PHI <ivtmp_162(12), 0(22)>
MEM <vector(8) int> [(struct S *)&D.3832] = { 0, 0, 0, 0, 0, 0, 0, 0 };
_16 = (long unsigned int) i_48;
_17 = _16 * 4;
_19 = a_18(D) + _17;
vect__20.52_128 = MEM <vector(8) int> [(int *)vectp_a.50_126];
_20 = _19->s;
MEM <vector(8) int> [(int *)&D.3832] = vect__20.52_128;
vect__24.54_131 = MEM <vector(8) int> [(int *)&D.3833]; # Wrong value.
...
vect__26.56_133 = vect__20.52_128 + vect__24.54_131;
...
if (ivtmp_162 < bnd.44_109)
goto <bb 12>; [0.00%]
else
goto <bb 25>; [100.00%]
...
The temporary reduction result of “prologue loop” is only stored in D.3833[0],
and all other elements of D.3833 are 0. Therefore, only the first element of
vect__26.56_133 accumulates the scalar reduction result of “prologue loop”.
I think the reasonable solution should be to broadcast the scalar reduction
result of “prologue loop” to all elements of D.3833.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
2023-09-13 10:46 [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd xry111 at gcc dot gnu.org
2023-09-13 10:48 ` [Bug target/111403] " xry111 at gcc dot gnu.org
2023-10-08 8:45 ` guojie at loongson dot cn
@ 2024-01-31 10:44 ` xry111 at gcc dot gnu.org
2024-01-31 16:45 ` xry111 at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: xry111 at gcc dot gnu.org @ 2024-01-31 10:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
--- Comment #3 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
It seems no longer happening with current trunk. Let me do a bisection...
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
2023-09-13 10:46 [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd xry111 at gcc dot gnu.org
` (2 preceding siblings ...)
2024-01-31 10:44 ` xry111 at gcc dot gnu.org
@ 2024-01-31 16:45 ` xry111 at gcc dot gnu.org
2024-01-31 16:48 ` xry111 at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: xry111 at gcc dot gnu.org @ 2024-01-31 16:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
After r14-5545 this issue became latent.
And at some point before r14-5545 this issue became nondeterministic: a
compiled program *sometimes* crashes. Really strange...
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
2023-09-13 10:46 [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd xry111 at gcc dot gnu.org
` (3 preceding siblings ...)
2024-01-31 16:45 ` xry111 at gcc dot gnu.org
@ 2024-01-31 16:48 ` xry111 at gcc dot gnu.org
2024-01-31 17:17 ` schwab@linux-m68k.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: xry111 at gcc dot gnu.org @ 2024-01-31 16:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
--- Comment #5 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #4)
> After r14-5545 this issue became latent.
>
> And at some point before r14-5545 this issue became nondeterministic: a
> compiled program *sometimes* crashes. Really strange...
At r14-5544, if running the compiled program in GDB it *always* crash, but if
directly running it it *sometimes* crash. What's the difference between GDB or
not?!
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
2023-09-13 10:46 [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd xry111 at gcc dot gnu.org
` (4 preceding siblings ...)
2024-01-31 16:48 ` xry111 at gcc dot gnu.org
@ 2024-01-31 17:17 ` schwab@linux-m68k.org
2024-01-31 17:23 ` xry111 at gcc dot gnu.org
2024-02-01 6:17 ` panchenghui at loongson dot cn
7 siblings, 0 replies; 9+ messages in thread
From: schwab@linux-m68k.org @ 2024-01-31 17:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
--- Comment #6 from Andreas Schwab <schwab@linux-m68k.org> ---
GDB disables ASLR.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
2023-09-13 10:46 [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd xry111 at gcc dot gnu.org
` (5 preceding siblings ...)
2024-01-31 17:17 ` schwab@linux-m68k.org
@ 2024-01-31 17:23 ` xry111 at gcc dot gnu.org
2024-02-01 6:17 ` panchenghui at loongson dot cn
7 siblings, 0 replies; 9+ messages in thread
From: xry111 at gcc dot gnu.org @ 2024-01-31 17:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
--- Comment #7 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #6)
> GDB disables ASLR.
Indeed, with "setarch -R" it always crashes.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
2023-09-13 10:46 [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd xry111 at gcc dot gnu.org
` (6 preceding siblings ...)
2024-01-31 17:23 ` xry111 at gcc dot gnu.org
@ 2024-02-01 6:17 ` panchenghui at loongson dot cn
7 siblings, 0 replies; 9+ messages in thread
From: panchenghui at loongson dot cn @ 2024-02-01 6:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
--- Comment #8 from Chenghui Pan <panchenghui at loongson dot cn> ---
(In reply to Xi Ruoyao from comment #4)
> After r14-5545 this issue became latent.
>
> And at some point before r14-5545 this issue became nondeterministic: a
> compiled program *sometimes* crashes. Really strange...
After applying this commit, GCC does not apply loop peeling while processing
the openmp reduction directive, which I think is the spawn point of the
problematic codes (According to Guo Jie's sample).
^ permalink raw reply [flat|nested] 9+ messages in thread