Side-effectful Nontermination #772

ThomasHaas · 2024-11-07T11:41:42Z

This PR adds a new, improved encoding that can detect some cases of side-effectful non-termination.

EDIT: The below description is not fully accurate anymore.

I added 5 new benchmarks to specifically test this, and updated the verdicts of the existing liveness tests that are now correctly identified as FAIL rather than UNKNOWN.
The encoding is functional and replaces the old encoding for deadlocks/liveness issues.
So feel free to test this branch on some real code.

Important notes:

In the presence of side-effectful loops, we generally need to unroll the code at least twice (B=2) and possibly even more times to find liveness issues
For side-effectful loops, we can only find liveness issues but no proof of termination! This means that no previous UNKNOWN verdict will become a PASS with theses changes, only possibly a FAIL!

The reasons that this PR is marked as DRAFT are:

The new encoding might have issues with uninit reads (we have no test for this). Even the old one might have had issues here.
~~The new encoding currently does also detect liveness issue that are caused by assertion failures, which the old one did not. This is easy to fix but we also have no test cases for this yet.~~
~~The new encoding does not reason about non-termination due to control barriers at all. We have no tests involving non-termination due to CBs.~~
We can detect many liveness issues in some of the currently skipped litmus tests for Vulkan. However, the liveness issue is only present under weak progress, so if I remove the test from the skip list, at least the LitmusVulkanFairLivenessTest will fail. We would need to be able to enable tests only for certain progress models and skip them for others.
~~EDIT: Fairness of spuriously failing events like StoreExclusive is not considered so far. We also do not have tests for this scenario.~~

~~Because of points (1) and (4), I have not yet deleted the old code (it is unused though).~~

…on-termination

Updated expected values in LivenessTest for existing tests that now show liveness violations (from UNKNOWN to FAIL)

ThomasHaas · 2024-11-07T15:45:02Z

The existing liveness tests seem to be correct, and the change from UNKNOWN to FAIL was not caused by side-effectful nontermination but by point (2) I mentioned above. The relaxation of some barriers caused an assertion failure, which then caused some thread to abort and not release its lock, which was then treated as liveness issue.
I will fix this and revert the changes to the tests.

EDIT: Fixed the issue and reverted expected outcome of some tests.

Fixed Nontermination verdict if nontermination was caused due to assertion failure. Updated expected outcomes of LivenessTest caused by the above change.

…on-termination

Updated expected values in LivenessTest for existing tests that now show liveness violations (from UNKNOWN to FAIL)

Fixed Nontermination verdict if nontermination was caused due to assertion failure. Updated expected outcomes of LivenessTest caused by the above change.

hernanponcedeleon · 2024-11-10T20:36:11Z

We can detect many liveness issues in some of the currently skipped litmus tests for Vulkan. However, the liveness issue is only present under weak progress, so if I remove the test from the skip list, at least the LitmusVulkanFairLivenessTest will fail. We would need to be able to enable tests only for certain progress models and skip them for others.

Can't we add a configurable (similar to several of our providers) that allows us to define a more fine-grained skip predicate and define the predicate accordingly based on the progress model?

ThomasHaas · 2024-11-10T20:55:28Z

We could have skip lists per progress model, but can't we instead just comment out the tests in the expected files? Those files are already defined on a per-progress-model basis.

hernanponcedeleon · 2024-11-11T07:51:23Z

Having skip list per model is not maintainable. If at some point we notice that e.g., the arch can also influence these things we need to do yet another level of splitting.

can't we instead just comment out the tests in the expected files?

As long as we do not lose the information we currently have (e.g., removing the lines is a "no go"), it should be fine.

ThomasHaas · 2024-11-11T09:03:13Z

Having skip list per model is not maintainable. If at some point we notice that e.g., the arch can also influence these things we need to do yet another level of splitting.

Using providers to skip the tests would effectively also just be a skiplist per model, but just written in code (unless you find a way to skip tests based on something other than their name).

…ation

ThomasHaas · 2024-11-11T18:52:10Z

Little update: this branch can give wrong verdicts on some simple cases where SCCP eliminates loop counter variables and the loop termination condition entirely.

int i = 0;
while (i < 10) { i++; }

