Incorrect TRUE for warning: ignoring bswap about cbmc

[lucasccordeiro]

@tautschnig: I think I have seen one of your PRs related to bswap.

[tautschnig]

Yes, but 1) should that be the root cause then there's a problem with the benchmark as it would rely on GCC built-ins; 2) I believe we would generate non-deterministic values in such a case, and thus over-approximate rather than introduce an error. Also, the solver terminates VERY quickly, so I'd be a bit surprised if it were related to bswap.

[lucasccordeiro]

Thanks for the feedback. I'm taking a look at this issue right now.

…

On 4 December 2017 at 11:44, Michael Tautschnig ***@***.***> wrote: Yes, but 1) should that be the root cause then there's a problem with the benchmark as it would rely on GCC built-ins; 2) I believe we would generate non-deterministic values in such a case, and thus over-approximate rather than introduce an error. Also, the solver terminates VERY quickly, so I'd be a bit surprised if it were related to bswap. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADheHW11FV4XVmnF1GIByvONdRTVy0-pks5s89ssgaJpZM4Q0hRc> .

[marek-trtik]

Here are results of my investigation:

• I failed to manually prove or disprove the classification of the benchmark, because the benchmark is big and messy, and no short property-violating error trace exists (I failed to find any).
• For low unwind constant CBMC terminates with TRUE, for larger constants (e.g. 40) it timeouts (15min).
• I checked other tools for error traces, namely CPA-seq, SMACK, ESBMC, UAutomizer. But none of them successfully analysed the benchmarks (typically timeouts).