[Bug c/106981] New: [OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma acc atomic capture'

[Bug c/106981] New: [OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma acc atomic capture'

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

            Bug ID: 106981
           Summary: [OpenMP] ICE in decompose, at wide-int.h:984 with
                    '#pragma acc atomic capture'
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, openacc
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: tschwinge at gcc dot gnu.org, vries at gcc dot gnu.org
  Target Milestone: ---

This is reduced from an OpenACC testsuite.

I am not quite sure whether it is valid or not; I now bluntly claim:
  ice-on-valid-code for C
  rejects-valid for C++
however, it might well be also an ICE on invalid, I have not checked ...
In any case:

With g++, it fails with:

input5.i:6:44: error: invalid form of ‘#pragma omp atomic’ before ‘(’ token
    6 |       c[x] = totals[x%((int)(n/10 + 1))] = (a[x] + b[x]) +
totals[x%((int) n/10 + 1)];


But with the C compiler, it has an ICE, unless 'long long n' has been changed
to 'int':


long long n = 100;

void test1(int x, double *a, double *b, double *c, double *totals)
{
#pragma acc atomic capture
      c[x] = totals[x%((int)(n/10 + 1))] = (a[x] + b[x]) + totals[x%((int) n/10
+ 1)];
}


The ICE is:
--------------------------
input5.i:6:7: internal compiler error: in decompose, at wide-int.h:984
    6 |       c[x] = totals[x%((int)(n/10 + 1))] = (a[x] + b[x]) +
totals[x%((int) n/10 + 1)];
      |       ^
0x67f840 wi::int_traits<generic_wide_int<wide_int_ref_storage<false, false> >
>::decompose(long*, unsigned int, generic_wide_int<wide_int_ref_storage<false,
false> > const&)
        ../../repos/gcc/gcc/wide-int.h:984

[Bug c/106981] [OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
            Summary|[OpenACC] ICE in decompose, |[OpenACC][OpenMP] ICE in
                   |at wide-int.h:984 with      |decompose, at
                   |'#pragma acc atomic         |wide-int.h:984 with
                   |capture'                    |'#pragma omp/acc atomic
                   |                            |capture'
           Keywords|                            |openmp

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
It actually fails in the same way with "-fopenmp" and 'acc' replaced by 'omp':

long long n = 100;
void test1(int x, double *a, double *b, double *c, double *totals)
{
#pragma omp atomic capture
      c[x] = totals[x%((int)(n/10 + 1))] = (a[x] + b[x]) + totals[x%((int) n/10
+ 1)];
}


I also missed to include the invoking part of the of stacktrace:

...
0x9848a2 c_tree_equal(tree_node*, tree_node*)
        ../../repos/gcc/gcc/c/c-typeck.cc:16197
0x9b3fd9 c_parser_binary_expression
        ../../repos/gcc/gcc/c/c-parser.cc:8085
0x9b40de c_parser_conditional_expression
        ../../repos/gcc/gcc/c/c-parser.cc:7653
0x9b49f6 c_parser_expr_no_commas
        ../../repos/gcc/gcc/c/c-parser.cc:7567
0x9c4189 c_parser_omp_atomic
        ../../repos/gcc/gcc/c/c-parser.cc:18992
0x9d7bcf c_parser_omp_construct
        ../../repos/gcc/gcc/c/c-parser.cc:23309
0x9acb3c c_parser_pragma
        ../../repos/gcc/gcc/c/c-parser.cc:12700
0x9cddff c_parser_compound_statement_nostart
        ../../repos/gcc/gcc/c/c-parser.cc:5800

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.5

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |ice-on-invalid-code

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Fails in

c_parser_binary_expression's POP  for the second c_type_equal, which is
probably:

    stack[sp].expr                                                            \
      = convert_lvalue_to_rvalue (stack[sp].loc,                              \
                                  stack[sp].expr, true, true);                \

there:

c_tree_equal (t1=0x7ffff710dce0, t2=0x7ffff710dba0) at
../../repos/gcc-trunk-commit/gcc/c/c-typeck.cc:16039

(gdb) p debug((tree)0x7ffff710dce0)
*(totals + (sizetype) ((long unsigned int) (x % ((int) n / 10 + 1)) * 8))

(gdb) p debug((tree)0x7ffff710dba0)
*(totals + (sizetype) ((long unsigned int) (x % (int) ((unsigned int) (n / 10)
+ 1)) * 8))

where 'n' is 'long long' and 'x' and the digits are 'int' - the expr right of
'%' differs in terms of casts.


The ICE can be prevented with:
------------------------
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -16216,6 +16216,9 @@ c_tree_equal (tree t1, tree t2)
            && n != TREE_OPERAND_LENGTH (t2))
          return false;

+       if (n >= TREE_OPERAND_LENGTH (t2))
+         return false;
+
        for (i = 0; i < n; ++i)
          if (!c_tree_equal (TREE_OPERAND (t1, i), TREE_OPERAND (t2, i)))
            return false;

------------------------


With this patch, the code fails – but C++ and C have different messages.

* gcc – points to tailing ';':
input5.i:7:86: error: invalid form of ‘#pragma omp atomic’ before ‘;’ token
    7 |       c[x] = totals[x%((int)(n/10 + 1))] = (a[x] + b[x]) +
totals[x%((int) n/10 + 1)];
      |                                                                        
             ^


* g++ - points to '(' in '... = (a[x ...':
input5.i:7:44: error: invalid form of ‘#pragma omp atomic’ before ‘(’ token
    7 |       c[x] = totals[x%((int)(n/10 + 1))] = (a[x] + b[x]) +
totals[x%((int) n/10 + 1)];
      |                                            ^


**************

Open... specification view. The expression is in the source code:
 __v_ = __x________________________ = ____expr_____ +
________x'________________
 c[x] = totals[x%((int)(n/10 + 1))] = (a[x] + b[x]) + totals[x%((int) n/10 +
1)];

and, obviously, x != x' due to the cast differences.

Looking at the OpenACC 3.2 spec, he last expr fits, except that x != x':
---------
If the atomic-clause is capture:
  v = x++;
  v = x--;
  v = ++x;
  v = --x;
  v = x binop= expr;
  v = x = x binop expr;
  v = x = expr binop x;
---------

Likewise in OpenMP 5.2:
---------
An update-atomic structured block is update-expr-stmt, an update expression
statement that has one of the following forms:
...
x = x binop expr;
x = expr binop x;

...
A capture-atomic structured block is capture-stmt, a capture statement that
has one of the following forms:
v = expr-stmt
...
---------

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yes, this is certainly not valid OpenMP, if in the syntax x or expr or r
appears multiple times, then each occurence needs to be the exact same set of
tokens and
due to the
"During the execution of an atomic region, multiple syntactic occurrences of
{x,expr,r} must designate the same storage location."
restrictions must be the same thing at runtime too.

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Obviously, my ICE-preventing patch (→ comment 2) does not work well as it now
rejects the following, which looks fine:

error: invalid form of ‘#pragma omp atomic’ before ‘;’ token
   66 |                      b[x] = totals[x%(n/10 + 1)] = a[x] &
totals[x%(n/10 + 1)];

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Slightly more reduced:
void
foo (int a, double *b, double *c, double *d, long long e)
{
#pragma omp atomic capture
  c[a] = d[((int) (e / 10 + 1))] = b[a] + d[((int) e / 10 + 1)];
}
The fix could be either partially backport what C++ FE did in
--- gcc/c/c-typeck.cc.jj        2022-09-23 09:02:56.525318361 +0200
+++ gcc/c/c-typeck.cc   2022-09-23 10:33:06.596467788 +0200
@@ -16069,6 +16069,9 @@ c_tree_equal (tree t1, tree t2)
   if (code1 != code2)
     return false;

+  if (CONSTANT_CLASS_P (t1) && !comptypes (TREE_TYPE (t1), TREE_TYPE (t2)))
+    return false;
+
   switch (code1)
     {
     case INTEGER_CST:
Or we could
--- gcc/c/c-typeck.cc.jj        2022-09-23 09:02:56.525318361 +0200
+++ gcc/c/c-typeck.cc   2022-09-23 10:33:06.596467788 +0200
@@ -16072,7 +16070,7 @@ c_tree_equal (tree t1, tree t2)
   switch (code1)
     {
     case INTEGER_CST:
-      return wi::to_wide (t1) == wi::to_wide (t2);
+      return wi::to_widest (t1) == wi::to_widest (t2);

     case REAL_CST:
       return real_equal (&TREE_REAL_CST (t1), &TREE_REAL_CST (t2));
but then it is accepted instead of rejected unlike C++.
I'm afraid even the
  for (code1 = TREE_CODE (t1);
       CONVERT_EXPR_CODE_P (code1)
         || code1 == NON_LVALUE_EXPR;
       code1 = TREE_CODE (t1))
    t1 = TREE_OPERAND (t1, 0);
  for (code2 = TREE_CODE (t2);
       CONVERT_EXPR_CODE_P (code2)
         || code2 == NON_LVALUE_EXPR;
       code2 = TREE_CODE (t2))
    t2 = TREE_OPERAND (t2, 0);
stuff is dangerous, I guess one could construct a valid OpenMP testcase like:
void
bar (int *a)
{
  unsigned int b = 0x100;
  #pragma omp atomic update
  a[(unsigned char) b] = a[(unsigned short) b] + a[(unsigned char) b];
  #pragma omp atomic update
  a[(unsigned char) b] = a[(unsigned char) b] + a[(unsigned short) b];
}
where for C++ I think we do the right thing in both cases, atomic increment of
a[0] by a[0x100], but in C we do atomic increment of a[0] by a[0] in the first
case.  Now, wonder what will break if I just strip same type casts and for
others like in C++ require same type.

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)

> The fix could be either partially backport what C++ FE did in
> --- gcc/c/c-typeck.cc.jj	2022-09-23 09:02:56.525318361 +0200
> +++ gcc/c/c-typeck.cc	2022-09-23 10:33:06.596467788 +0200

> +  if (CONSTANT_CLASS_P (t1) && !comptypes (TREE_TYPE (t1), TREE_TYPE (t2)))
> +    return false;

Maybe. Though I think we still need something like my:

+       if (n > TREE_OPERAND_LENGTH (t2))
+         return false;

(With ">" not ">=" as I accidentally had.)
Given that 
          if (!c_tree_equal (TREE_OPERAND (t1, i), TREE_OPERAND (t2, i)))
does not make sense when exceeding the operand length!

Nonetheless, ...

> Now, wonder what will break if I just strip same type casts and
> for others like in C++ require same type.

sounds like a reasonable approach,.

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> 
> > The fix could be either partially backport what C++ FE did in
> > --- gcc/c/c-typeck.cc.jj	2022-09-23 09:02:56.525318361 +0200
> > +++ gcc/c/c-typeck.cc	2022-09-23 10:33:06.596467788 +0200
> 
> > +  if (CONSTANT_CLASS_P (t1) && !comptypes (TREE_TYPE (t1), TREE_TYPE (t2)))
> > +    return false;
> 
> Maybe. Though I think we still need something like my:
> 
> +	if (n > TREE_OPERAND_LENGTH (t2))
> +	  return false;
> 
> (With ">" not ">=" as I accidentally had.)
> Given that 
>  	  if (!c_tree_equal (TREE_OPERAND (t1, i), TREE_OPERAND (t2, i)))
> does not make sense when exceeding the operand length!

I don't understand.
We have there:
        int i, n = TREE_OPERAND_LENGTH (t1);

        switch (code1)
          {
          case PREINCREMENT_EXPR:
          case PREDECREMENT_EXPR:
          case POSTINCREMENT_EXPR:
          case POSTDECREMENT_EXPR:
            n = 1;
            break;
          case ARRAY_REF:
            n = 2;
            break;
          default:
            break;
          }

        if (TREE_CODE_CLASS (code1) == tcc_vl_exp
            && n != TREE_OPERAND_LENGTH (t2))
          return false;
and know that code1 == code2.  So, except for tcc_vl_exp like CALL_EXPR,
TREE_OPERAND_LENGTH (t1) == TREE_OPERAND_LENGTH (t2) and n is in most
cases equal to that too, except for the pre/post in/decrements (which have
length 2) and ARRAY_REF which has length 4 and we use a smaller number.

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2022-09-23
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53616&action=edit
gcc13-pr106981.patch

Full untested patch (well, tested make check-gcc RUNTESTFLAGS='gomp.exp
goacc.exp' and in libgomp make check RUNTESTFLAGS="c++.exp=pr106981.c
c.exp='pr106981.c *atomic*'").

[Bug c/106981] [10/11/12/13 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3c5bccb608c665ac3f62adb1817c42c845812428

commit r13-2828-g3c5bccb608c665ac3f62adb1817c42c845812428
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Sep 24 09:19:26 2022 +0200

    openmp, c: Tighten up c_tree_equal [PR106981]

    This patch changes c_tree_equal to work more like cp_tree_equal, be
    more strict in what it accepts.  The ICE on the first testcase was
    due to INTEGER_CST wi::wide (t1) == wi::wide (t2) comparison which
    ICEs if the two constants have different precision, but as the second
    testcase shows, being too lenient in it can also lead to miscompilation
    of valid OpenMP programs where we think certain expression is the same
    even when it isn't and can be guaranteed at runtime to represent different
    memory location.  So, the patch looks through only NON_LVALUE_EXPRs
    and for constants as well as casts requires that the types match before
    actually comparing the constant values or recursing on the cast operands.

    2022-09-24  Jakub Jelinek  <jakub@redhat.com>

            PR c/106981
    gcc/c/
            * c-typeck.cc (c_tree_equal): Only strip NON_LVALUE_EXPRs at the
            start.  For CONSTANT_CLASS_P or CASE_CONVERT: return false if t1
and
            t2 have different types.
    gcc/testsuite/
            * c-c++-common/gomp/pr106981.c: New test.
    libgomp/
            * testsuite/libgomp.c-c++-common/pr106981.c: New test.

[Bug c/106981] [10/11/12 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
            Summary|[10/11/12/13                |[10/11/12
                   |Regression][OpenACC][OpenMP |Regression][OpenACC][OpenMP
                   |] ICE in decompose, at      |] ICE in decompose, at
                   |wide-int.h:984 with         |wide-int.h:984 with
                   |'#pragma omp/acc atomic     |'#pragma omp/acc atomic
                   |capture'                    |capture'
      Known to work|                            |13.0

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
I assume it's fixed on trunk.

[Bug c/106981] [10/11/12 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:a46f71c1a5c286b8cc4802fffe235909016cd34f

commit r12-8884-ga46f71c1a5c286b8cc4802fffe235909016cd34f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Sep 24 09:19:26 2022 +0200

    openmp, c: Tighten up c_tree_equal [PR106981]

    This patch changes c_tree_equal to work more like cp_tree_equal, be
    more strict in what it accepts.  The ICE on the first testcase was
    due to INTEGER_CST wi::wide (t1) == wi::wide (t2) comparison which
    ICEs if the two constants have different precision, but as the second
    testcase shows, being too lenient in it can also lead to miscompilation
    of valid OpenMP programs where we think certain expression is the same
    even when it isn't and can be guaranteed at runtime to represent different
    memory location.  So, the patch looks through only NON_LVALUE_EXPRs
    and for constants as well as casts requires that the types match before
    actually comparing the constant values or recursing on the cast operands.

    2022-09-24  Jakub Jelinek  <jakub@redhat.com>

            PR c/106981
    gcc/c/
            * c-typeck.cc (c_tree_equal): Only strip NON_LVALUE_EXPRs at the
            start.  For CONSTANT_CLASS_P or CASE_CONVERT: return false if t1
and
            t2 have different types.
    gcc/testsuite/
            * c-c++-common/gomp/pr106981.c: New test.
    libgomp/
            * testsuite/libgomp.c-c++-common/pr106981.c: New test.

    (cherry picked from commit 3c5bccb608c665ac3f62adb1817c42c845812428)

[Bug c/106981] [10/11/12 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:01b894bc8a59691cc1d8dc29936635c8cfb8aed7

commit r11-10359-g01b894bc8a59691cc1d8dc29936635c8cfb8aed7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Sep 24 09:19:26 2022 +0200

    openmp, c: Tighten up c_tree_equal [PR106981]

    This patch changes c_tree_equal to work more like cp_tree_equal, be
    more strict in what it accepts.  The ICE on the first testcase was
    due to INTEGER_CST wi::wide (t1) == wi::wide (t2) comparison which
    ICEs if the two constants have different precision, but as the second
    testcase shows, being too lenient in it can also lead to miscompilation
    of valid OpenMP programs where we think certain expression is the same
    even when it isn't and can be guaranteed at runtime to represent different
    memory location.  So, the patch looks through only NON_LVALUE_EXPRs
    and for constants as well as casts requires that the types match before
    actually comparing the constant values or recursing on the cast operands.

    2022-09-24  Jakub Jelinek  <jakub@redhat.com>

            PR c/106981
    gcc/c/
            * c-typeck.c (c_tree_equal): Only strip NON_LVALUE_EXPRs at the
            start.  For CONSTANT_CLASS_P or CASE_CONVERT: return false if t1
and
            t2 have different types.
    gcc/testsuite/
            * c-c++-common/gomp/pr106981.c: New test.
    libgomp/
            * testsuite/libgomp.c-c++-common/pr106981.c: New test.

    (cherry picked from commit 3c5bccb608c665ac3f62adb1817c42c845812428)

[Bug c/106981] [10 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11/12                   |[10
                   |Regression][OpenACC][OpenMP |Regression][OpenACC][OpenMP
                   |] ICE in decompose, at      |] ICE in decompose, at
                   |wide-int.h:984 with         |wide-int.h:984 with
                   |'#pragma omp/acc atomic     |'#pragma omp/acc atomic
                   |capture'                    |capture'

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.4+ and 12.3+ too.

[Bug c/106981] [10 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:7cdefaee48af5d203560091bd37aad206df683b9

commit r10-11337-g7cdefaee48af5d203560091bd37aad206df683b9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Sep 24 09:19:26 2022 +0200

    openmp, c: Tighten up c_tree_equal [PR106981]

    This patch changes c_tree_equal to work more like cp_tree_equal, be
    more strict in what it accepts.  The ICE on the first testcase was
    due to INTEGER_CST wi::wide (t1) == wi::wide (t2) comparison which
    ICEs if the two constants have different precision, but as the second
    testcase shows, being too lenient in it can also lead to miscompilation
    of valid OpenMP programs where we think certain expression is the same
    even when it isn't and can be guaranteed at runtime to represent different
    memory location.  So, the patch looks through only NON_LVALUE_EXPRs
    and for constants as well as casts requires that the types match before
    actually comparing the constant values or recursing on the cast operands.

    2022-09-24  Jakub Jelinek  <jakub@redhat.com>

            PR c/106981
    gcc/c/
            * c-typeck.c (c_tree_equal): Only strip NON_LVALUE_EXPRs at the
            start.  For CONSTANT_CLASS_P or CASE_CONVERT: return false if t1
and
            t2 have different types.
    gcc/testsuite/
            * c-c++-common/gomp/pr106981.c: New test.
    libgomp/
            * testsuite/libgomp.c-c++-common/pr106981.c: New test.

    (cherry picked from commit 3c5bccb608c665ac3f62adb1817c42c845812428)

[Bug c/106981] [10 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 10.5 too.