The above program is wrongly considered non-terminating if unrolled insufficiently.
The reason is that after unrolling + SCCP, the resulting code is essentially indistuinguishable from a while (true) loop.

EDIT: This is fixed now

hernanponcedeleon · 2024-11-16T18:57:42Z

I suspect that the problem is not SCCP, but rather DeadAssignmentElimination which removes side-effects and might not be really sound when we want to check liveness.

ThomasHaas · 2024-11-16T19:27:38Z

It's both actually. SCCP makes the assignments dead and even if they were not deleted I would like my code to not care about variables that are not live inside the loop (I have not implemented this yet, but I will eventually).
The solution is similar to what we already do: instrument the loop properly. Then SCCP/DAE can run as usual because the instrumentation will capture the necessary information for liveness detection.

…detection: this removes a wrong verdict related to SCCP removing the whole loop body. Added new test related to above issue. Minor updates to related code.

ThomasHaas · 2024-12-17T23:50:04Z

How necessary is it to support non-termination due to blocked ControlBarriers? We don't have any tests for this nor do we actually know how scheduling in the presence of blocked ControlBarriers work (the blocked thread cannot be rescheduled I guess).

hernanponcedeleon · 2024-12-18T08:34:18Z

The best would be to have support for non-termination for a given encoding of BlockedBarrier (whatever that one is). Correctly handling that is orthogonal to this PR (and actually related to #768).

ThomasHaas · 2024-12-18T10:07:09Z

Then I will copy over whatever we are doing right now for blocked control barriers into the new non-termination detection.

ThomasHaas · 2025-01-15T09:56:16Z

Yes, cause I didn't implement control barriers at all, i.e., there was not a single line of code handling them.
I fixed this locally already but I have no tests besides this trivial one.

Pure control-barrier nontermination actually requires nothing of the new theory: it is a standard reachability problem as no thread does anything anymore and thus is witnessed by standard finite executions.
The difficulty here is just ensuring that CBs are correctly waiting for each other for which we do not have good tests yet.

The most interesting type of non-termination would involve both barriers and loops: some threads get stuck in barriers while others are looping (possibly even with barriers inside the loop).

Added consideration of ControlBarriers in non-termination (WIP)

…ation

hernanponcedeleon · 2025-01-16T08:05:42Z

clspv benchmarks/opencl/NonUniformBarrier.cl --cl-std=CL3.0 --inline-entry-points --spv-version=1.6 -o kernel.spv
spirv-dis kernel.spv > kernel.spv.dis
spirv-opt --upgrade-memory-model kernel.spv.dis -o dartagnan/src/test/resources/spirv/basic/UniformBarrier-opt.spv.dis

I actually got the order of cmds wrong, the optimization should be done on the binary

> clspv benchmarks/opencl/NonUniformBarrier.cl --cl-std=CL3.0 --inline-entry-points --spv-version=1.6 -o kernel.spv
> spirv-opt --upgrade-memory-model kernel.spv -o kernel-opt.spv
> spirv-dis kernel-opt.spv > dartagnan/src/test/resources/spirv/basic/NonUniformBarrier.spv.dis

…old version) - Deleted old LivenessEncoder code

… (asymmetric) non-termination. Cleaned up NonTerminationEncoder and updated comments.

…tation for better error reporting

ThomasHaas · 2025-02-07T14:51:33Z

I have implemented a (more or less) complete detection of loop non-termination. It can detect all liveness violations in the Vulkan litmus tests, no matter how intricate they are.

The detection relies on a new instrumentation pass called NonterminationDetection. There is an option to affect how aggressively this pass instruments:
(1) Only spinloops: Should result in a detection identical to what we have currently on development
(2) Simple: A cheap version of side-effectful non-termination detection that detects many cases of non-termination that do not require asymmetric loop execution (where one loop runs more often than another).
(3) Full (default): A complete (and possibly expensive) version for side-effectful non-termination detection, required to detect asymmetric non-termination.

Future work:

The encoding can be optimized.
The encoding does not fully match the underlying theory. I believe an accurate encoding might require less unrollings to detect non-termination, though it can also be more expensive.

Issues:

There are very likely issues if loop non-termination is combined with barrier non-termination and I suspect possible false positives (i.e. false "FAIL" results) for now. Since we lack tests for this, I'm not really eager to work on this right now.
Some of the enabled litmus tests have expected result PASS but we return UNKNOWN, therefore the unit tests are failing. We either need to exclude them, or relativize our expected outcome (i.e., if the expectation is PASS, returning UNKNOWN is also correct).

