Created attachment 15638 [details] The source file This program was generated by csmith and compiled at -O1. While single-stepping, a line was reached that the program had not yet executed. gcc version:9.4.0 (installed by sudo command) gdb version:13.2 os:Ubuntu 20.04 The problem occurs on line 333.The problem occurs on line 333. This line is not a return statement in the source code. Reading symbols from ./random_64.o... (gdb) b func_1 Breakpoint 1 at 0x31f4: file random_64_mutated.c, line 224. (gdb) r Starting program: /home/hzw/experiment/mutation/mutated_files/random_64.o Breakpoint 1, func_1 () at random_64_mutated.c:224 224 int32_t l_2166 = 1L; (gdb) n 247 g_2153[0] = func_2((func_4(func_7(g_11, l_12, g_11), (l_12 < l_12)) , ((safe_mul_func_uint8_t_u_u(0xDCL, (l_1915 = ((func_4(((*l_1908)--), l_12) , g_1630.f1) | 0UL)))) >= 6L))); (gdb) 248 int32_t c_61 = l_1915 * l_2166; (gdb) 250 int32_t c_63 = l_2166 * (*(*l_2366)); (gdb) 256 int32_t c_69 = l_1915 * l_1915; (gdb) 278 g_2476[2][3][0] = c_89 - c_90; (gdb) 279 if ((~(safe_div_func_uint8_t_u_u(((((254UL && (((safe_rshift_func_uint16_t_u_s((((safe_mul_func_uint32_t_u_u((safe_sub_func_int64_t_s_s((safe_rshift_func_uint64_t_u_u(((l_2166 |= (0x60DEL | (l_1915 = l_12))) , (l_2167 != l_2165[0])), 40)), (l_12 <= (safe_rshift_func_int8_t_s_s(l_12, ((*l_2170) = (((l_12 , l_1908) != l_1908) <= g_841.f0))))))), l_12)) | g_1399) , 0x5B0BL), l_12)) <= l_12) >= 0xEC13E069L)) ^ g_388) != 0x74L) , g_120.f1), l_12)))) (gdb) 288 (*g_105) = (safe_mod_func_int32_t_s_s((l_12 == ((safe_rshift_func_uint64_t_u_u((l_2175[0] == ((l_2176 == l_2176) , (((&g_579 != l_2177) , l_2178) , (((*g_657) , (255UL ^ 0xE6L)) , (*g_1254))))), 45)) & l_1915)), 4294967291UL)); (gdb) 333 return (gdb) 289 (*g_2180) = (*g_1305); (gdb) 321 g_1388[0][0][3] = c_119 + c_120; (gdb) 740 (*l_2366) = l_2532[0]; (gdb) main (argc=<optimized out>, argv=<optimized out>) at random_64_mutated.c:1760 1760 csmith_sink_ = g_11; After that, I tried to execute it with lldb in single step. After executing the if statement, lldb went back to execute the statement of the previous basic block. It seems that some kind of optimization scheduled the instructions, causing gdb to have an error. I attached the debugging information printed by llvm-dwarfdump, I hope it helps.
(In reply to Hu ZW from comment #0) > The problem occurs on line 333. This line is > not a return statement in the source code. > > (gdb) > 333 return When you are on this line, can you try to find out where it is from? Because I don't think gdb just invented it. You can try any or all of these commands: frame bt info source
Dup. *** This bug has been marked as a duplicate of bug 32011 ***