[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