issue: unexpected results in optimizations

issue: unexpected results in optimizations

[Jingwen Wu]

[-- Attachment #1.1: Type: text/plain, Size: 772 bytes --]

Hello, I'm sorry to bother you. And I have some gcc compiler optimization
questions to ask you.
First of all, I used csmith tools to generate c files randomly. Meanwhile,
the final running result is the checksum for global variables in a c file.
For the two c files in the attachment, I performed the equivalent
transformation of loop from *initial.**c* to *transformed.c*. And the two
files produced different results (i.e. different checksum values) when
using *-O1* optimization level, while the results of both are the same when
using other levels of optimization such as *-O0*, *-O2*, *-O3*, *-Os*,
*-Ofast*.
Please help me to explain why this is, thank you.

command line: *gcc file.c -O1 -lm -I $CSMITH_HOME/include && ./a.out*
version: gcc 12.2.0
os: ubuntu 22.04

[-- Attachment #2: transformed.c --]
[-- Type: text/x-c-code, Size: 3301 bytes --]


#include "csmith.h"

static int32_t g_a368[3];
static int32_t g_b368[3];

union U0 {
  const int32_t f0;
};

union U1 {
  const uint16_t f0;
  const uint64_t f1;
  int32_t f2;
  const signed f3 : 29;
};

union U2 {
  int64_t f0;
  int16_t f1;
};

static union U2 g_13 = {7L};
static uint16_t g_21 = 0x4AB4L;
static uint32_t g_24 = 4294967286UL;
static int64_t g_42[3][3] = {{0xE9505C00D4B3BEBDLL, 0xCDCEC458AF32651ELL, 0xCDCEC458AF32651ELL}, {0xE9505C00D4B3BEBDLL, 0xCDCEC458AF32651ELL, 0xCDCEC458AF32651ELL}, {0xE9505C00D4B3BEBDLL, 0xCDCEC458AF32651ELL, 0xCDCEC458AF32651ELL}};
static int8_t g_43[1][2][1] = {{{0xDCL}, {0xDCL}}};
static int64_t *g_62 = &g_13.f0;
static int64_t **volatile g_61 = &g_62;
static union U0 g_87 = {0xA9ACF304L};
static union U0 *g_89[1][3][2] = {{{&g_87, &g_87}, {&g_87, &g_87}, {&g_87, &g_87}}};
static union U0 **volatile g_88[3][1] = {{&g_89[0][2][1]}, {&g_89[0][2][1]}, {&g_89[0][2][1]}};
static union U1 g_409[1][3][2] = {{{{0xD839L}, {0xD839L}}, {{0xD839L}, {0xD839L}}, {{0xD839L}, {0xD839L}}}};

static void func_1(void);

static void func_1() {
  uint32_t p_5 = 3L;
  int32_t l_34 = 0xFF2FD6B2L;

  for (g_13.f0 = 1; (g_13.f0 >= 0); g_13.f0 -= 1) {
    uint8_t l_19 = 1UL;
    int32_t l_25 = 0x5DB5A26CL;
    uint16_t l_35 = 0x2570L;
    uint8_t l_84 = 1UL;
    if ((safe_unary_minus_func_uint8_t_u((((safe_rshift_func_uint16_t_u_s((safe_lshift_func_uint8_t_u_s(l_19, 4)), 3)) <= ((safe_div_func_int32_t_s_s((+(l_34 == 0x494FL)), l_35)), l_34)) >= 3UL)))) {
      for (p_5 = 0; (p_5 <= 0); p_5 += 1) {
        g_42[2][2] ^= 1L;
      }
      if (((g_43[0][1][0] = 0x3F3A8A1DL) < (((g_42[2][0], g_24), 0x9878FF5FL) ^ 0L))) {
      }
    } else {
      for (l_25 = 0; (l_25 <= 1); l_25 += 1) {
        int ii_9;
        int jj_9;
        int ij_9;
        // fusion in max execTimes
        for (g_21 = 0, ii_9 = 0, jj_9 = 0, ij_9 = 0; ij_9 <= 3; ij_9++) {
          if (ij_9 <= 2 && (g_21 <= 1)) {
            g_a368[ii_9] = g_43[0][1][0] * l_84 - g_409[0][0][0].f2;
            g_21 += 1;
            ii_9++;
          }
          if (ij_9 <= 3 && jj_9 < 3) {
            g_b368[jj_9] = g_409[0][1][1].f0 * g_a368[jj_9] + (*g_89[0][2][0]).f0;
            jj_9++;
          }
        }
      }
    }
  }
}

int main(void) {
  int i, j, k;
  int print_hash_value = 0;
  platform_main_begin();
  crc32_gentab();
  func_1();
  transparent_crc(g_21, "g_21", print_hash_value);
  transparent_crc(g_24, "g_24", print_hash_value);
  for (i = 0; i < 3; i++) {
    for (j = 0; j < 3; j++) {
      transparent_crc(g_42[i][j], "g_42[i][j]", print_hash_value);
    }
  }
  for (i = 0; i < 1; i++) {
    for (j = 0; j < 2; j++) {
      for (k = 0; k < 1; k++) {
        transparent_crc(g_43[i][j][k], "g_43[i][j][k]", print_hash_value);
      }
    }
  }
  transparent_crc(g_87.f0, "g_87.f0", print_hash_value);
  for (i = 0; i < 1; i++) {
    for (j = 0; j < 3; j++) {
      for (k = 0; k < 2; k++) {
        transparent_crc(g_409[i][j][k].f0, "g_409[i][j][k].f0", print_hash_value);
      }
    }
  }
  for (i = 0; i < 3; i++) {
    transparent_crc(g_a368[i], "g_a368[i]", print_hash_value);
  }
  for (i = 0; i < 3; i++) {
    transparent_crc(g_b368[i], "g_b368[i]", print_hash_value);
  }
  platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
  return 0;
}

[-- Attachment #3: initial.c --]
[-- Type: text/x-c-code, Size: 3157 bytes --]


#include "csmith.h"

static int32_t g_a368[3];
static int32_t g_b368[3];

union U0 {
  const int32_t f0;
};

union U1 {
  const uint16_t f0;
  const uint64_t f1;
  int32_t f2;
  const signed f3 : 29;
};

union U2 {
  int64_t f0;
  int16_t f1;
};

static union U2 g_13 = {7L};
static uint16_t g_21 = 0x4AB4L;
static uint32_t g_24 = 4294967286UL;
static int64_t g_42[3][3] = {{0xE9505C00D4B3BEBDLL, 0xCDCEC458AF32651ELL, 0xCDCEC458AF32651ELL}, {0xE9505C00D4B3BEBDLL, 0xCDCEC458AF32651ELL, 0xCDCEC458AF32651ELL}, {0xE9505C00D4B3BEBDLL, 0xCDCEC458AF32651ELL, 0xCDCEC458AF32651ELL}};
static int8_t g_43[1][2][1] = {{{0xDCL}, {0xDCL}}};
static int64_t *g_62 = &g_13.f0;
static int64_t **volatile g_61 = &g_62;
static union U0 g_87 = {0xA9ACF304L};
static union U0 *g_89[1][3][2] = {{{&g_87, &g_87}, {&g_87, &g_87}, {&g_87, &g_87}}};
static union U0 **volatile g_88[3][1] = {{&g_89[0][2][1]}, {&g_89[0][2][1]}, {&g_89[0][2][1]}};
static union U1 g_409[1][3][2] = {{{{0xD839L}, {0xD839L}}, {{0xD839L}, {0xD839L}}, {{0xD839L}, {0xD839L}}}};

static void func_1(void);

static void func_1() {
  uint32_t p_5 = 3L;
  int32_t l_34 = 0xFF2FD6B2L;

  for (g_13.f0 = 1; (g_13.f0 >= 0); g_13.f0 -= 1) {
    uint8_t l_19 = 1UL;
    int32_t l_25 = 0x5DB5A26CL;
    uint16_t l_35 = 0x2570L;
    uint8_t l_84 = 1UL;
    if ((safe_unary_minus_func_uint8_t_u((((safe_rshift_func_uint16_t_u_s((safe_lshift_func_uint8_t_u_s(l_19, 4)), 3)) <= ((safe_div_func_int32_t_s_s((+(l_34 == 0x494FL)), l_35)), l_34)) >= 3UL)))) {
      for (p_5 = 0; (p_5 <= 0); p_5 += 1) {
        g_42[2][2] ^= 1L;
      }
      if (((g_43[0][1][0] = 0x3F3A8A1DL) < (((g_42[2][0], g_24), 0x9878FF5FL) ^ 0L))) {
      }
    } else {
      for (l_25 = 0; (l_25 <= 1); l_25 += 1) {
        int ii_9;
        // fusion in max execTimes
        for (g_21 = 0, ii_9 = 0; (g_21 <= 1); g_21 += 1, ii_9++) {
          g_a368[ii_9] = g_43[0][1][0] * l_84 - g_409[0][0][0].f2;
        }
        int jj_9;
        for (jj_9 = 0; jj_9 < 3; jj_9++) {
          g_b368[jj_9] = g_409[0][1][1].f0 * g_a368[jj_9] + (*g_89[0][2][0]).f0;
        }
      }
    }
  }
}

int main(void) {
  int i, j, k;
  int print_hash_value = 0;
  platform_main_begin();
  crc32_gentab();
  func_1();
  transparent_crc(g_21, "g_21", print_hash_value);
  transparent_crc(g_24, "g_24", print_hash_value);
  for (i = 0; i < 3; i++) {
    for (j = 0; j < 3; j++) {
      transparent_crc(g_42[i][j], "g_42[i][j]", print_hash_value);
    }
  }
  for (i = 0; i < 1; i++) {
    for (j = 0; j < 2; j++) {
      for (k = 0; k < 1; k++) {
        transparent_crc(g_43[i][j][k], "g_43[i][j][k]", print_hash_value);
      }
    }
  }
  transparent_crc(g_87.f0, "g_87.f0", print_hash_value);
  for (i = 0; i < 1; i++) {
    for (j = 0; j < 3; j++) {
      for (k = 0; k < 2; k++) {
        transparent_crc(g_409[i][j][k].f0, "g_409[i][j][k].f0", print_hash_value);
      }
    }
  }
  for (i = 0; i < 3; i++) {
    transparent_crc(g_a368[i], "g_a368[i]", print_hash_value);
  }
  for (i = 0; i < 3; i++) {
    transparent_crc(g_b368[i], "g_b368[i]", print_hash_value);
  }
  platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
  return 0;
}

issue: unexpected results in optimizations

[Jingwen Wu]

[-- Attachment #1.1: Type: text/plain, Size: 858 bytes --]

Hello, I'm sorry to bother you. And I have some gcc compiler optimization
questions to ask you.
First of all, I used csmith tools to generate c files randomly. Meanwhile,
the final running result was the checksum for global variables in a c file.
For the two c files in the attachment, I performed the equivalent
transformation of loop from *initial.**c* to *transformed.c*. And the two
files produced different results (i.e. different checksum values) when
using *-O3 and -Ofast* optimization level, while the results of both were
the same when using other levels of optimization such as *-O0*, *-O1*,
*-O2, **-Os*.
Please help me to explain why this is, thank you.

command line: *gcc file.c -O3 -lm -I $CSMITH_HOME/include && ./a.out*
                        *gcc file.c -Ofast -lm -I $CSMITH_HOME/include &&
./a.out*
version: gcc 12.2.0
os: ubuntu 22.04

[-- Attachment #2: initial.c --]
[-- Type: text/x-c-code, Size: 2017 bytes --]

#include "csmith.h"

static int32_t g_a75[4];
static int32_t g_b75[4];

struct S0 {
  uint32_t f0;
  const uint16_t f1;
  volatile int32_t f2;
  uint16_t f3;
  int64_t f4;
};

struct S1 {
  int32_t f0;
  const uint32_t f1;
  uint32_t f2;
};

struct S2 {
  const int64_t f0;
  int32_t f1;
  volatile int64_t f2;
  int8_t f3;
  volatile struct S0 f4;
};

static int8_t g_11 = (-6L);
static int32_t g_13 = 0xC869B7D6L;
static int32_t *g_12[2][3][1] = {{{&g_13}, {&g_13}, {&g_13}}, {{&g_13}, {&g_13}, {&g_13}}};
static volatile uint8_t g_27 = 2UL;
static struct S1 g_237 = {0xD8430CE5L, 0x74A446EAL, 0UL};
static struct S1 g_239 = {9L, 0UL, 18446744073709551615UL};

static int64_t func_1(void);

static int64_t func_1(void) {
  int32_t **l_488 = &g_12[1][1][0];
  int i, j, k;
  for (i = 0; i < 1; i++) {
    int ii_1;
    // fusion in max execTimes
    for (j = 0, ii_1 = 0; j < 2; j++, ii_1++) {
      for (k = 0; k < 1; k++) {
        g_a75[ii_1] = g_237.f0 * g_11 - g_27;
      }
    }
    int jj_1;
    for (jj_1 = 0; jj_1 < 4; jj_1++) {
      g_b75[jj_1] = g_239.f0 * g_a75[jj_1] - g_13;
    }
  }

  return (**l_488);
}

int main(void) {
  int i, j, k;
  int print_hash_value = 0;
  platform_main_begin();
  crc32_gentab();
  func_1();

  transparent_crc(g_11, "g_11", print_hash_value);
  transparent_crc(g_13, "g_13", print_hash_value);
  transparent_crc(g_27, "g_27", print_hash_value);
  transparent_crc(g_237.f0, "g_237.f0", print_hash_value);
  transparent_crc(g_237.f1, "g_237.f1", print_hash_value);
  transparent_crc(g_237.f2, "g_237.f2", print_hash_value);
  transparent_crc(g_239.f0, "g_239.f0", print_hash_value);
  transparent_crc(g_239.f1, "g_239.f1", print_hash_value);
  transparent_crc(g_239.f2, "g_239.f2", print_hash_value);
  for (i = 0; i < 4; i++) {
    transparent_crc(g_a75[i], "g_a75[i]", print_hash_value);
  }
  for (i = 0; i < 4; i++) {
    transparent_crc(g_b75[i], "g_b75[i]", print_hash_value);
  }
  platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
  return 0;
}

[-- Attachment #3: transformed.c --]
[-- Type: text/x-c-code, Size: 2141 bytes --]

#include "csmith.h"

static int32_t g_a75[4];
static int32_t g_b75[4];

struct S0 {
  uint32_t f0;
  const uint16_t f1;
  volatile int32_t f2;
  uint16_t f3;
  int64_t f4;
};

struct S1 {
  int32_t f0;
  const uint32_t f1;
  uint32_t f2;
};

struct S2 {
  const int64_t f0;
  int32_t f1;
  volatile int64_t f2;
  int8_t f3;
  volatile struct S0 f4;
};

static int8_t g_11 = (-6L);
static int32_t g_13 = 0xC869B7D6L;
static int32_t *g_12[2][3][1] = {{{&g_13}, {&g_13}, {&g_13}}, {{&g_13}, {&g_13}, {&g_13}}};
static volatile uint8_t g_27 = 2UL;
static struct S1 g_237 = {0xD8430CE5L, 0x74A446EAL, 0UL};
static struct S1 g_239 = {9L, 0UL, 18446744073709551615UL};

static int64_t func_1(void);

static int64_t func_1(void) {
  int32_t **l_488 = &g_12[1][1][0];
  int i, j, k;
  for (i = 0; i < 1; i++) {
    int ii_1;
    int jj_1;
    int ij_1;
    // fusion in max execTimes
    for (j = 0, ii_1 = 0, jj_1 = 0, ij_1 = 0; ij_1 <= 4; ij_1++) {
      if (ij_1 <= 2 && j < 2) {
        for (k = 0; k < 1; k++) {
          g_a75[ii_1] = g_237.f0 * g_11 - g_27;
        }
        j++;
        ii_1++;
      }
      if (ij_1 <= 4 && jj_1 < 4) {
        g_b75[jj_1] = g_239.f0 * g_a75[jj_1] - g_13;
        jj_1++;
      }
    }
  }

  return (**l_488);
}

int main(void) {
  int i, j, k;
  int print_hash_value = 0;
  platform_main_begin();
  crc32_gentab();
  func_1();

  transparent_crc(g_11, "g_11", print_hash_value);
  transparent_crc(g_13, "g_13", print_hash_value);
  transparent_crc(g_27, "g_27", print_hash_value);
  transparent_crc(g_237.f0, "g_237.f0", print_hash_value);
  transparent_crc(g_237.f1, "g_237.f1", print_hash_value);
  transparent_crc(g_237.f2, "g_237.f2", print_hash_value);
  transparent_crc(g_239.f0, "g_239.f0", print_hash_value);
  transparent_crc(g_239.f1, "g_239.f1", print_hash_value);
  transparent_crc(g_239.f2, "g_239.f2", print_hash_value);
  for (i = 0; i < 4; i++) {
    transparent_crc(g_a75[i], "g_a75[i]", print_hash_value);
  }
  for (i = 0; i < 4; i++) {
    transparent_crc(g_b75[i], "g_b75[i]", print_hash_value);
  }
  platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
  return 0;
}

issue: unexpected results in optimizations

[Jingwen Wu]

[-- Attachment #1.1: Type: text/plain, Size: 774 bytes --]

Hello, I'm sorry to bother you. And I have some gcc compiler optimization
questions to ask you.
First of all, I used csmith tools to generate c files randomly. Meanwhile,
the final running result was the checksum for global variables in a c file.
For the two c files in the attachment, I performed the equivalent
transformation of loop from *initial.**c* to *transformed.c*. And the two
files produced different results (i.e. different checksum values) when
using *-O2* optimization level, while the results of both were the same
when using other levels of optimization such as *-O0*, *-O1*, *-O3*, *-Os*,
*-Ofast*.
Please help me to explain why this is, thank you.

command line: *gcc file.c -O2 -lm -I $CSMITH_HOME/include && ./a.out*
version: gcc 12.2.0
os: ubuntu 22.04

[-- Attachment #2: initial.c --]
[-- Type: text/x-c-code, Size: 1866 bytes --]


#include "csmith.h"

static int32_t g_a321[3];
static int64_t g_b321[3];

union U0 {
  const int32_t f0;
};

union U1 {
  const uint16_t f0;
  const uint64_t f1;
  int32_t f2;
  const signed f3 : 29;
};

union U2 {
  int64_t f0;
  int16_t f1;
};

static uint32_t g_39 = 0x78C76445L;
static union U0 g_87 = {0xA9ACF304L};
static union U0 *g_89[1][3][2] = {{{&g_87, &g_87}, {&g_87, &g_87}, {&g_87, &g_87}}};
static union U0 **volatile g_88[3][1] = {{&g_89[0][2][1]}, {&g_89[0][2][1]}, {&g_89[0][2][1]}};
static int32_t g_165 = 2L;
static union U2 g_261[3] = {{0xDF9C6E8BCC63CCAELL}, {0xDF9C6E8BCC63CCAELL}, {0xDF9C6E8BCC63CCAELL}};
static union U1 g_412 = {3UL};

static void func_1(void);

static void func_1() {
  uint8_t l_19 = 1UL;
  for (l_19 = 0; (l_19 <= 2); l_19 += 1) {
    int i, j;
    for (i = 0; i < 1; i++) {
      for (j = 0; j < 3; j++) {
      }
    }
    int ii_7;
    // fusion in add execTimes
    for (g_39 = 0, ii_7 = 0; (g_39 <= 1); g_39 += 1, ii_7++) {
      g_a321[ii_7] = (*g_89[0][2][0]).f0 * l_19 + g_165;
    }
    int jj_7;
    for (jj_7 = 0; jj_7 < 3; jj_7++) {
      g_b321[jj_7] = g_261[1].f0 * g_a321[jj_7] + g_412.f2;
    }
  }
}

int main(void) {
  int i;
  int print_hash_value = 0;
  platform_main_begin();
  crc32_gentab();
  func_1();
  transparent_crc(g_39, "g_39", print_hash_value);
  transparent_crc(g_87.f0, "g_87.f0", print_hash_value);
  transparent_crc(g_165, "g_165", print_hash_value);
  for (i = 0; i < 3; i++) {
    transparent_crc(g_261[i].f0, "g_261[i].f0", print_hash_value);
  }
  transparent_crc(g_412.f0, "g_412.f0", print_hash_value);
  for (i = 0; i < 3; i++) {
    transparent_crc(g_a321[i], "g_a321[i]", print_hash_value);
  }
  for (i = 0; i < 3; i++) {
    transparent_crc(g_b321[i], "g_b321[i]", print_hash_value);
  }
  platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
  return 0;
}

[-- Attachment #3: transformed.c --]
[-- Type: text/x-c-code, Size: 1966 bytes --]


#include "csmith.h"

static int32_t g_a321[3];
static int64_t g_b321[3];

union U0 {
  const int32_t f0;
};

union U1 {
  const uint16_t f0;
  const uint64_t f1;
  int32_t f2;
  const signed f3 : 29;
};

union U2 {
  int64_t f0;
  int16_t f1;
};

static uint32_t g_39 = 0x78C76445L;
static union U0 g_87 = {0xA9ACF304L};
static union U0 *g_89[1][3][2] = {{{&g_87, &g_87}, {&g_87, &g_87}, {&g_87, &g_87}}};
static union U0 **volatile g_88[3][1] = {{&g_89[0][2][1]}, {&g_89[0][2][1]}, {&g_89[0][2][1]}};
static int32_t g_165 = 2L;
static union U2 g_261[3] = {{0xDF9C6E8BCC63CCAELL}, {0xDF9C6E8BCC63CCAELL}, {0xDF9C6E8BCC63CCAELL}};
static union U1 g_412 = {3UL};

static void func_1(void);

static void func_1() {
  uint8_t l_19 = 1UL;
  for (l_19 = 0; (l_19 <= 2); l_19 += 1) {
    int i, j;
    for (i = 0; i < 1; i++) {
      for (j = 0; j < 3; j++) {
      }
    }
    int ii_7;
    int jj_7;
    int ij_7;
    // fusion in add execTimes
    for (g_39 = 0, ii_7 = 0, jj_7 = 0, ij_7 = 0; ij_7 < 5; ij_7++) {
      if (ij_7 <= 2 && (g_39 <= 1)) {
        g_a321[ii_7] = (*g_89[0][2][0]).f0 * l_19 + g_165;
        g_39 += 1;
        ii_7++;
      } else {
        jj_7 = ij_7 - 2;
        g_b321[jj_7] = g_261[1].f0 * g_a321[jj_7] + g_412.f2;
      }
    }
  }
}

int main(void) {
  int i;
  int print_hash_value = 0;
  platform_main_begin();
  crc32_gentab();
  func_1();
  transparent_crc(g_39, "g_39", print_hash_value);
  transparent_crc(g_87.f0, "g_87.f0", print_hash_value);
  transparent_crc(g_165, "g_165", print_hash_value);
  for (i = 0; i < 3; i++) {
    transparent_crc(g_261[i].f0, "g_261[i].f0", print_hash_value);
  }
  transparent_crc(g_412.f0, "g_412.f0", print_hash_value);
  for (i = 0; i < 3; i++) {
    transparent_crc(g_a321[i], "g_a321[i]", print_hash_value);
  }
  for (i = 0; i < 3; i++) {
    transparent_crc(g_b321[i], "g_b321[i]", print_hash_value);
  }
  platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
  return 0;
}

Re: issue: unexpected results in optimizations

[Dave Blanchard]

Hi Jingwen,

This is the same GCC which in recent versions produces something like two dozen extraneous, useless, no-op instructions when doing a simple 64-bit math operation on 32-bit systems, and does not use SSE properly either. In each major release these problems get worse. The code generator is clearly in a state of slow degradation, starting about GCC version 5 or 6--not coincidentally the same time when the major version numbers started increasingly so rapidly, although it really has been junk since the beginning.

Stefan Kanthak hammered this point home numerous times on this list, much to the ire of people like Jonathan Wakely who called him a noob, telling him to "go file a bug" in a filing cabinet in some obscure corner of a disused lavatory so that it can be safely ignored, and so on. 

It seems that if correct code generation and optimization is important to you (as it should be), GCC is NOT the compiler to be using. I'm all the time discovering new and crazy problems with this convoluted pile of junk. My recent foray into bootstrapping GNAT (ADA) has opened up yet another can of worms. It's broken on GCC 10, and even more broken on GCC 9, and this despite 30+ years of development. 

Sometimes these days I even blame GCC when it wasn't at fault after all, because it's making itself into more and more of a likely suspect as the years go by.

I haven't examined the code output of Clang to see how it compares, but it's worth serious investigation. 

Dave

Re: issue: unexpected results in optimizations

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

Ignore the troll

On Mon, 11 Dec 2023, 17:28 Dave Blanchard, <dave@killthe.net> wrote:

> Hi Jingwen,
>
> This is the same GCC which in recent versions produces something like two
> dozen extraneous, useless, no-op instructions when doing a simple 64-bit
> math operation on 32-bit systems, and does not use SSE properly either. In
> each major release these problems get worse. The code generator is clearly
> in a state of slow degradation, starting about GCC version 5 or 6--not
> coincidentally the same time when the major version numbers started
> increasingly so rapidly, although it really has been junk since the
> beginning.
>
> Stefan Kanthak hammered this point home numerous times on this list, much
> to the ire of people like Jonathan Wakely who called him a noob, telling
> him to "go file a bug" in a filing cabinet in some obscure corner of a
> disused lavatory so that it can be safely ignored, and so on.
>
> It seems that if correct code generation and optimization is important to
> you (as it should be), GCC is NOT the compiler to be using. I'm all the
> time discovering new and crazy problems with this convoluted pile of junk.
> My recent foray into bootstrapping GNAT (ADA) has opened up yet another can
> of worms. It's broken on GCC 10, and even more broken on GCC 9, and this
> despite 30+ years of development.
>
> Sometimes these days I even blame GCC when it wasn't at fault after all,
> because it's making itself into more and more of a likely suspect as the
> years go by.
>
> I haven't examined the code output of Clang to see how it compares, but
> it's worth serious investigation.
>
> Dave
>

Re: issue: unexpected results in optimizations

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

On Mon, 11 Dec 2023, 17:08 Jingwen Wu via Gcc, <gcc@gcc.gnu.org> wrote:

> Hello, I'm sorry to bother you. And I have some gcc compiler optimization
> questions to ask you.
> First of all, I used csmith tools to generate c files randomly. Meanwhile,
> the final running result was the checksum for global variables in a c file.
> For the two c files in the attachment, I performed the equivalent
> transformation of loop from *initial.**c* to *transformed.c*. And the two
> files produced different results (i.e. different checksum values) when
> using *-O2* optimization level, while the results of both were the same
> when using other levels of optimization such as *-O0*, *-O1*, *-O3*, *-Os*,
> *-Ofast*.
> Please help me to explain why this is, thank you.
>

Sometimes csmith can generate invalid code that gets miscompiled. It looks
like you're compiling with no warnings, which is a terrible idea:


> command line: *gcc file.c -O2 -lm -I $CSMITH_HOME/include && ./a.out*
>

You should **at least** enable warnings and make sure gcc isn't pointing
out any problems in the code.

You should also try the options suggested at http://gcc.gnu.org/bugs/ which
help identify invalid code.


version: gcc 12.2.0
> os: ubuntu 22.04
>

Re: issue: unexpected results in optimizations

[Alexander Monakov]

On Tue, 12 Dec 2023, Jonathan Wakely via Gcc wrote:

> On Mon, 11 Dec 2023, 17:08 Jingwen Wu via Gcc, <gcc@gcc.gnu.org> wrote:
> 
> > Hello, I'm sorry to bother you. And I have some gcc compiler optimization
> > questions to ask you.
> > First of all, I used csmith tools to generate c files randomly. Meanwhile,
> > the final running result was the checksum for global variables in a c file.
> > For the two c files in the attachment, I performed the equivalent
> > transformation of loop from *initial.**c* to *transformed.c*. And the two
> > files produced different results (i.e. different checksum values) when
> > using *-O2* optimization level, while the results of both were the same
> > when using other levels of optimization such as *-O0*, *-O1*, *-O3*, *-Os*,
> > *-Ofast*.
> > Please help me to explain why this is, thank you.
> >
> 
> Sometimes csmith can generate invalid code that gets miscompiled. It looks
> like you're compiling with no warnings, which is a terrible idea:
> 
> 
> > command line: *gcc file.c -O2 -lm -I $CSMITH_HOME/include && ./a.out*
> >
> 
> You should **at least** enable warnings and make sure gcc isn't pointing
> out any problems in the code.
> 
> You should also try the options suggested at http://gcc.gnu.org/bugs/ which
> help identify invalid code.

Let me also link the "Testing Compilers Using Csmith" page, which is
currently available via the Wayback Machine, but not its original URL:

https://web.archive.org/web/20230316072811/http://embed.cs.utah.edu/csmith/using.html

It was written by the developers of Csmith.

Alexander

issue: unexpected results in optimizations

[Jingwen Wu]

[-- Attachment #1.1: Type: text/plain, Size: 768 bytes --]

Hello, I'm sorry to bother you. And I have some gcc compiler optimization
questions to ask you.
First of all, I used csmith tools to generate c files randomly. Meanwhile,
the final running result was the checksum for global variables in a c file.
For the two c files in the attachment, I performed the equivalent
transformation of loop from *initial.**c* to *transformed.c*. And the two
files produced different results (i.e. different checksum values) when
using *-Os* optimization level, while the results of both were the same
when using other levels of optimization such as *-O0*, -O1, -O2, -O3,
*-Ofast*.
Please help me to explain why this is, thank you.

command line: *gcc file.c -Os -lm -I $CSMITH_HOME/include && ./a.out*
version: gcc 12.2.0
os: ubuntu 22.04

[-- Attachment #2: initial.c --]
[-- Type: application/octet-stream, Size: 2322 bytes --]


#include "csmith.h"

static int32_t g_a83[69];
static int32_t g_b83[69];

static volatile uint16_t g_2[3][2][1] = {{{0x439BL}, {8UL}}, {{8UL}, {0x439BL}}, {{8UL}, {8UL}}};
static int32_t g_3 = 0xB4E1265AL;
static uint8_t g_13 = 0x83L;
static int16_t g_15[1] = {0x4F23L};
static int32_t *g_20 = &g_3;
static int32_t *const *g_53 = &g_20;
static int32_t *const **g_52 = &g_53;
static int32_t *g_92 = &g_3;
static volatile uint8_t g_167 = 8UL;
static int32_t g_258 = 0xDB41F928L;
static volatile uint8_t *volatile g_261 = &g_167;
static volatile int32_t g_267 = 0x9B2E194DL;
static int32_t **volatile g_389 = &g_92;

static void func_1(void);

static void func_1(void) {
  int32_t l_14 = 0xDD013D0BL;

  if (g_2[1][1][0]) {
    uint32_t l_36[1][3];
    uint8_t *l_37 = &g_13;
    int i, j;
    for (i = 0; i < 1; i++) {
      for (j = 0; j < 3; j++) {
        l_36[i][j] = 0xB839BF5BL;
      }
    }
    if ((~(((***g_52) = l_36[0][1]) ^ (safe_div_func_int64_t_s_s((l_14 || 0x12L), g_15[0]))))) {
      int ii_4;
      // fusion in max execTimes
      for (g_13 = 8, ii_4 = 0; (g_13 <= 44); g_13 = safe_add_func_uint64_t_u_u(g_13, 1), ii_4++) {
        g_a83[ii_4] = g_258 * g_13 + (*g_261);
      }
      int jj_4;
      for (jj_4 = 0; jj_4 < 69; jj_4++) {
        g_b83[jj_4] = (**g_389) * g_a83[jj_4] - g_267;
      }
    } else {
    	uint8_t **l_81 = &l_37;
      uint8_t ***l_80 = &l_81;
    }
  }
}

int main(void) {
  int i, j, k;
  int print_hash_value = 0;
  platform_main_begin();
  crc32_gentab();
  func_1();
  for (i = 0; i < 3; i++) {
    for (j = 0; j < 2; j++) {
      for (k = 0; k < 1; k++) {
        transparent_crc(g_2[i][j][k], "g_2[i][j][k]", print_hash_value);
      }
    }
  }
  transparent_crc(g_3, "g_3", print_hash_value);
  transparent_crc(g_13, "g_13", print_hash_value);
  for (i = 0; i < 1; i++) {
    transparent_crc(g_15[i], "g_15[i]", print_hash_value);
  }
  transparent_crc(g_167, "g_167", print_hash_value);
  transparent_crc(g_258, "g_258", print_hash_value);
  transparent_crc(g_267, "g_267", print_hash_value);
  for (i = 0; i < 69; i++) {
    transparent_crc(g_a83[i], "g_a83[i]", print_hash_value);
  }
  for (i = 0; i < 69; i++) {
    transparent_crc(g_b83[i], "g_b83[i]", print_hash_value);
  }
  platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
  return 0;
}

[-- Attachment #3: transformed.c --]
[-- Type: application/octet-stream, Size: 2457 bytes --]


#include "csmith.h"

static int32_t g_a83[69];
static int32_t g_b83[69];

static volatile uint16_t g_2[3][2][1] = {{{0x439BL}, {8UL}}, {{8UL}, {0x439BL}}, {{8UL}, {8UL}}};
static int32_t g_3 = 0xB4E1265AL;
static uint8_t g_13 = 0x83L;
static int16_t g_15[1] = {0x4F23L};
static int32_t *g_20 = &g_3;
static int32_t *const *g_53 = &g_20;
static int32_t *const **g_52 = &g_53;
static int32_t *g_92 = &g_3;
static volatile uint8_t g_167 = 8UL;
static int32_t g_258 = 0xDB41F928L;
static volatile uint8_t *volatile g_261 = &g_167;
static volatile int32_t g_267 = 0x9B2E194DL;
static int32_t **volatile g_389 = &g_92;

static void func_1(void);

static void func_1(void) {
  int32_t l_14 = 0xDD013D0BL;

  if (g_2[1][1][0]) {
    uint32_t l_36[1][3];
    uint8_t *l_37 = &g_13;
    int i, j;
    for (i = 0; i < 1; i++) {
      for (j = 0; j < 3; j++) {
        l_36[i][j] = 0xB839BF5BL;
      }
    }
    if ((~(((***g_52) = l_36[0][1]) ^ (safe_div_func_int64_t_s_s((l_14 || 0x12L), g_15[0]))))) {
      int ii_4;
      int jj_4;
      int ij_4;
      // fusion in max execTimes
      for (g_13 = 8, ii_4 = 0, jj_4 = 0, ij_4 = 0; ij_4 <= 69; ij_4++) {
        if (ij_4 <= 37 && (g_13 <= 44)) {
          g_a83[ii_4] = g_258 * g_13 + (*g_261);
          g_13 = safe_add_func_uint64_t_u_u(g_13, 1);
          ii_4++;
        }
        if (ij_4 <= 69 && jj_4 < 69) {
          g_b83[jj_4] = (**g_389) * g_a83[jj_4] - g_267;
          jj_4++;
        }
      }
    } else {
    	uint8_t **l_81 = &l_37;
      uint8_t ***l_80 = &l_81;
    }
  }
}

int main(void) {
  int i, j, k;
  int print_hash_value = 0;
  platform_main_begin();
  crc32_gentab();
  func_1();
  for (i = 0; i < 3; i++) {
    for (j = 0; j < 2; j++) {
      for (k = 0; k < 1; k++) {
        transparent_crc(g_2[i][j][k], "g_2[i][j][k]", print_hash_value);
      }
    }
  }
  transparent_crc(g_3, "g_3", print_hash_value);
  transparent_crc(g_13, "g_13", print_hash_value);
  for (i = 0; i < 1; i++) {
    transparent_crc(g_15[i], "g_15[i]", print_hash_value);
  }
  transparent_crc(g_167, "g_167", print_hash_value);
  transparent_crc(g_258, "g_258", print_hash_value);
  transparent_crc(g_267, "g_267", print_hash_value);
  for (i = 0; i < 69; i++) {
    transparent_crc(g_a83[i], "g_a83[i]", print_hash_value);
  }
  for (i = 0; i < 69; i++) {
    transparent_crc(g_b83[i], "g_b83[i]", print_hash_value);
  }
  platform_main_end(crc32_context ^ 0xFFFFFFFFUL, print_hash_value);
  return 0;
}

Re: issue: unexpected results in optimizations

[David Brown]

Hi,

First, please ignore everything Dave Blanchard writes.  I don't know 
why, but he likes to post angry, rude and unhelpful messages to this list.

Secondly, this is the wrong list.  gcc-help would be the correct list, 
as you are asking for help with gcc.  This list is for discussions on 
the development of gcc.

Thirdly, if you want help, you need to provide something that other 
people can comprehend.  There is very little that anyone can do to 
understand lumps of randomly generated code, especially when it cannot 
compile without headers and additional files or libraries that we do not 
have.

So your task is to write a /minimal/ piece of stand-alone code that 
demonstrates the effect that concerns you.  It is fine to use standard 
headers like <stdint.h>, but no external headers like this "csmith" 
stuff.  Aim to make it small enough to be included directly in the text 
of the post, not as an attachment.  Include the compiler version(s) you 
tried, the command line flags, what you expect the results to give, and 
what wrong results you got.

Always do development compiles with comprehensive sets of warnings.  I 
managed to take a section of your code (part that was different between 
the "initial.c" and "transformed.c") and compile it - there were lots of 
warnings.  There are a lot of overflows in initialisations, pointless 
calculations on the left of commas, and other indications of badly 
written code.  There were also static warnings about undefined behaviour 
in some calculations - and that, most likely, is key.

When code has undefined behaviour, you cannot expect the compiler to 
give any particular results.  It's all down to luck.  And luck varies 
with the details, such as optimisation levels.  It's "garbage in, 
garbage out", and that is the explanation for differing results.

So compile with "-Wall -Wextra -std=c99 -Wpedantic -O2" and check all 
the warnings.  (Static warnings work better when optimising the code.) 
If you have fixed the immediate problems in the code, add the 
"-fsanitize=undefined" flag before running it.  That will do run-time 
undefined behaviour checks.

If you have a code block that is small enough to comprehend, and that 
you are now confident has no undefined behaviour, and you get different 
results with different optimisations, post it to the gcc-help list. 
Then people can try it and give opinions - maybe there is a gcc bug.

I hope that all helps.

David





On 11/12/2023 18:14, Jingwen Wu via Gcc wrote:
> Hello, I'm sorry to bother you. And I have some gcc compiler optimization
> questions to ask you.
> First of all, I used csmith tools to generate c files randomly. Meanwhile,
> the final running result was the checksum for global variables in a c file.
> For the two c files in the attachment, I performed the equivalent
> transformation of loop from *initial.**c* to *transformed.c*. And the two
> files produced different results (i.e. different checksum values) when
> using *-Os* optimization level, while the results of both were the same
> when using other levels of optimization such as *-O0*, -O1, -O2, -O3,
> *-Ofast*.
> Please help me to explain why this is, thank you.
> 
> command line: *gcc file.c -Os -lm -I $CSMITH_HOME/include && ./a.out*
> version: gcc 12.2.0
> os: ubuntu 22.04

Re: issue: unexpected results in optimizations

[James K. Lowden]

On Tue, 12 Dec 2023 09:39:58 +0100
David Brown via Gcc <gcc@gcc.gnu.org> wrote:

> If you have fixed the immediate problems in the code, add the 
> "-fsanitize=undefined" flag before running it.  That will do run-time 
> undefined behaviour checks.

I would like to understand that better, for reasons you might guess.  

-fsanitize is described under Program Instrumentation Options, but much
of the terminology seems to C, and some of the options are documented
to work only with C or C++. 

If it applies to the generated code irrespective of the front-end, then
could the options be described in terms of Generic?  For example,
signed-integer-overflow, bounds, and bounds-strict would seem to be
useful in any language that defines integers and arrays.  I also wonder
if "integer" includes _Float128. 

"-fsanitize" appears only once in the Internals document, under 

	bool TARGET_MEMTAG_CAN_TAG_ADDRESSES

If I knew when contructs were needed for particular options to work, I
could add them to the documentation.  

--jkl