Bug 105884 - A possible optimization bug when uint64_t is used with -O2/-O3.
Summary: A possible optimization bug when uint64_t is used with -O2/-O3.
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 13.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-08 08:49 UTC by zhonghao
Modified: 2022-06-08 09:41 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zhonghao 2022-06-08 08:49:14 UTC
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.
Comment 1 Andrew Pinski 2022-06-08 08:54:59 UTC
I am 99% sure this is an aliasing issue with the code. Try -fno-strict-aliasing.
Comment 2 Jonathan Wakely 2022-06-08 09:35:43 UTC
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.