This issue was copied from checkedc/checkedc-clang#1028
The crash happens in some scenarios where a goto statement has to be backpatched with CFGLifetimeEnds elements. During CFG construction, the statements enclosed within a compound statement are iterated through in reverse (i.e., last statement is processed first). In the case where the target of the goto statement occurs earlier than the goto, the goto statement is processed before its target labeled statement is processed. Now, the variables that go out of scope when the goto is executed depend on the position of the target of the goto statement. Therefore, the LifetimeEnds CFGElements for these variables, in the case mentioned above, have to be backpatched into the basic block containing the goto only after the target of the goto has been processed.
The bug is in determining the set of variables that go out of scope, while performing the backpatching. Consider the following block structure:
{
<variable A declared>
{
<variable B declared>
label:
......
}
<variable C declared>
{
<variable D declared>
goto label
}
<variable E declared>
}
The variables that go out of scope when the goto is executed are: D and C. The above block structure represents the general case that is not handled during backpatching. The cases that are handled are when the scope of the goto target is an ancestor of the scope that contains the goto statement in the tree of scopes within the function.
This issue was copied from checkedc/checkedc-clang#1028
The crash happens in some scenarios where a
gotostatement has to be backpatched withCFGLifetimeEndselements. During CFG construction, the statements enclosed within a compound statement are iterated through in reverse (i.e., last statement is processed first). In the case where the target of thegotostatement occurs earlier than thegoto, thegotostatement is processed before its target labeled statement is processed. Now, the variables that go out of scope when thegotois executed depend on the position of the target of thegotostatement. Therefore, theLifetimeEndsCFGElementsfor these variables, in the case mentioned above, have to be backpatched into the basic block containing thegotoonly after the target of thegotohas been processed.The bug is in determining the set of variables that go out of scope, while performing the backpatching. Consider the following block structure:
The variables that go out of scope when the
gotois executed are:DandC. The above block structure represents the general case that is not handled during backpatching. The cases that are handled are when the scope of thegototarget is an ancestor of the scope that contains thegotostatement in the tree of scopes within the function.