Open maul-esel opened 4 years ago
When inlining is turned on, all code is inlined in ULTIMATE.start. LTLAutomizer does not analyse anything in that procedure. This is also a problem in the existing LTLAutomizerCInline.xml toolchain – every property seems satisfied.
To fix this, inlining inside ULTIMATE.start should be turned off. The existing settings seem to only support blacklists for the callee ("do not inline calls to X"), not the caller ("do not inline calls from X").
As discussed, I'm opening an issue for my problems with LTLAutomizer. I've committed some workarounds and potential fixes in the wip/dk/ltl-fixes branch.
I'm using the following Boogie program:
with the
LTLAutomizer.xml
toolchain and the settings inexample/settings/ltlAutomizer/Default.epf
. The only change in settings is this:Problem 1: GotoEdges
This results in:
This can be avoided by setting
so this should probably be in the default settings.
Problem 2: NullPointerException with Procedures
With these settings, the next problem is:
because the copied action is a
StatementSequence
(a singleassume true
), whose TransFormula is null. This seems related to procedures, as this statement is a transition fromULTIMATE.startFINAL_NONWA
toULTIMATE.startEXIT_NONWA
; and when I use inlining this problem does not occur.Problem 3: ConcurrentModificationException
I've also encountered the following exception:
This problem seems to also be avoided / masked when inlining. I have not yet managed to produce a small example program exhibiting this, and I don't want to post the original program here (student's work; but I can send it to you). The problem seems to be that
pruneNonProductSinks
iterates over the setmHelperProductStates
, and in the iteration callsremoveProductProgramPointAndSuccessors
(throughpruneNonProductSink
), which modifies the set.