[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
gcc-bugzilla@gcc.gnu.org
Tue Nov 16 02:24:03 GMT 2021
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.
More information about the Gcc-bugs
mailing list