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).