[Bug c/98582] New: Optimization combined with aliasing generating wrong code

[ferruh.yigit at intel dot com via Gcc-bugs]

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

Bug ID: 98582
   Summary: Optimization combined with aliasing generating wrong
code
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ferruh.yigit at intel dot com
  Target Milestone: ---

This is reported by "George Prekas " to the DPDK mailing
list, also following sample code to reproduce the error is by him:

---

#include 
#include 
#include 
#include 

struct rte_ipv4_hdr {
uint8_t  version_ihl;
uint8_t  type_of_service;
uint16_t total_length;
uint16_t packet_id;
uint16_t fragment_offset;
uint8_t  time_to_live;
uint8_t  next_proto_id;
uint16_t hdr_checksum;
uint32_t src_addr;
uint32_t dst_addr;
};

static inline uint16_t ip_sum(const uint16_t *hdr, int hdr_len)
{
uint32_t sum = 0;

while (hdr_len > 1)
{
sum += *hdr++;
if (sum & 0x8000)
sum = (sum & 0x) + (sum >> 16);
hdr_len -= 2;
}

while (sum >> 16)
sum = (sum & 0x) + (sum >> 16);

return ~sum;
}

static void pkt_burst_flow_gen(void)
{
struct rte_ipv4_hdr *ip_hdr = (struct rte_ipv4_hdr *) malloc(4096);
memset(ip_hdr, 0, sizeof(*ip_hdr));
ip_hdr->version_ihl = 1;
ip_hdr->type_of_service = 2;
ip_hdr->fragment_offset = 3;
ip_hdr->time_to_live= 4;
ip_hdr->next_proto_id   = 5;
ip_hdr->packet_id   = 6;
ip_hdr->src_addr= 7;
ip_hdr->dst_addr= 8;
ip_hdr->total_length= 9;
ip_hdr->hdr_checksum= ip_sum((uint16_t *)ip_hdr, sizeof(*ip_hdr));
printf("%x\n", ip_hdr->hdr_checksum);
}

int main(void)
{
pkt_burst_flow_gen();
return 0;
}

---

with -O0 it outputs: f8d9
With -O3 it outputs: ffed
With -O2 it outputs: fdec


"-O3 -fno-strict-aliasing" is also works and outputs: f8d9

clang 11, with "-O3" returns: f8d9

With gcc 10.2 the value is calculated in the compile-time:
mov$0xffed,%esi

and calculated value is wrong, not quite sure if a violation of the strict
aliasing or gcc internal defect. Reporting here to get more insight.

The header banner suggests the code is wrong [1], if that is the case you
please help to figure out what is wrong.

Thanks,
ferruh

[1]
"Similarly, if compiling with -fno-strict-aliasing -fwrapv makes a difference,
your code probably is not correct."

[Bug c/98582] Optimization combined with aliasing generating wrong code

[ferruh.yigit at intel dot com via Gcc-bugs]

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

--- Comment #2 from Ferruh YIGIT  ---
Thanks Jakup,

I confirm the 'may_alias' attribute is doing the trick. -fno-strict-aliasing
was already confirmed.

I can see the aliasing between incompatible types, but it bothers me not able
to see what exactly goes wrong. Anyway, if there is no problem with the
compiler this defect can get be closed.

And is there any side effect of the '-fno-strict-aliasing' other than allowing
the non-standard compatible aliasing, may it cause performance impact because
of the reduced optimization etc? If so I will go with 'may_alias' attribute in
a reduced scope.

Thanks again,
ferruh