WI #2039 Compute cyclic call using transitive closure. #2052

mayanje · 2021-10-21T14:18:32Z

What have been done

We noticed that all cyclic perform call chains were not detected by the curent implementation: a -> b -> c -> a was not detected.
Thus as we know all direct calls, that is to say we know: a -> b, b -> c and c -> a
The idea here is to compute the transitive closure of all known direct calls.
So we compute the transitive closure of the direct call relation which is know as a transitive relation: a->b and b->c implies a->c
During the transitive closure computation, we compute the call chains of cycles in parallel.

fm-117 · 2021-10-22T09:42:49Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.Paragraph.cs

@@ -60,7 +60,7 @@ public override IEnumerator<Sentence> GetEnumerator()

            public override void AccumulateSentencesThrough(List<Sentence> sentences, Procedure end, out Procedure last)
            {
-                if (_sentences != null)
+                if (_sentences != null && sentences != null)


I disagree with this change, sentences is an accumulator list given by the caller of AccumulateSentencesThrough. The purpose of the method is to fill this list so it does not make sense to allow a null reference for this arg.

done in 9bf7eb1

fm-117 · 2021-10-22T09:49:21Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

+        /// <summary>
+        /// Add a Direct Call to the Call Relation. 
+        /// For a PERFORM THRU all intermediate procedure are added to the relation.
+        /// </summary>
+        /// <param name="caller">The caller of the PERFOM procedure</param>
+        /// <param name="callee">The PERFOM procedure called</param>
+        /// <param name="callRelation">CALL Relation</param>
+        /// <param name="callRelationDomain">The domain of the call relation</param>
+        private void AddDirectCallRelation(PerformProcedure performCaller, Procedure caller, PerformProcedure callee, 
+            Dictionary<Procedure, Tuple<PerformProcedure, List<Node>, HashSet<Procedure>>> callRelation,
+            HashSet<Procedure> callRelationDomain)


Naming: what is a 'CALL relation' ? This is not a good naming choice because it looks like it refers to the Cobol CALL instruction but here we are dealing with PERFORMs only.

What is the first element in the tuple stored for each procedure in the dictionary ? If it is the caller of the said procedure then there is a problem because there can be multiple PERFORMs calling the same procedure in the whole program. Also, the second item of the tuple should be a list of PerformProcedure (not Node).

I think this method can be greatly simplified. Instead of doing the whole procedure resolution process again (finding the procedures targeted in a perform and the associated sentences) we could simply attach the resolved procedures and the list of sentences directly into BasicBlockForNodeGroup instance, at resolve time in ResolvePendingPERFORMProcedure. And then go over the list of groups to build the 'CALL relation' dictionary. The current procedure can also be attached to a Sentence instance very easily at build time so no need to compute it again.

done in 9bf7eb1

fm-117 · 2021-10-22T12:18:00Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

+            }
+            callRelationDomain.Add(caller);
+
+            void addToRelation(Procedure _calleeProcedure, PerformProcedure _callee)


Naming: AddToRelation, first parameter should be called simply procedure to avoid conflict with calleeProcedure and second parameter can be removed as the local function ccan capture the callee parameter.

do,e in c5f891a

fm-117 · 2021-10-22T12:19:12Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

