You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no problem until the second round, where *g_4 = g_2, and "g_3[g_2] = g_2++;" doesn't satisfy effect safety. But when generate this statement, we didn't know g_4 would point to g_2 in the future, and in Block::post_creation_analysis, it seems also no consideration of this situation.
The text was updated successfully, but these errors were encountered:
Block::find_fixed_point takes a generated for-loop, and repeat the execution several times to make sure all statements in the for-loop body are defined.
I don't see a problem with the generated code. There is a sequence point between computing (*g_4)++ and the assignment to g_3[g_2]. So the fact that g_2 is modified before the sequence point doesn't endanger effect safety when g2 is read for the assignment after the sequence point.
csmith may generate this code:
int g_1;
int g_2;
int g_3[1]={ 0};
int* g_4 = &g_1;
……
for( int i=0; i<=2; i++){
g_3[g_2] = (*g_4)++;
g_4 = &g_2;
}
There is no problem until the second round, where *g_4 = g_2, and "g_3[g_2] = g_2++;" doesn't satisfy effect safety. But when generate this statement, we didn't know g_4 would point to g_2 in the future, and in Block::post_creation_analysis, it seems also no consideration of this situation.
The text was updated successfully, but these errors were encountered: