Hang when simulated program's input is near INT_MIN about gem5

[BobbyRBruce]

I have been able to reproduce this error. For the others wishing to reproduce the error themselves, I've created the following package. Once you have the binary it's fairly easy to reproduce

issue-790-reproduction.tar.gz

[powerjg]

Which CPU does this occur with? Atomic? Timing? All?

[BobbyRBruce]

Which CPU does this occur with? Atomic? Timing? All?

I've reproduced this with timing.

[BobbyRBruce]

Which CPU does this occur with? Atomic? Timing? All?

I've reproduced this with timing.

Just reproduced it in with atomic CPU also.

[BobbyRBruce]

We have developed two theories here:

1. Running this binary on my local machine takes 16.5s. I dind't expect that binary to take that long initially, but that loop is iterated through A LOT. It could just take a lot more than 3 hours to complete, perhaps up to 24 hours or more. I'm going to leave this running for a couple of days and see what happens.
2. There's some undefined behavior with all these uninitialized variables. This undefined behavior could lead to different behaviors in the SE-mode simulation than on host. This I'm more dubious of, but the code used to recreate this bug is a weird compiler test and that jumps out to me as an oddity.

[karineek]

The variables: int a, b, c, g, k, l, m, n; char h;, are global; but char j; is local and uninitialised. Now the question is what's going on with m = b || c < 0 || c > 1 ? : c;, now since b (I think) is 0, then we try to evaluate c < 0 and get a UB.

However, I am not so sure, because it is a compiler test case from GCC torture which is supposed to be UB-free.

[ivanaamit]

We ran it overnight, and it finished, but it took a long time. @BobbyRBruce, please correct me if I am wrong.