+                if (!callRelation.TryGetValue(caller, out var callees))
+                {
+                    callees = new Tuple<PerformProcedure, List<Node>, HashSet<Procedure>>(performCaller, new List<Node>(), new HashSet<Procedure>());
+                    callRelation[caller] = callees;


This is an Add operation so better use callRelation.Add(caller, callees);

done in c5f891a

fm-117 · 2021-10-22T12:20:38Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

+                if (!callees.Item3.Contains(_calleeProcedure))
+                {
+                    callees.Item3.Add(_calleeProcedure);                    
+                }


This is a HashSet, simply call Add.

don in c5f891a

fm-117 · 2021-10-22T13:17:31Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

@@ -1056,6 +1248,7 @@ void StoreSentences(IEnumerable<Sentence> sentences)
                        if (block is BasicBlockForNodeGroup group0)
                        {
                            isPerform = true; //To avoid a second dynamic cast
+                            AddDirectCallRelation(p, currentProcedure, (PerformProcedure)group0.Instructions.Last.Value, callRelation, callRelationDomain);

                            //Is there a recursion in the graph ?


This part (Line 1253 to 1262) can now be removed ?

Yes done in d80af72

fm-117 · 2021-10-22T13:18:42Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

                foreach (var sentence in sentences)
                {
+                    var currentProcedure = n >= procedures.Count ? procedures[procedures.Count - 1] : procedures[n++];


Not needed, store the current procedure inside each Sentence instance at build time.

done in 9bf7eb1

fm-117 · 2021-10-22T14:06:53Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

+                }
+            }
+
+            void dfs(Procedure a)


Could you explain the algorithm ? What does the N dictionary contain ? What does "an entry point of a calculated component" mean ?

Ok this algorithm is not my invention, it is based on J. Eve, R. Kurki-Suonio transitive closure calculation algorithm, you can google on it, there are many adaptation. I implemented also an adaptation for gathering perform chain path.
I added few comments on it in 9bf7eb1

Do we need it ? What about this much simpler algorithm ?

public static Dictionary<N, HashSet<N>> TransitiveClosure<N>(Dictionary<N, HashSet<N>> graph) { var transitiveClosure = new Dictionary<N, HashSet<N>>(); var root = graph.FirstOrDefault().Key; if (root != null) { ComputeDirectAndIndirectSuccessors(root); } return transitiveClosure; HashSet<N> ComputeDirectAndIndirectSuccessors(N node) { if (transitiveClosure.TryGetValue(node, out var result)) { return result; } var directSuccessors = graph[node]; result = new HashSet<N>(directSuccessors); transitiveClosure.Add(node, result); foreach (var directSuccessor in directSuccessors) { foreach (var indirectSuccessor in ComputeDirectAndIndirectSuccessors(directSuccessor)) { result.Add(indirectSuccessor); } } return result; } }

Ok here is the url of the Eve paper: http://i.stanford.edu/pub/cstr/reports/cs/tr/75/508/CS-TR-75-508.pdf
It seems to me that the algorithm that you suggest is in the best case in O(n^2) and in the worst case in O(n^4) because it can implies 4 foreach loops.
In the paper it is say that computing transitive closure is in the best case be in O(n^2) and in the worst case in O(n^3), and it is said in the paper that the algorithm in the paper usually works in O(n) to O(n^2) where n is the number of vertices.

And I don't see in your algorithm where to compute perform call path chain.

Yes it was an attempt at writing a simpler algorithm to help understanding the transitive closure. Anyway my code does not work properly for cyclic graphs so we can forget about it.

However the main question still remains, do we need to compute the full closure ? Our goal is to gather cyclic chains but not necessarily building the transitive closure of the perform call graph.

My answer is yes we need to compute the full transitive closure, it is this computation that discovers Strongly connected components (that is to say cyclic chains).

fm-117 · 2021-11-03T11:10:09Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+            /// <summary>
+            /// All target sentences
+            /// </summary>
+            internal List<Sentence> Sentences { get; private set; }
+            /// <summary>
+            /// All target procedures.
+            /// </summary>
+            internal List<Procedure> Procedures { get; private set; }


You can remove private setters, they are redundant

fm-117 · 2021-11-03T11:11:47Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+        /// Cache of PerformTarget instances already calculated for a Perform procedure 
+        /// </summary>
+        private Dictionary<PerformProcedure, PerformTarget> _performTargetCache;
+        private PerformTarget ComputePerformTarget(PerformProcedure p, SectionNode sectionNode)


naming, this is more like GetPerformTarget since we do not compute the target each time the method is called.

done in 4b969b9

fm-117 · 2021-11-03T11:12:11Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+        {
+            if (_performTargetCache == null)
+                _performTargetCache = new Dictionary<PerformProcedure, PerformTarget>();
+            if (_performTargetCache.TryGetValue(p, out var target)) {


Java indent style

done in 4b969b9

fm-117 · 2021-11-03T11:13:18Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+    public partial class ControlFlowGraphBuilder<D>
+    {
+        /// <summary>
+        /// PerfomrTarget class to capture target sentences and procedures from a PERFORM instruction.


Typo: PerformTarget class

done in 4b969b9

fm-117 · 2021-11-03T11:18:19Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+
+            Node procedureNode = ResolveProcedure(p, sectionNode, procedureReference);
+            if (procedureNode == null)
+                return null;


This remark goes for all the return null; instructions in this method. We should actually store the null value inside the dictionary to prevent attempting resolving the target multiple times.
Even better: we should create a special instance Unresolved with empty sentences and procedures to use whenever a PerformProcedure cannot have its target properly resolved. This way the method would always return a non-null value.

I would say this an abnormal situation it should never happened, let's take it in account with an assert.

In fact calling an inexisting procedure is a semantic error, so no need to assert here, and simply return null here without storing such error value.

It is a semantic error but the CFG builder may run on semantically wrong programs. CFG building happens during the Node phase so at this point we may have unresolved procedures. Storing a null PerformTarget in the cache for such cases is required to avoid trying the resolution multiple times. The null-object pattern is useful for the callers of the method which won't have to bother with testing for null value but it is optional.

It is not a good practice to store null values for semantic error reason.

fm-117 · 2021-11-03T11:20:58Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+                int n = 0;
+                int currentProcedureNumber = procedure.Number;
+                while (currentProcedureNumber <= throughProcedure.Number)
+                {
+                    var currentProcedure = this.CurrentProgramCfgBuilder.AllProcedures[currentProcedureNumber];
+                    currentProcedure.AccumulateSentencesThrough(sentences, throughProcedure, out var lastProcedure);
+                    currentProcedureNumber = lastProcedure.Number + 1;
+                    procedures.Add(currentProcedure);
+                    while (n < sentences.Count)
+                    {
+                        sentences[n++].Procedure = currentProcedure;
+                    }
+                }


No need to track the current procedure using the n index. The Procedure property of each Sentence object can (and should) be set at construction time. See my previous remark in this PR to see how to do it.

done in 4b969b9

fm-117 · 2021-11-03T11:21:10Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+                        sentences[n++].Procedure = currentProcedure;
+                    }
+                }
+            } else 


Java indent style ?

done in 4b969b9

fm-117 · 2021-11-03T11:22:26Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.Sentence.cs

+            /// <summary>
+            /// The associated procedure
+            /// </summary>
+            internal Procedure Procedure { get; set; }


Should be read-only, set in constructor

It is set in PerformTarget

right done in 4b969b9

fm-117 · 2021-11-03T11:26:56Z

TypeCobol.Analysis/Resource.Designer.cs

@@ -1,10 +1,10 @@
 //------------------------------------------------------------------------------
 // <auto-generated>
-//     This code was generated by a tool.
-//     Runtime Version:4.0.30319.42000
+//     Ce code a été généré par un outil.


Strange the file is generated in French now ?

Maybe it's because I have a french version of VS2019

fm-117 · 2021-11-03T11:28:39Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

+            {
+                if (!callPerformRelation.TryGetValue(caller, out var callees))
+                {
+                    callees = new Tuple<PerformProcedure, List<Node>, HashSet<Procedure>>(performCaller, new List<Node>(), new HashSet<Procedure>());


List<Node> can be turned into List<PerformProcedure> if i recall correctly.

I would like, but it's because of ControlFlowGraph<N, D>.AddRecursivePerform(PerformProcedure perform, List recursiveJump)

smedilol · 2021-11-18T08:50:18Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformCallRelation.cs

+                }
+
+                // Depth First Search Traversal.
+                void dfs(Procedure a)


This last version of the code without Tuple is much clearer.
Can you use more meaningful name for variables?
Like procedure or at least proc instead of a for the name of the procedure.
Same remarks for variables : d, fa, b, nb, ...

Done in 35d0734

smedilol · 2021-11-18T08:53:57Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformCallRelation.cs

+                            int nb = Visited(b);
+                            if (nb == 0)


With my previous remarks on meaningful variable name, you could inline variable:

if (Visited(b)== 0)

Done in 35d0734

fm-117 · 2021-11-18T09:41:25Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+
+            Node procedureNode = ResolveProcedure(p, sectionNode, procedureReference);
+            if (procedureNode == null)
+                return null;


It is a semantic error but the CFG builder may run on semantically wrong programs. CFG building happens during the Node phase so at this point we may have unresolved procedures. Storing a null PerformTarget in the cache for such cases is required to avoid trying the resolution multiple times. The null-object pattern is useful for the callers of the method which won't have to bother with testing for null value but it is optional.

fm-117 · 2021-11-18T11:01:51Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

+                // Report Recursive PERFORM call
+                ReportRecursivePerformCall(performCallRelation);


As we have now a new mechanism to detect recursive PERFORMs, we can remove the RecursivityGroupSet property from BasicBlockForNodeGroup class. I've checked the code, it is now written only, never read.

Done in 35d0734

fm-117 · 2021-11-18T11:11:17Z

TypeCobol.Analysis/Graph/ControlFlowGraph.cs

@@ -226,7 +226,7 @@ internal void AddWrongOrderPerformThru(PerformProcedure performThru, N procedure
        /// </summary>
        /// <param name="perform">Perform node</param>
        /// <param name="recursiveJump">Recursive jump node</param>
-        internal void AddRecursivePerform(PerformProcedure perform, N recursiveJump)
+        internal void AddRecursivePerform(PerformProcedure perform, List<N> recursiveJump)


There is no need to check for the existence of the perform node entry in the dictionary now, we can call Add each time. The second parameter should be renamed also (but I can't find a proper name yet, it is not the cycle, it's all the perform reached through the one passed as first arg).

Done in 35d0734

fm-117 · 2021-11-18T11:50:28Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

-                                   this.CurrentProgramCfgBuilder.CurrentSection;
-
-            if (currentProcedure != null)
+            if (sentence.Procedure != null)


Now that I read it again, sentence.Procedure should never be null since we have a default root section.

Yep, there is a bug in presence of DECLARATIVE:
#2081

fm-117 · 2021-11-18T11:51:12Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

            //And finally relocate the Graph.
            RelocateBasicBlockForNodeGroupGraph(p, group, clonedBlocksIndexMap);

-            void StoreSentences(IEnumerable<Sentence> sentences)
+            void StoreSentences(PerformTarget target)


Parameter is not used, remove it please.

Done in 35d0734

fm-117 · 2021-11-22T10:30:55Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+            {
+                Node throughProcedureNode = ResolveProcedure(p, sectionNode, throughProcedureReference);
+                if (throughProcedureNode == null)
+                    return null;


The null value should be stored here also.

done in 49d4035

fm-117 · 2021-11-22T10:31:02Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+                {
+                    // the second procedure name is declared before the first one.
+                    this.Cfg.AddWrongOrderPerformThru(p, procedureNode, throughProcedureNode);
+                    return null;


And here too

done in 49d4035

smedilol · 2021-11-23T19:54:24Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformCallRelation.cs

+        /// Representation of Perform Call Relation. 
+        /// It is a dictionary which gives for each Procedure its Perform Call chain.
+        /// </summary>
+        private class PerformCallRelation : Dictionary<Procedure, PerformCallChain>


The inheritance from Dictionary disturbs me.
You are not extending the concept of Dictionary here but rather you want to use a Dictionary to store some information.

It is not an extension of the concept of Dictionary because Generic Type Variables <TKey, TValue> of the Dictionary base class are instantiated with <Procedure, PerformCallChain>types.

smedilol · 2021-11-23T19:59:53Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformCallRelation.cs

+
+namespace TypeCobol.Analysis.Cfg
+{
+    public partial class ControlFlowGraphBuilder<D>


Does it have to be in the class ControlFlowGraphBuilder ?
It seems to me that the transitive closure mechanism could be put aside the ControlFlowGraphBuilder.
I mean it can be called by ControlFlowGraphBuilder, but the mechanism could also be called later. Once the graph is fully calculated.

I think yes because only ControlFlowGraphBuilder knows how to discover direct perfrom calls. Once the graph is fully calculated direct perform calls context will be difficult to reproduce without retraversing the graph and analyzing each block to look for performs and perform targets..

smedilol · 2021-11-23T20:09:35Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformTarget.cs

+                foreach (var sentence in procedure)
+                {
+                    sentences.Add(sentence);
+                }


Suggested change

foreach (var sentence in procedure)

{

sentences.Add(sentence);

}

sentences.AddRange(procedure);

Yes done in 99deb05

smedilol · 2021-11-23T21:18:45Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.cs

-                                System.Diagnostics.Debug.Assert(offendingInstruction != null);
-                                this.Cfg.AddRecursivePerform(p, offendingInstruction);
-                            }
+                            AddDirectCallPerformRelation(p, currentProcedure, (PerformProcedure)group0.Instructions.Last.Value, performCallRelation);


If I understand correctly a BasicBlockForNodeGroup is only used for Perform.
Such block always contains only 1 instruction which is the PerformProcedure.
If this is correct, it'd be easier to understand this by creating a getter in BasicBlockForNodeGroup to retrieve the PerformProcedure.
This way, you don't have to understand how BasicBlockForNodeGroup is implemented to retrieve the PerformProcedure.

So this code in this class would become:

Suggested change

AddDirectCallPerformRelation(p, currentProcedure, (PerformProcedure)group0.Instructions.Last.Value, performCallRelation);

AddDirectCallPerformRelation(p, currentProcedure, block.PerformProcedure, performCallRelation);

Yes but this is a specialized knowledge whereas BasicBlockForNodeGroup is for a general purpose.

smedilol · 2021-11-24T20:22:02Z

TypeCobol.Analysis/Cfg/ControlFlowGraphBuilder.PerformCallRelation.cs

+            /// We browse the graph represented using the Call Relation, then we found during the visit cycles.
+            /// In the same time we compute the call chain.
+            /// </summary>
+            internal void TransitiveClosure()


It works but it seems we don't realy use the full capabilities of the CFG here. There is no use of SuccessorEdges.

Plus this algorithm only focus on cyclic perform call.
Why don't we try to detect all cyclic code? Like this:

procedure division. a. go to b. b. perform a.

There is also PR #2050 currently in progress with almost the same algorithm.
Why not use the DFS in this other PR to detect every cycle ?
If our internal quality tools only want to report perform cycle as error, then we can filter the result.
And we can report other cycles (cycles not only with perform) as warning as a bonus for developers.

Yes this will be an improvement because IBM compiler reports these warnings in such situation:

12 IGYCB7309-W There may be a loop from the "PERFORM" statement at "PERFORM (line 12.1)" to itself. 12 IGYCB7310-W The "PERFORM" statement at "PERFORM (line 12.1)" cannot reach its exit.

But it seems that qualis does not report such situation also.

But our parser report a CFG error like this:
--- Diagnostics ---
Line 12[13,21] <37, Warning, General> - Warning: Statement ' go to b' located at line 10, column 13 prevents this PERFORM statement to reach its exit.

Ok for such situation I agree, Abstract Interpretation is welcome to be very similar with IBM Compiler.

smedilol · 2021-11-24T20:25:08Z

TypeCobol.Analysis.Test/BasicCfgInstrs/CyclicPerformRecursive.diag

@@ -0,0 +1,11 @@
+--- Diagnostics ---
+Line 5[12,20] <37, Warning, General> - Warning: A recursive loop has been encountered while analyzing 'PERFORM a', recursive instruction is '    perform b' at line 9.


Isn't possible to report the full perform chain ?
Like perform a, Line 5 > perform b, Line 9 > perform c, Line 12 > perform a, Line 15?

With the current diagnostics, the Cobol developer have to manualy group error message together to understand what the cycle is.

In fact this the current way of reporting, but the Perform Call Chain contains all information to do that.

WI #2039 Compute cyclic call using transitive closure.

5b3c0d6

mayanje added the DataFlow label Oct 21, 2021

mayanje added this to the v1.6 milestone Oct 21, 2021

mayanje requested review from smedilol and fm-117 October 21, 2021 14:18

mayanje self-assigned this Oct 21, 2021

trafico-bot bot added the 🔍 Ready for Review Pull Request is not reviewed yet label Oct 21, 2021

fm-117 requested changes Oct 22, 2021

View reviewed changes

trafico-bot bot added ⚠️ Changes requested Pull Request needs changes before it can be reviewed again and removed 🔍 Ready for Review Pull Request is not reviewed yet labels Oct 22, 2021

WI #2039 Use PerformTarget class.

9bf7eb1

trafico-bot bot added 🔍 Ready for Review Pull Request is not reviewed yet and removed ⚠️ Changes requested Pull Request needs changes before it can be reviewed again labels Oct 29, 2021

mayanje added 2 commits November 2, 2021 17:34

WI #2039 Remove old diagnostics

d80af72

WI #2039 Change review

c5f891a

mayanje requested a review from fm-117 November 3, 2021 10:41

fm-117 requested changes Nov 3, 2021

View reviewed changes

trafico-bot bot added ⚠️ Changes requested Pull Request needs changes before it can be reviewed again and removed 🔍 Ready for Review Pull Request is not reviewed yet labels Nov 3, 2021

WI #2039 Change review

4b969b9

trafico-bot bot added 🔍 Ready for Review Pull Request is not reviewed yet and removed ⚠️ Changes requested Pull Request needs changes before it can be reviewed again labels Nov 12, 2021

mayanje requested a review from fm-117 November 16, 2021 10:38

WI #2039 Refactor the Perform Call relation.

5ce94ee

smedilol suggested changes Nov 18, 2021

View reviewed changes

trafico-bot bot added ⚠️ Changes requested Pull Request needs changes before it can be reviewed again and removed 🔍 Ready for Review Pull Request is not reviewed yet labels Nov 18, 2021

fm-117 requested changes Nov 18, 2021

View reviewed changes

WI #2039 Change Review

35d0734

trafico-bot bot added the 🔍 Ready for Review Pull Request is not reviewed yet label Nov 18, 2021

trafico-bot bot removed the ⚠️ Changes requested Pull Request needs changes before it can be reviewed again label Nov 18, 2021

mayanje requested review from smedilol and fm-117 November 19, 2021 07:53

fm-117 requested changes Nov 22, 2021

View reviewed changes

WI #2039 Change review

49d4035

mayanje requested a review from fm-117 November 22, 2021 16:40

smedilol suggested changes Nov 25, 2021

View reviewed changes

WI #2039 Change review

99deb05

fm-117 mentioned this pull request Dec 16, 2021

2039 compute jump targets #2099

Open

		// Report Recursive PERFORM call
		ReportRecursivePerformCall(performCallRelation);

	AddDirectCallPerformRelation(p, currentProcedure, (PerformProcedure)group0.Instructions.Last.Value, performCallRelation);
	AddDirectCallPerformRelation(p, currentProcedure, block.PerformProcedure, performCallRelation);

		@@ -0,0 +1,11 @@
		--- Diagnostics ---
		Line 5[12,20] <37, Warning, General> - Warning: A recursive loop has been encountered while analyzing 'PERFORM a', recursive instruction is ' perform b' at line 9.

WI #2039 Compute cyclic call using transitive closure. #2052

Are you sure you want to change the base?

WI #2039 Compute cyclic call using transitive closure. #2052

Conversation

mayanje commented Oct 21, 2021 • edited

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

mayanje Nov 3, 2021 • edited

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

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

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

mayanje Nov 30, 2021 • edited

Choose a reason for hiding this comment

mayanje commented Oct 21, 2021 •

edited

mayanje Nov 3, 2021 •

edited

mayanje Nov 30, 2021 •

edited