EDIT: The NonterminationDetection pass is actually a kind of more liberal unrolling. Typically, if we have a loop that we unroll B times, then we only consider executions that execute the loop exactly B times (if it is non-terminating).
The idea of the pass is to relax this unrolling to consider also all executions with less than B unrollings.
The resulting program is effectively the superposition of all programs obtained by unrolling each loop 1 <= X <= B times.
Because of this, I might want to integrate this instrumentation into the LoopUnrolling pass with options to enable/disable this type of unrolling.

Btw. this superimposed unrolling also gives a nice monotonicity property which ensures that the executions of a (B+1)-unrolled program is a superset of the executions of a B-unrolled program (we never lose any "short" executions when unrolling more).
However, this may negatively impact the performance for detecting safety/cat violations, especially when iteratively extending the unrolling bound.

hernanponcedeleon · 2025-02-07T16:25:36Z

The second issue is to be expected since I re-enabled all tests in 40624e9. I can take care of this.

…g executions.

hernanponcedeleon

I still have not checked the main class NonTerminationEncoder (probably wont have time before the end of the week), but here are already some small comments.

dartagnan/src/main/java/com/dat3m/dartagnan/configuration/OptionNames.java

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/EncodingContext.java

hernanponcedeleon · 2025-02-10T14:29:58Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/PropertyEncoder.java

-        return new LivenessEncoder().encodeLivenessBugs();
+    private TrackableFormula encodeNontermination() {
+        final BooleanFormula hasNontermination = new NonTerminationEncoder(context.getTask(), context).encodeNontermination();
+        return new TrackableFormula(context.getBooleanFormulaManager().not(LIVENESS.getSMTVariable(context)), hasNontermination);


Should we use NON_TERMINATION instead of LIVENESS?

We specify all properties in the positive (e.g. program_spec rather than spec_violation), so I think it should be LIVENESS. However, the way we check this is by encoding the negative.

I was not referring to the positive vs negative part, but rather about the term "liveness" ... at some point we even had some "deadlock/no-deadlock" terms and I thought that "termination" was maybe a more general one.

However, we use liveness for the property and the nice stdout msg when we find a violation, so for consistency we should probably keep it as it is.

Hmm, we could use TERMINATION as the property. It would be more precise than liveness, since the latter can be understood in many ways.
If I rename it, dependent tools like Vsyncer might need updates.

I can take care of updating vsyncer once we release a new dartagnan and I change the used version there.

dartagnan/src/main/java/com/dat3m/dartagnan/program/processing/DynamicSpinLoopDetection.java

dartagnan/src/main/java/com/dat3m/dartagnan/program/processing/NonterminationDetection.java

hernanponcedeleon · 2025-02-10T14:45:23Z

dartagnan/src/main/java/com/dat3m/dartagnan/program/processing/NonterminationDetection.java

+        final LoopAnalysis.LoopIterationInfo lastIter = loop.iterations().get(loop.iterations().size() - 1);
+        final Event lastEvent = lastIter.getIterationEnd();
+
+        final Event bound = lastEvent.getSuccessor().getSuccessor();


Does the unrolling guarantee that the bound even is add 2+ after the loop end? If so, document this assumption here

I think we guarantee nothing really. While unrolling itself guarantees this, every other pass may break it.
I can add a comment saying that this is a "naive" check. But even if this fails, the code remains correct.

I was wrong. The code can accidentally treat a not-fully unrolled loop as fully unrolled and skip its instrumentation. This can result in wrong verdicts for non-termination.

Why are we filtering loops before the instrumentation? Is it purely for performance reasons (i.e. not to instrument loops unnecessarily) or the instrumentation relies on loops "passing" this filtering?

Can we instead search for the next bound event in the program and check if it belongs to the same loop?

The filtering is performance-only. No need to check bounded loops for non-termination.

We can search for the next bound event, but there is no way to 100% know if it belongs to the same loop without tagging the bound events somehow

hernanponcedeleon

Firs pass up to method encodeInfixSuffixDecomposition(). Will continue during the week

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

hernanponcedeleon · 2025-02-16T18:27:41Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+      - We assume that if the suffix is consistent with the infix and co/fr-fair, then it must be "strongly"
+        consistent. This may not be true and we could possibly report a liveness violation that is not consistently


What does "strongly consistent" mean?

This is a notion I have in my upcoming paper. I'm not sure how far I should explain the concepts (I cannot write the paper inside the comments :P).
Anyways, a suffix (extension) is strongly consistent if it is consistent with every possible prefix (modulo some properties known about the prefix). I can add that as a short explanation.

It seems I already added an explanation in the comments describing the class.

Where? "(3) Suffix must be strongly fair/consistent:"? The word "strongly" is there, but I still do not understand what this is supposed to mean

Well, the explanation of what this means is given exactly by the points after :).
For the most part it boils down to the fact that the suffix cannot really interact with the prefix, even if it was consistent(!).
That is why we require "strong" consistency which guarantees that not only the finite execution we currently see is consistent but that it also stays consistent when we append the suffix repeatedly.

guarantees that not only the finite execution we currently see is consistent but that it also stays consistent when we append the suffix repeatedly.

I find this much informative that the current We assume that if the suffix is consistent with the infix and co/fr-fair, then it must be "strongly" consistent

Sure it is. But at some point I'm going to write a whole paper in the comments :).
I will add one more line of explanation.

hernanponcedeleon · 2025-02-16T18:28:06Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+        repeatable. Fixing this would require additional checks relative to the memory model, possibly requiring
+        encoding of the memory model or native handling in CAAT.
+
+     TODO: We have not considered uninit reads, i.e., reads without rf-edges in the implementation.


What are the consequences of this?

I haven't thought this through, but my gut-feeling is that a suffix could possibly read the initial value although it is not co-maximal (because there are no co-edges that witness non-maximality). This would result in a fr-edge from suffix into prefix and therefore violating strong consistency/fairness.

EDIT: Just to be clear about the consequence: We could report FAIL although the non-terminating execution is actually unfair.

We could report FAIL although the non-terminating execution is actually unfair.

Please at this as the last sentence of the TODO

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

hernanponcedeleon · 2025-02-16T18:58:43Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+
+        }
+
+        // TODO: Check other types of events as well.


Missing to detect equivalence of other methods would just make this analysis less precise, right? I.e. we might miss to detect some non-termination

No, currently it is the opposite: without the check it considers events equivalent rather than not equivalent.
For example, it will consider all fences equivalent, even if their tagging mismatches. The same is true for all other kinds of events.

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

hernanponcedeleon · 2025-02-18T07:49:11Z

@ThomasHaas please rebase and fix the conflicts

# Conflicts: # dartagnan/src/main/java/com/dat3m/dartagnan/program/processing/CoreCodeVerification.java # dartagnan/src/test/resources/VULKAN-Liveness-Fair-expected.csv

hernanponcedeleon

Another pass up to "Strong suffix extension encoding"

hernanponcedeleon · 2025-02-18T08:21:47Z

benchmarks/nontermination/nontermination_asymmetric.c

