[Bug c/103194] New: ice in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3626

[Bug c/103194] New: ice in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3626

[dcb314 at hotmail dot com]

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

            Bug ID: 103194
           Summary: ice in optimize_atomic_bit_test_and, at
                    tree-ssa-ccp.c:3626
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

long pscc_a_2_3;
int pscc_a_1_4;
void pscc()
{
        pscc_a_1_4 = __sync_fetch_and_and(&pscc_a_2_3, 1);
}

compiled by recent gcc trunk, does this:

$ /home/dcb/gcc/results/bin/gcc -c -O1 bug771.c
during GIMPLE pass: fab
bug771.c: In function ‘pscc’:
bug771.c:3:6: internal compiler error: in optimize_atomic_bit_test_and, at
tree-ssa-ccp.c:3626
    3 | void pscc()
      |      ^~~~
0xee6020 optimize_atomic_bit_test_and(gimple_stmt_iterator*, internal_fn, bool,
bool)
        ../../trunk.git/gcc/tree-ssa-ccp.c:3626
0xee389a (anonymous namespace)::pass_fold_builtins::execute(function*)
        ../../trunk.git/gcc/tree-ssa-ccp.c:0

The bug first seems to occur sometime between git hash f2572a398d21fd52
and a97fdde627e64202,a distance of some 60 commits.

In that range, commit fb161782545224f55ba26ba663889c5e6e9a04d1
looks a likely candidate.

[Bug c/103194] ice in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3626

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
Adding HJ. I hope I have the correct email account.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ice in                      |[12 Regression] ice in
                   |optimize_atomic_bit_test_an |optimize_atomic_bit_test_an
                   |d, at tree-ssa-ccp.c:3626   |d with __sync_fetch_and_and
          Component|c                           |tree-optimization
   Target Milestone|---                         |12.0
           Keywords|                            |ice-on-valid-code
           Severity|normal                      |blocker

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-11-11
     Ever confirmed|0                           |1

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
The narrowing cast isn't handled:

[hjl@gnu-cfl-2 pr102566]$ cat x3.c
#include <stdatomic.h>

int
foo (_Atomic long long int *v)
{
  return atomic_fetch_or_explicit (v, 1, memory_order_relaxed) & 1;
}
[hjl@gnu-cfl-2 pr102566]$ make x3.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -O2 -S
x3.c
[hjl@gnu-cfl-2 pr102566]$ cat x3.s
        .file   "x3.c"
        .text
        .p2align 4
        .globl  foo
        .type   foo, @function
foo:
.LFB0:
        .cfi_startproc
        movq    (%rdi), %rax
.L2:
        movq    %rax, %rcx
        movq    %rax, %rdx
        orq     $1, %rcx
        lock cmpxchgq   %rcx, (%rdi)
        jne     .L2
        movl    %edx, %eax
        andl    $1, %eax
        ret
        .cfi_endproc
.LFE0:
        .size   foo, .-foo
        .ident  "GCC: (GNU) 12.0.0 20211111 (experimental)"
        .section        .note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 pr102566]$

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12 Regression] ice in      |[12 Regression] ice in
                   |optimize_atomic_bit_test_an |optimize_atomic_bit_test_an
                   |d with __sync_fetch_and_and |d with __sync_fetch_and_and
                   |                            |since
                   |                            |r12-5102-gfb161782545224f5
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Really started with r12-5102-gfb161782545224f5.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
This avoids the crash:

diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index 0f79e9f05bd..14c5ecdf119 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -3443,7 +3443,7 @@ optimize_atomic_bit_test_and (gimple_stmt_iterator *gsip,
     ibit = 0;
   }
       else if (TYPE_PRECISION (TREE_TYPE (use_lhs))
-         == TYPE_PRECISION (TREE_TYPE (use_rhs)))
+         <= TYPE_PRECISION (TREE_TYPE (use_rhs)))
   {
     gimple *use_nop_stmt;
     if (!single_imm_use (use_lhs, &use_p, &use_nop_stmt)

But nop_atomic_bit_test_and_p should handle cast.  Hongtao, please take a look.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 51784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51784&action=edit
An incomplete patch

Hongtao, can you finish it?

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #51784|0                           |1
        is obsolete|                            |

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 51785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51785&action=edit
The v2 incomplete patch

Hongtao, please finish it.  Thanks.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #7 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to H.J. Lu from comment #6)
> Created attachment 51785 [details]
> The v2 incomplete patch
> 
> Hongtao, please finish it.  Thanks.

Yes.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #8 from Hongtao.liu <crazylht at gmail dot com> ---
unsigned long pscc_a_2_3;
int pscc_a_1_4;
unsigned long pc2;
void pscc(int n)
{
  long mask = 1ll << n;
  pc2 = __sync_fetch_and_or(&pscc_a_2_3, mask) & mask;
}

void pscc1(int n)
{
  long mask = 1ll << 65;
  pc2 = __sync_fetch_and_or(&pscc_a_2_3, mask) & mask;
}

pscc and pscc1 have different behavior when n >= 64, It seems unsafe to
optimize variable mask?

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #9 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to H.J. Lu from comment #6)
> Created attachment 51785 [details]
> The v2 incomplete patch
> 
> Hongtao, please finish it.  Thanks.

I'm trying to handle narrowing part in match.pd and add else return; when
precision is not equal.

(for bit_op (bit_and bit_xor bit_ior)
 (simplify
  (bit_op (convert@0 @1) (convert@2 @3))
  (if (INTEGRAL_TYPE_P (type)
      && INTEGRAL_TYPE_P (TREE_TYPE (@1))
      && tree_nop_conversion_p (TREE_TYPE (@1), TREE_TYPE (@3))
      && single_use (@0)
      && single_use (@2)
      && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@1)))
   (with { tree type1 = TREE_TYPE (@1); }
    (convert (bit_op @1 (convert:type1 @3)))))))

(for bit_op (bit_and bit_xor bit_ior)
 (simplify
  (bit_op (convert@0 @1) INTEGER_CST@2)
  (if (INTEGRAL_TYPE_P (type)
      && INTEGRAL_TYPE_P (TREE_TYPE (@1))
      && single_use (@0)
      && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@1)))
   (convert (bit_op @1 { fold_convert (TREE_TYPE (@1), @2); })))))

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #10 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #9)
> (In reply to H.J. Lu from comment #6)
> > Created attachment 51785 [details]
> > The v2 incomplete patch
> > 
> > Hongtao, please finish it.  Thanks.
> 
> I'm trying to handle narrowing part in match.pd and add else return; when
> precision is not equal.
> 
> (for bit_op (bit_and bit_xor bit_ior)
>  (simplify
>   (bit_op (convert@0 @1) (convert@2 @3))
>   (if (INTEGRAL_TYPE_P (type)
>       && INTEGRAL_TYPE_P (TREE_TYPE (@1))
>       && tree_nop_conversion_p (TREE_TYPE (@1), TREE_TYPE (@3))
>       && single_use (@0)
>       && single_use (@2)
>       && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@1)))
>    (with { tree type1 = TREE_TYPE (@1); }
>     (convert (bit_op @1 (convert:type1 @3)))))))
> 
> (for bit_op (bit_and bit_xor bit_ior)
>  (simplify
>   (bit_op (convert@0 @1) INTEGER_CST@2)
>   (if (INTEGRAL_TYPE_P (type)
>       && INTEGRAL_TYPE_P (TREE_TYPE (@1))
>       && single_use (@0)
>       && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@1)))
>    (convert (bit_op @1 { fold_convert (TREE_TYPE (@1), @2); })))))

hmm, cause infinite loop because of

      /* Convert (T)(x & c) into (T)x & (T)c, if c is an integer
         constants (if x has signed type, the sign bit cannot be set
         in c).  This folds extension into the BIT_AND_EXPR.
         ??? We don't do it for BOOLEAN_TYPE or ENUMERAL_TYPE because they
         very likely don't have maximal range for their precision and this
         transformation effectively doesn't preserve non-maximal ranges.  */
      if (TREE_CODE (type) == INTEGER_TYPE
          && TREE_CODE (op0) == BIT_AND_EXPR
          && TREE_CODE (TREE_OPERAND (op0, 1)) == INTEGER_CST)

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #9)
> (In reply to H.J. Lu from comment #6)
> > Created attachment 51785 [details]
> > The v2 incomplete patch
> > 
> > Hongtao, please finish it.  Thanks.
> 
> I'm trying to handle narrowing part in match.pd and add else return; when
> precision is not equal.

Right this is related to PR 103228 (and a few others) :).

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #12 from Hongtao.liu <crazylht at gmail dot com> ---

