public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/111403] New: LoongArch: Wrong code with -O -mlasx -fopenmp-simd
@ 2023-09-13 10:46 xry111 at gcc dot gnu.org
2023-09-13 10:48 ` [Bug target/111403] " xry111 at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-09-13 10:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403
Bug ID: 111403
Summary: LoongArch: Wrong code with -O -mlasx -fopenmp-simd
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
Testcase:
struct S
{
int s;
S () : s (0) {}
~S () {}
S (const S &x) { s = x.s; }
S &
operator= (const S &x)
{
s = x.s;
return *this;
}
};
S r, a[1024], b[1024];
#pragma omp declare reduction(+ : S : omp_out.s += omp_in.s)
__attribute__ ((noipa)) void
foo (S *a, S *b)
{
#pragma omp simd reduction(inscan, + : r)
for (int i = 0; i < 1024; i++)
{
r.s += a[i].s;
#pragma omp scan inclusive(r)
b[i] = r;
}
}
int
main ()
{
S s;
for (int i = 0; i < 1024; ++i)
{
a[i].s = i;
b[i].s = -1;
}
foo (a, b);
if (r.s != 1024 * 1023 / 2)
__builtin_abort ();
return 0;
}
$ g++ t.cc -O -mlasx -fopenmp-simd
$ ./a.out
Aborted (core dumped)
^ 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 ` 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
end of thread, other threads:[~2024-02-01 6:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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).