[Bug c++/105884] New: A possible optimization bug when uint64_t is used with -O2/-O3.

[Bug c++/105884] New: A possible optimization bug when uint64_t is used with -O2/-O3.

[zhonghao at pku dot org.cn]

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

            Bug ID: 105884
           Summary: A possible optimization bug when uint64_t is used with
                    -O2/-O3.
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

zapret is a tool to bypass network blocking:
https://github.com/bol-van/zapret/blob/master/docs/readme.eng.md

I notice that its programmers complain an optimization bug. This bug is
triggered when gcc optimizes uint64_t. The commit is
https://github.com/bol-van/zapret/commit/9402cd2cf0a16352a3401f7bce1a894bf131138b

Please check the problem.

[Bug c++/105884] A possible optimization bug when uint64_t is used with -O2/-O3.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am 99% sure this is an aliasing issue with the code. Try
-fno-strict-aliasing.

[Bug c++/105884] A possible optimization bug when uint64_t is used with -O2/-O3.

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Definitely an aliasing bug:

        ((uint64_t*)result->s6_addr)[0] = ((uint64_t*)a->s6_addr)[0] &
((uint64_t*)b->s6_addr)[0];
        ((uint64_t*)result->s6_addr)[1] = ((uint64_t*)a->s6_addr)[1] &
((uint64_t*)b->s6_addr)[1];

Even their "fix" to use uint32_t instead is wrong.

With glibc the s6_addr array has type uint8_t[16] so there are no uint64_t (or
uint32_t) objects there.

With _GNU_SOURCE or _DEFAULT_SOURCE (formerly _BSD_SOURCE) defined, there is a
s6_addr32 member which can be used to type-pun the s6_addr array as 32-bit
values.

The portable solution is to memcpy from s6_addr to uint64_t[2], perform the
bitwise AND ops on the uint64_t objects, and then memcpy back to s6_addr.

[Bug c++/105884] A possible optimization bug when uint64_t is used with -O2/-O3.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I commented upstream:
https://github.com/bol-van/zapret/commit/9402cd2cf0a16352a3401f7bce1a894bf131138b#r75598628