+
+void *thread(void *unused)
+{
+    __VERIFIER_loop_bound(5);


you are missing an #include dat3m.h. Similar in other benchmarks

hernanponcedeleon · 2025-02-18T08:23:47Z

dartagnan/src/main/java/com/dat3m/dartagnan/configuration/OptionNames.java

@@ -49,6 +49,7 @@ public class OptionNames {
    public static final String DYNAMIC_SPINLOOP_DETECTION = "program.processing.spinloops";
    public static final String PROPAGATE_COPY_ASSIGNMENTS = "program.processing.propagateCopyAssignments";
    public static final String REMOVE_ASSERTION_OF_TYPE = "program.processing.skipAssertionsOfType";
+    public static final String NONTERMINATION_INSTRUMENTATION = "program.processing.nonTerm";


We are already very verbose on the option names; why not program.processing.nonTermination?

hernanponcedeleon · 2025-02-18T08:29:47Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/PropertyEncoder.java

-        return bmgr.and(exitReached, bmgr.not(encodeBoundEventExec()));
+        final BooleanFormula terminated = program.getThreadEventsWithAllTags(Tag.NONTERMINATION).stream()
+                .map(CondJump.class::cast)
+                .map(jump -> bmgr.not(bmgr.and(context.jumpCondition(jump), context.execution(jump))))


Bound events are also tagged as NONTERMINATION and as their condition is trivially true (they are gotos), the previous encoding is supersed by this one, correct?

What about other events tagged by NONTERMINATION? Is it always guaranteed that if they jumped, then they did not terminate?

Bound events are also tagged as NONTERMINATION and as their condition is trivially true (they are gotos), the previous encoding is supersed by this one, correct?

Yes.

What about other events tagged by NONTERMINATION? Is it always guaranteed that if they jumped, then they did not terminate?

Tag.NONTERMINATION should designate - as its name says - executions that did not terminate (yet). If this is not the case, then the events are incorrectly marked. Currently, this is the case for loop bound events, spin loop events, and the events placed by the new pass.
That being said, we exclusively use it for loop-induced nontermination and not for barrier-induced one.

My question is: in a jump that is tagged as non-terminated, non-termination requires (1) only execution (as with bound events), (2) execution + taking the jump, or (3) execution + not taking the jump?

The jump needs to be taken (which is always true for unconditional jumps that are executed).

hernanponcedeleon · 2025-02-18T08:30:54Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/PropertyEncoder.java

-        return new LivenessEncoder().encodeLivenessBugs();
+    private TrackableFormula encodeNontermination() {
+        final BooleanFormula hasNontermination = new NonTerminationEncoder(context.getTask(), context).encodeNontermination();
+        return new TrackableFormula(context.getBooleanFormulaManager().not(LIVENESS.getSMTVariable(context)), hasNontermination);


I can take care of updating vsyncer once we release a new dartagnan and I change the used version there.

hernanponcedeleon · 2025-02-18T08:41:16Z

dartagnan/src/main/java/com/dat3m/dartagnan/program/processing/NonterminationDetection.java

+        final LoopAnalysis.LoopIterationInfo lastIter = loop.iterations().get(loop.iterations().size() - 1);
+        final Event lastEvent = lastIter.getIterationEnd();
+
+        final Event bound = lastEvent.getSuccessor().getSuccessor();


Why are we filtering loops before the instrumentation? Is it purely for performance reasons (i.e. not to instrument loops unnecessarily) or the instrumentation relies on loops "passing" this filtering?

Can we instead search for the next bound event in the program and check if it belongs to the same loop?

hernanponcedeleon · 2025-02-18T12:19:02Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+            - Prefix stores must be co-before suffix stores
+            - Only suffix reads can read from suffix stores, prefix/infix reads can not.
+            - Suffix reads can only read from infix/suffix or from co-maximal stores in the prefix,
+              if they access an address not stored to by infix/suffix.


isn't this line guaranteed by the fact that if you read from prefix, it is co-maximal?

It does depend on how you read the sentence. I meant that the stores are co-maximal within the prefix, which by itself does not exclude the possibility that there are stores in the infix/suffix that are co-before/after the prefix one.
With some detailed analysis of the cases, it is possible to flatout require that the suffix only reads from globally co-maximal prefix stores.
I exploit this fact in the encoding.

We have already a rather "fix/standard" meaning of what "co-maximal" means. I would rather say Suffix reads can only read from infix/suffix or from the last store in the prefix to the corresponding address

hernanponcedeleon · 2025-02-18T12:22:12Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+      - We assume that if the suffix is consistent with the infix and co/fr-fair, then it must be "strongly"
+        consistent. This may not be true and we could possibly report a liveness violation that is not consistently


Where? "(3) Suffix must be strongly fair/consistent:"? The word "strongly" is there, but I still do not understand what this is supposed to mean

hernanponcedeleon · 2025-02-18T12:24:25Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+        repeatable. Fixing this would require additional checks relative to the memory model, possibly requiring
+        encoding of the memory model or native handling in CAAT.
+
+     TODO: We have not considered uninit reads, i.e., reads without rf-edges in the implementation.


We could report FAIL although the non-terminating execution is actually unfair.

Please at this as the last sentence of the TODO

hernanponcedeleon · 2025-02-18T12:43:30Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+    // FIXME: This is likely going to cause problems (wrong result) with executions where some thread is stuck in a loop
+    //  and another in a barrier. We could replace the code to check if ALL threads are stuck at a control-barrier
+    //  to avoid such wrong results.


Checking that ALL threads are stuck sounds wrong to me. If we have two sets of threads, each group synchronizing on a different barrier, if one group properly sync and the other not, we still want to report a violation.

I mean that we check if all non-terminated threads are stuck in a barrier. Then if one group properly synchronizes, it will terminate or get stuck in the next barrier.
The idea of checking that all non-terminated threads are stuck in a barrier is that we do explicitly avoid these problematic cases of mixed non-termination at the cost of completeness.

Ok, now it is clearer, but it would still change to We could replace the code to check if ALL stuck threads are stuck at a control-barrier to avoid such wrong results.

hernanponcedeleon · 2025-02-18T19:01:01Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+
+    // Encodes the basic properties of the infix-suffix matching relation.
+    // The semantics of what a matching actually implies is done by the above methods.
+    // NOTE: We do


broken sentence

hernanponcedeleon · 2025-02-23T16:04:26Z

dartagnan/src/main/java/com/dat3m/dartagnan/encoding/NonTerminationEncoder.java

+    // Internal classes
+
+    /*
+        - A (possibly nonterminating) "Loop" contains a list of "NonterminationCase"s.


How can more than one iteration be non-terminating? Or is it that you consider any iteration after the non terminating also non terminating?

It's not more than one iteration, but there can be multiple ways in which a loop does not terminate. There are different iterations that can trigger a non-teminating situation and even multiple possiblities within a single iteration.
For example, if some loop/iteration is conditionally side-effect-free, then it may fail to terminate due to side-effect-free spinning (spinloop-tagged jump event) or due to side-effect-ful non-progress (other, nontermination-tagged jump).

Implementation-wise, the idea is that a single loop has special jump events tagged by Tag.NONTERMINATION to designate where non-termination could occur. Every such event is a "nontermination case" of the loop.

ThomasHaas added 3 commits November 7, 2024 12:08

Added new NonTerminationEncoder that can reason over side-effectful n…

48e40bf

…on-termination

Added 5 new side-effectful nontermination tests.

78caf43

Updated expected values in LivenessTest for existing tests that now show liveness violations (from UNKNOWN to FAIL)

Merge branch 'refs/heads/development' into non-termination

112ed0c

Updated the new Nontermination tests, mainly to be (almost) race-free

2150e68

Fixed Nontermination verdict if nontermination was caused due to assertion failure. Updated expected outcomes of LivenessTest caused by the above change.

ThomasHaas mentioned this pull request Nov 9, 2024

Add support for encoding tuples (Tuple theory) #775

Merged

ThomasHaas added 3 commits November 10, 2024 21:04

Added new NonTerminationEncoder that can reason over side-effectful n…

d663e54

…on-termination

Added 5 new side-effectful nontermination tests.

5257846

Updated expected values in LivenessTest for existing tests that now show liveness violations (from UNKNOWN to FAIL)

Updated the new Nontermination tests, mainly to be (almost) race-free

5200c69

Fixed Nontermination verdict if nontermination was caused due to assertion failure. Updated expected outcomes of LivenessTest caused by the above change.

hernanponcedeleon force-pushed the non-termination branch from 2150e68 to 5200c69 Compare November 10, 2024 20:04

ThomasHaas added 3 commits November 11, 2024 18:06

Merge remote-tracking branch 'origin/non-termination' into non-termin…

84d91d2

…ation

Merge branch 'refs/heads/development' into non-termination

57fb307

Merge branch 'refs/heads/development' into non-termination

3312d61

Merge branch 'refs/heads/development' into non-termination

90ce2b8

ThomasHaas mentioned this pull request Nov 22, 2024

Improve spinloop detection #786

Merged

ThomasHaas added 3 commits December 9, 2024 12:46

Merge branch 'refs/heads/development' into non-termination

8d0ca46

Minor changes to nontermination_weak.c benchmark

768b090

Added new StateSnapshot event for instrumentation of non-termination …

0e852a1

…detection: this removes a wrong verdict related to SCCP removing the whole loop body. Added new test related to above issue. Minor updates to related code.

hernan-poncedeleon added 2 commits January 5, 2025 20:56

Add NonUniformBarrier test

6f5d60b

Enable more forward progress tests

bda6540

ThomasHaas added 3 commits January 15, 2025 14:54

Merge branch 'refs/heads/development' into non-termination

a2cb70e

Added handling of fairness for RMWStoreExclusive (WIP)

e300c5b

Added consideration of ControlBarriers in non-termination (WIP)

Merge remote-tracking branch 'origin/non-termination' into non-termin…

752a68c

…ation

hernan-poncedeleon and others added 11 commits February 3, 2025 15:35

Update expected CADP results using the weak fairness variants

40624e9

Add filter spec to spirv tests (#795)

96e6bed

Use alignment information in VisitorLlvm.visitAllocaInst() (#796)

1f60258

Draft of improved NonTerminationEncoder (WIP)

8006d5b

Fixed bug due to non-unique variable names in encoding.

78a11ba

- Renamed NonTerminationEncoderNew to NonTerminationEncoder (removed …

7cef8eb

…old version) - Deleted old LivenessEncoder code

Added NonterminationDetection pass to instrument detection of complex…

d0a2a3a

… (asymmetric) non-termination. Cleaned up NonTerminationEncoder and updated comments.

Added SourceLocation information to NonterminationDetection instrumen…

d61f89f

…tation for better error reporting

Added more complex liveness unit tests

8b275dd

Increased Vulkan Liveness Test bounds to detect all non-termination

fc8e826

Merge branch 'refs/heads/development' into non-termination

e276384

ThomasHaas changed the title ~~Side-effectful Nontermination [DRAFT]~~ Side-effectful Nontermination Feb 7, 2025

ThomasHaas and others added 4 commits February 7, 2025 18:02

Fix program_spec for Litmus tests to avoid considering non-terminatin…

5d123b6

…g executions.

Comment unsupported HSA tests

8e97c09

Comment unsupported Obe tests

6c9eb1f

Comment unsupported fair tests

9a467c1

hernanponcedeleon reviewed Feb 10, 2025

View reviewed changes

hernanponcedeleon reviewed Feb 16, 2025

View reviewed changes

Refactor & clean-up

0b7e670

Merge branch 'refs/heads/development' into non-termination

d44ce40

# Conflicts: # dartagnan/src/main/java/com/dat3m/dartagnan/program/processing/CoreCodeVerification.java # dartagnan/src/test/resources/VULKAN-Liveness-Fair-expected.csv

hernanponcedeleon reviewed Feb 18, 2025

View reviewed changes

hernanponcedeleon reviewed Feb 23, 2025

View reviewed changes

		- We assume that if the suffix is consistent with the infix and co/fr-fair, then it must be "strongly"
		consistent. This may not be true and we could possibly report a liveness violation that is not consistently

Side-effectful Nontermination #772

Are you sure you want to change the base?

Side-effectful Nontermination #772

Conversation

ThomasHaas commented Nov 7, 2024 • edited Loading

ThomasHaas commented Nov 7, 2024 • edited Loading

hernanponcedeleon commented Nov 10, 2024

ThomasHaas commented Nov 10, 2024

hernanponcedeleon commented Nov 11, 2024

ThomasHaas commented Nov 11, 2024

ThomasHaas commented Nov 11, 2024 • edited Loading

hernanponcedeleon commented Nov 16, 2024

ThomasHaas commented Nov 16, 2024

ThomasHaas commented Dec 17, 2024

hernanponcedeleon commented Dec 18, 2024

ThomasHaas commented Dec 18, 2024

ThomasHaas commented Jan 15, 2025

hernanponcedeleon commented Jan 16, 2025

ThomasHaas commented Feb 7, 2025 • edited Loading

hernanponcedeleon commented Feb 7, 2025

hernanponcedeleon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hernanponcedeleon left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ThomasHaas Feb 18, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ThomasHaas Feb 16, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hernanponcedeleon commented Feb 18, 2025

hernanponcedeleon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ThomasHaas commented Nov 7, 2024 •

edited

Loading

ThomasHaas commented Nov 7, 2024 •

edited

Loading

ThomasHaas commented Nov 11, 2024 •

edited

Loading

ThomasHaas commented Feb 7, 2025 •

edited

Loading

hernanponcedeleon left a comment •

edited

Loading

ThomasHaas Feb 18, 2025 •

edited

Loading

ThomasHaas Feb 16, 2025 •

edited

Loading