[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from H.J. Lu --- Fixed for GCC 12.
[Bug tree-optimization/103194] [12 Regression] ice in optimize_atomic_bit_test_and with __sync_fetch_and_and since r12-5102-gfb161782545224f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #23 from Hongtao.liu --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #22 from Jakub Jelinek --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #21 from Hongtao.liu --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #20 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:7df89377a7ae3906255e38a79be8e5d962c3a0df commit r12-5486-g7df89377a7ae3906255e38a79be8e5d962c3a0df Author: liuhongt 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 (_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 (_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 (_a_2_3, n_7(D), 0); _5 = (unsigned int) _14; _6 = (int) _5; 2021-11-17 Hongtao Liu H.J. Lu 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #19 from Hongtao.liu --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #18 from Hongtao.liu --- Created attachment 51806 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51806=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #17 from H.J. Lu ---
(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(_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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #16 from H.J. Lu ---
(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(_a_2_3, mask) & mask;
> > > }
> > >
> > > void pscc1(int n)
> > > {
> > > long mask = 1ll << 65;
> > > pc2 = __sync_fetch_and_or(_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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #15 from Hongtao.liu ---
(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(_a_2_3, mask) & mask;
> > }
> >
> > void pscc1(int n)
> > {
> > long mask = 1ll << 65;
> > pc2 = __sync_fetch_and_or(_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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #14 from H.J. Lu --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #13 from H.J. Lu ---
(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(_a_2_3, mask) & mask;
> }
>
> void pscc1(int n)
> {
> long mask = 1ll << 65;
> pc2 = __sync_fetch_and_or(_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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #12 from Hongtao.liu ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #11 from Andrew Pinski --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #10 from Hongtao.liu ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #9 from Hongtao.liu ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
Hongtao.liu changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Hongtao.liu ---
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(_a_2_3, mask) & mask;
}
void pscc1(int n)
{
long mask = 1ll << 65;
pc2 = __sync_fetch_and_or(_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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #7 from Hongtao.liu --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 H.J. Lu changed: What|Removed |Added Attachment #51784|0 |1 is obsolete|| --- Comment #6 from H.J. Lu --- Created attachment 51785 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51785=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 --- Comment #5 from H.J. Lu --- Created attachment 51784 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51784=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194
--- Comment #4 from H.J. Lu ---
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, _p, _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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103194 Martin Liška 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 --- Really started with r12-5102-gfb161782545224f5.
