Bug ID: 41764
           Summary: wrong code error
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs

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;
  return ak;
int main() {
  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

You are receiving this mail because:
You are on the CC list for the bug.
llvm-bugs mailing list

Reply via email to