(In reply to Hongtao.liu from comment #9)
> (In reply to H.J. Lu from comment #6)
> > Created attachment 51785 [details]
> > The v2 incomplete patch
> > 
> > Hongtao, please finish it.  Thanks.
> 
> I'm trying to handle narrowing part in match.pd and add else return; when
> precision is not equal.
> 
> (for bit_op (bit_and bit_xor bit_ior)
>  (simplify
>   (bit_op (convert@0 @1) (convert@2 @3))
>   (if (INTEGRAL_TYPE_P (type)
>       && INTEGRAL_TYPE_P (TREE_TYPE (@1))
>       && tree_nop_conversion_p (TREE_TYPE (@1), TREE_TYPE (@3))
>       && single_use (@0)
>       && single_use (@2)
>       && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@1)))
>    (with { tree type1 = TREE_TYPE (@1); }
>     (convert (bit_op @1 (convert:type1 @3)))))))
> 
> (for bit_op (bit_and bit_xor bit_ior)
>  (simplify
>   (bit_op (convert@0 @1) INTEGER_CST@2)
>   (if (INTEGRAL_TYPE_P (type)
>       && INTEGRAL_TYPE_P (TREE_TYPE (@1))
>       && single_use (@0)
>       && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@1)))
>    (convert (bit_op @1 { fold_convert (TREE_TYPE (@1), @2); })))))

Since there's infinite loop, i'll still handle conversions in tree-ssa-ccp.c as
HJ's attached patch.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Hongtao.liu from comment #8)
> unsigned long pscc_a_2_3;
> int pscc_a_1_4;
> unsigned long pc2;
> void pscc(int n)
> {
>   long mask = 1ll << n;
>   pc2 = __sync_fetch_and_or(&pscc_a_2_3, mask) & mask;
> }
> 
> void pscc1(int n)
> {
>   long mask = 1ll << 65;
>   pc2 = __sync_fetch_and_or(&pscc_a_2_3, mask) & mask;
> }
> 
> pscc and pscc1 have different behavior when n >= 64, It seems unsafe to
> optimize variable mask?

Is the behavior well defined for n >= 64? I got

