wrong code error

[llvmbot]

Bugzilla Link	41764
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@dwblaikie

Extended Description

I am not sure whether it is a bug. Maybe it is an undefined behaviour. I cannot understand why the results are different at different optimization level.
Specially, if I change the int64_t to type int, the bug doesn't exist.

> cat report.c

typedef char int8_t;
typedef int int16_t;
typedef int uint16_t;
typedef long int64_t;
typedef char uint8_t;
typedef int uint32_t;

union a {
  int64_t b;
  uint16_t c;
} e;
int8_t d, l, h;
uint16_t *g = &e.c;
uint16_t **i = &g;
int16_t j;
uint16_t ***k = &i;
uint32_t m();
int8_t *n(uint16_t, uint32_t, uint16_t, union a, uint32_t);
uint32_t o() {
  union a p = {};
  m(n(d, 0, 0, p, d));
  return l;
}
uint32_t m() {
  int64_t *ad = &e.b;
  *ad = 0;
  int16_t *ae = &j;
  *ae = ***k;
  return h;
}
int8_t *n(uint16_t f, uint32_t ag, uint16_t ah, union a ai, uint32_t aj) {
  int8_t *ak = &d;
  (***k)++;
  return ak;
}
int main() {
  o();
  printf("%d\n", j);
}

> clang -v 
clang version 9.0.0 (trunk 356835) (llvm/trunk 356836)
......

> clang report.c -O0 -o a0
> clang report.c -O2 -o a2
>./a0
0
>./a2
1

[frederick-vs-ja]

Reduced example, still reproducible on the trunk (Godbolt link):

#include <stdio.h>

union U {
  long first;
  int second;
} x;

int *p2 = &x.second;
int result;

int main(void) {
  ++*p2;
  long *p1 = &x.first;
  *p1 = 0;
  result = *p2;

  printf("%d\n", result);
}

I'm pretty sure that this program contains UB in C++. But it seems to me it has no UB in C.

[llvmbot]

@llvm/issue-subscribers-c

Author: None (llvmbot)

Details

| | | | --- | --- | | Bugzilla Link | [41764](https://llvm.org/bz41764) | | Version | trunk | | OS | Linux | | Reporter | LLVM Bugzilla Contributor | | CC | @dwblaikie |

Extended Description

I am not sure whether it is a bug. Maybe it is an undefined behaviour. I cannot understand why the results are different at different optimization level.
Specially, if I change the int64_t to type int, the bug doesn't exist.

> cat report.c

typedef char int8_t;
typedef int int16_t;
typedef int uint16_t;
typedef long int64_t;
typedef char uint8_t;
typedef int uint32_t;

union a {
  int64_t b;
  uint16_t c;
} e;
int8_t d, l, h;
uint16_t *g = &e.c;
uint16_t **i = &g;
int16_t j;
uint16_t ***k = &i;
uint32_t m();
int8_t *n(uint16_t, uint32_t, uint16_t, union a, uint32_t);
uint32_t o() {
  union a p = {};
  m(n(d, 0, 0, p, d));
  return l;
}
uint32_t m() {
  int64_t *ad = &e.b;
  *ad = 0;
  int16_t *ae = &j;
  *ae = ***k;
  return h;
}
int8_t *n(uint16_t f, uint32_t ag, uint16_t ah, union a ai, uint32_t aj) {
  int8_t *ak = &d;
  (***k)++;
  return ak;
}
int main() {
  o();
  printf("%d\n", j);
}

> clang -v 
clang version 9.0.0 (trunk 356835) (llvm/trunk 356836)
......

> clang report.c -O0 -o a0
> clang report.c -O2 -o a2
>./a0
0
>./a2
1

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: None (llvmbot)

Details

| | | | --- | --- | | Bugzilla Link | [41764](https://llvm.org/bz41764) | | Version | trunk | | OS | Linux | | Reporter | LLVM Bugzilla Contributor | | CC | @dwblaikie |

Extended Description

I am not sure whether it is a bug. Maybe it is an undefined behaviour. I cannot understand why the results are different at different optimization level.
Specially, if I change the int64_t to type int, the bug doesn't exist.

> cat report.c

typedef char int8_t;
typedef int int16_t;
typedef int uint16_t;
typedef long int64_t;
typedef char uint8_t;
typedef int uint32_t;

union a {
  int64_t b;
  uint16_t c;
} e;
int8_t d, l, h;
uint16_t *g = &e.c;
uint16_t **i = &g;
int16_t j;
uint16_t ***k = &i;
uint32_t m();
int8_t *n(uint16_t, uint32_t, uint16_t, union a, uint32_t);
uint32_t o() {
  union a p = {};
  m(n(d, 0, 0, p, d));
  return l;
}
uint32_t m() {
  int64_t *ad = &e.b;
  *ad = 0;
  int16_t *ae = &j;
  *ae = ***k;
  return h;
}
int8_t *n(uint16_t f, uint32_t ag, uint16_t ah, union a ai, uint32_t aj) {
  int8_t *ak = &d;
  (***k)++;
  return ak;
}
int main() {
  o();
  printf("%d\n", j);
}

> clang -v 
clang version 9.0.0 (trunk 356835) (llvm/trunk 356836)
......

> clang report.c -O0 -o a0
> clang report.c -O2 -o a2
>./a0
0
>./a2
1

[shafik]

Use -fno-strict-aliasing and we obtain identical results: https://godbolt.org/z/rPbfzn5ha

If you want type punning then use bit_cast in C++ or memcpy in C or just type pun directly via the union itself (only valid in C).