foo.c:11:19: warning: left shift count >= width of type
[-Wshift-count-overflow]
   11 |   long mask = 1ll << 65;
      |                   ^~

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
Should we open a new bug for missed optimization?

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #15 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to H.J. Lu from comment #13)
> (In reply to Hongtao.liu from comment #8)
> > unsigned long pscc_a_2_3;
> > int pscc_a_1_4;
> > unsigned long pc2;
> > void pscc(int n)
> > {
> >   long mask = 1ll << n;
> >   pc2 = __sync_fetch_and_or(&pscc_a_2_3, mask) & mask;
> > }
> > 
> > void pscc1(int n)
> > {
> >   long mask = 1ll << 65;
> >   pc2 = __sync_fetch_and_or(&pscc_a_2_3, mask) & mask;
> > }
> > 
> > pscc and pscc1 have different behavior when n >= 64, It seems unsafe to
> > optimize variable mask?
> 
> Is the behavior well defined for n >= 64? I got
> 
> foo.c:11:19: warning: left shift count >= width of type
> [-Wshift-count-overflow]
>    11 |   long mask = 1ll << 65;
>       |                   ^~
According to C99
The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are
filled with zeros. If E1 has an unsigned type, the value of the result is E1 ×
2E2, reduced modulo one more than the maximum value representable in the result
type. If E1 has a signed type and nonnegative value, and E1 × 2E2 is
representable in the result type, then that is the resulting value; otherwise,
the behavior is undefined.

So yes, it's well defined, and the result is zero.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Hongtao.liu from comment #15)
> (In reply to H.J. Lu from comment #13)
> > (In reply to Hongtao.liu from comment #8)
> > > unsigned long pscc_a_2_3;
> > > int pscc_a_1_4;
> > > unsigned long pc2;
> > > void pscc(int n)
> > > {
> > >   long mask = 1ll << n;
> > >   pc2 = __sync_fetch_and_or(&pscc_a_2_3, mask) & mask;
> > > }
> > > 
> > > void pscc1(int n)
> > > {
> > >   long mask = 1ll << 65;
> > >   pc2 = __sync_fetch_and_or(&pscc_a_2_3, mask) & mask;
> > > }
> > > 
> > > pscc and pscc1 have different behavior when n >= 64, It seems unsafe to
> > > optimize variable mask?
> > 
> > Is the behavior well defined for n >= 64? I got
> > 
> > foo.c:11:19: warning: left shift count >= width of type
> > [-Wshift-count-overflow]
> >    11 |   long mask = 1ll << 65;
> >       |                   ^~
> According to C99
> The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are
> filled with zeros. If E1 has an unsigned type, the value of the result is E1
> × 2E2, reduced modulo one more than the maximum value representable in the
> result type. If E1 has a signed type and nonnegative value, and E1 × 2E2 is
> representable in the result type, then that is the resulting value;
> otherwise, the behavior is undefined.
> 
> So yes, it's well defined, and the result is zero.

This is the existing behavior since GCC 7.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to David Binderman from comment #0)
> For this C code:
> 
> long pscc_a_2_3;
> int pscc_a_1_4;
> void pscc()
> {
>         pscc_a_1_4 = __sync_fetch_and_and(&pscc_a_2_3, 1);
> }
> 
> compiled by recent gcc trunk, does this:
> 
> $ /home/dcb/gcc/results/bin/gcc -c -O1 bug771.c
> during GIMPLE pass: fab
> bug771.c: In function ‘pscc’:
> bug771.c:3:6: internal compiler error: in optimize_atomic_bit_test_and, at
> tree-ssa-ccp.c:3626
>     3 | void pscc()
>       |      ^~~~
> 0xee6020 optimize_atomic_bit_test_and(gimple_stmt_iterator*, internal_fn,
> bool, bool)
> 	../../trunk.git/gcc/tree-ssa-ccp.c:3626
> 0xee389a (anonymous namespace)::pass_fold_builtins::execute(function*)
> 	../../trunk.git/gcc/tree-ssa-ccp.c:0
> 
> The bug first seems to occur sometime between git hash f2572a398d21fd52
> and a97fdde627e64202,a distance of some 60 commits.
> 
> In that range, commit fb161782545224f55ba26ba663889c5e6e9a04d1
> looks a likely candidate.

This is fixed by r12-5290.  But we should fix the missed optimization.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #18 from Hongtao.liu <crazylht at gmail dot com> ---
Created attachment 51806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51806&action=edit
untested patch.

I'm testing this patch.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #19 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #18)
> Created attachment 51806 [details]
> untested patch.
> 
> I'm testing this patch.

This patch is for optimization.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

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

commit r12-5486-g7df89377a7ae3906255e38a79be8e5d962c3a0df
Author: liuhongt <hongtao.liu@intel.com>
Date:   Tue Nov 16 13:36:36 2021 +0800

    Enhance optimize_atomic_bit_test_and to handle truncation.

    r12-5102-gfb161782545224f5 improves integer bit test on
    __atomic_fetch_[or|and]_* returns only for nop_convert, .i.e.

    transfrom

      mask_5 = 1 << bit_4(D);
      mask.0_1 = (unsigned int) mask_5;
      _2 = __atomic_fetch_or_4 (a_7(D), mask.0_1, 0);
      t1_9 = (int) _2;
      t2_10 = mask_5 & t1_9;

    to

      mask_5 = 1 << n_4(D);
      mask.1_1 = (unsigned int) mask_5;
      _11 = .ATOMIC_BIT_TEST_AND_SET (&pscc_a_1_4, n_4(D), 0);
      _8 = (int) _11;

    And this patch extend the original patch to handle truncation.
    .i.e.

    transform

      long int mask;
      mask_8 = 1 << n_7(D);
      mask.0_1 = (long unsigned int) mask_8;
      _2 = __sync_fetch_and_or_8 (&pscc_a_2_3, mask.0_1);
      _3 = (unsigned int) _2;
      _4 = (unsigned int) mask_8;
      _5 = _3 & _4;
      _6 = (int) _5;

    to

      long int mask;
      mask_8 = 1 << n_7(D);
      mask.0_1 = (long unsigned int) mask_8;
      _14 = .ATOMIC_BIT_TEST_AND_SET (&pscc_a_2_3, n_7(D), 0);
      _5 = (unsigned int) _14;
      _6 = (int) _5;

    2021-11-17  Hongtao Liu  <hongtao.liu@intel.com>
                H.J. Lu  <hongjiu.lu@intel.com>

    gcc/ChangeLog:

            PR tree-optimization/103194
            * match.pd (gimple_nop_atomic_bit_test_and_p): Extended to
            match truncation.
            * tree-ssa-ccp.c (gimple_nop_convert): Declare.
            (optimize_atomic_bit_test_and): Enhance
            optimize_atomic_bit_test_and to handle truncation.

    gcc/testsuite/ChangeLog:

            * gcc.target/i386/pr103194-2.c: New test.
            * gcc.target/i386/pr103194-3.c: New test.
            * gcc.target/i386/pr103194-4.c: New test.
            * gcc.target/i386/pr103194-5.c: New test.
            * gcc.target/i386/pr103194.c: New test.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #21 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to H.J. Lu from comment #14)
> Should we open a new bug for missed optimization?

Missed optimization is fixed in GCC12.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Hongtao.liu from comment #15)
> > Is the behavior well defined for n >= 64? I got
> > 
> > foo.c:11:19: warning: left shift count >= width of type
> > [-Wshift-count-overflow]
> >    11 |   long mask = 1ll << 65;
> >       |                   ^~
> According to C99
> The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are
> filled with zeros. If E1 has an unsigned type, the value of the result is E1
> × 2E2, reduced modulo one more than the maximum value representable in the
> result type. If E1 has a signed type and nonnegative value, and E1 × 2E2 is
> representable in the result type, then that is the resulting value;
> otherwise, the behavior is undefined.
> 
> So yes, it's well defined, and the result is zero.

No, that isn't well defined in any C or C++ versions.
E.g. in C++:
https://eel.is/c++draft/expr.shift#1
The behavior is undefined if the right operand is negative, or greater than or
equal to the width of the promoted left operand.
C99 6.5.7:
If the value of the right operand is negative or is
greater than or equal to the width of the promoted left operand, the behavior
is undefined.
What varies is whether shifting negative values left is well defined or not, or
whether shifting bits into the sign bit of signed type is well defined or not.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[crazylht at gmail dot com]

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

--- Comment #23 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Jakub Jelinek from comment #22)
> (In reply to Hongtao.liu from comment #15)
> > > Is the behavior well defined for n >= 64? I got
> > > 
> > > foo.c:11:19: warning: left shift count >= width of type
> > > [-Wshift-count-overflow]
> > >    11 |   long mask = 1ll << 65;
> > >       |                   ^~
> > According to C99
> > The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are
> > filled with zeros. If E1 has an unsigned type, the value of the result is E1
> > × 2E2, reduced modulo one more than the maximum value representable in the
> > result type. If E1 has a signed type and nonnegative value, and E1 × 2E2 is
> > representable in the result type, then that is the resulting value;
> > otherwise, the behavior is undefined.
> > 
> > So yes, it's well defined, and the result is zero.
> 
> No, that isn't well defined in any C or C++ versions.
> E.g. in C++:
> https://eel.is/c++draft/expr.shift#1
> The behavior is undefined if the right operand is negative, or greater than
> or equal to the width of the promoted left operand.
> C99 6.5.7:
> If the value of the right operand is negative or is
> greater than or equal to the width of the promoted left operand, the
> behavior is undefined.
> What varies is whether shifting negative values left is well defined or not,
> or whether shifting bits into the sign bit of signed type is well defined or
> not.

thanks for correction， I missed another paragraph。 

----cut from WG14--------
The integer promotions are performed on each of the operands. The type of the
result is that of the promoted left operand. If the value of the right operand
is negative or is greater than or equal to the width of the promoted left
operand, the behavior is undefined.

The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are
filled with zeros. If E1 has an unsigned type, the value of the result is E1 ×
2
E2, reduced modulo one more than the maximum value representable in the result
type. If E1 has a signed type and nonnegative value, and E1 × 2E2 is
representable in the result type, then that is the resulting value; otherwise,
the behavior is undefined.
--------end---------

So, the result is undefined.

[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #24 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed for GCC 12.