You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

316 lines
25 KiB

/* @generated */
digraph cfg {
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_1" [label="1: Start assign_conditional\nFormals: a:int\nLocals: 0$?%__sil_tmpSIL_temp_conditional___n$1:int& v2:int v1:int \n " color=yellow style=filled]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_1" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_12" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_2" [label="2: Exit assign_conditional \n " color=yellow style=filled]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_3" [label="3: Return Stmt \n n$0=*&v1:int [line 23, column 10]\n " shape="box"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_3" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_4" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_4" [label="4: Return Stmt \n *&return:int=n$0 [line 23, column 3]\n " shape="box"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_4" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_2" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_5" [label="5: + \n " ]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_5" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_10" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_6" [label="6: Prune (true branch, boolean exp) \n n$2=*&a:int [line 22, column 4]\n PRUNE(n$2, true); [line 22, column 4]\n " shape="invhouse"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_6" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_8" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_7" [label="7: Prune (false branch, boolean exp) \n n$2=*&a:int [line 22, column 4]\n PRUNE(!n$2, false); [line 22, column 4]\n " shape="invhouse"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_7" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_9" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_8" [label="8: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$1:int&=&v1 [line 22, column 4]\n " shape="box"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_8" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_5" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_9" [label="9: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$1:int&=&v2 [line 22, column 4]\n " shape="box"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_9" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_5" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_10" [label="10: BinaryOperatorStmt: Assign \n n$3=*&0$?%__sil_tmpSIL_temp_conditional___n$1:int& [line 22, column 4]\n *n$3:int=1 [line 22, column 3]\n " shape="box"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_10" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_3" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_11" [label="11: DeclStmt \n VARIABLE_DECLARED(v2:int); [line 21, column 3]\n *&v2:int=0 [line 21, column 3]\n " shape="box"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_11" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_6" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_11" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_7" ;
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_12" [label="12: DeclStmt \n VARIABLE_DECLARED(v1:int); [line 21, column 3]\n *&v1:int=0 [line 21, column 3]\n " shape="box"]
"assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_12" -> "assign_conditional#6602154438630029026.d4adbdaf8d08f61e93de4faf3d45d8ab_11" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_1" [label="1: Start choose_lvalue\nFormals: a:int\nLocals: v3:int 0$?%__sil_tmpSIL_temp_conditional___n$1:int& v2:int v1:int \n " color=yellow style=filled]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_1" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_13" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_2" [label="2: Exit choose_lvalue \n " color=yellow style=filled]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_3" [label="3: Return Stmt \n n$0=*&v3:int [line 11, column 10]\n " shape="box"]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_3" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_4" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_4" [label="4: Return Stmt \n *&return:int=n$0 [line 11, column 3]\n " shape="box"]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_4" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_2" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_5" [label="5: + \n " ]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_5" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_11" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_6" [label="6: Prune (true branch, boolean exp) \n n$2=*&a:int [line 10, column 12]\n PRUNE(n$2, true); [line 10, column 12]\n " shape="invhouse"]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_6" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_8" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_7" [label="7: Prune (false branch, boolean exp) \n n$2=*&a:int [line 10, column 12]\n PRUNE(!n$2, false); [line 10, column 12]\n " shape="invhouse"]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_7" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_9" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_8" [label="8: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$1:int&=&v1 [line 10, column 12]\n " shape="box"]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_8" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_5" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_9" [label="9: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_temp_conditional___n$1:int&=&v2 [line 10, column 12]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_9" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_5" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_10" [label="10: DeclStmt \n VARIABLE_DECLARED(v3:int); [line 10, column 3]\n " shape="box"]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_10" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_6" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_10" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_7" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_11" [label="11: DeclStmt \n n$3=*&0$?%__sil_tmpSIL_temp_conditional___n$1:int& [line 10, column 12]\n n$4=*n$3:int [line 10, column 12]\n *&v3:int=n$4 [line 10, column 3]\n " shape="box"]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_11" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_3" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_12" [label="12: DeclStmt \n VARIABLE_DECLARED(v2:int); [line 9, column 3]\n *&v2:int=1 [line 9, column 3]\n " shape="box"]
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_12" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_10" ;
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_13" [label="13: DeclStmt \n VARIABLE_DECLARED(v1:int); [line 9, column 3]\n *&v1:int=0 [line 9, column 3]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_13" -> "choose_lvalue#6868643882447178722.7e0e06006a6e1baaef3aab18bce2b8d2_12" ;
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_1" [label="1: Start choose_rvalue\nFormals: a:int\nLocals: v3:int v1:int \n " color=yellow style=filled]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_1" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_11" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_2" [label="2: Exit choose_rvalue \n " color=yellow style=filled]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_3" [label="3: Return Stmt \n n$0=*&v3:int [line 17, column 10]\n " shape="box"]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_3" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_4" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_4" [label="4: Return Stmt \n *&return:int=n$0 [line 17, column 3]\n " shape="box"]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_4" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_2" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_5" [label="5: + \n " ]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_5" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_3" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_6" [label="6: Prune (true branch, boolean exp) \n n$1=*&a:int [line 16, column 12]\n PRUNE(n$1, true); [line 16, column 12]\n " shape="invhouse"]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_6" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_8" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_7" [label="7: Prune (false branch, boolean exp) \n n$1=*&a:int [line 16, column 12]\n PRUNE(!n$1, false); [line 16, column 12]\n " shape="invhouse"]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_7" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_9" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_8" [label="8: ConditionalStmt Branch \n n$2=*&v1:int [line 16, column 16]\n *&v3:int=n$2 [line 16, column 12]\n " shape="box"]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_8" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_5" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_9" [label="9: ConditionalStmt Branch \n *&v3:int=1 [line 16, column 12]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_9" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_5" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_10" [label="10: DeclStmt \n VARIABLE_DECLARED(v3:int); [line 16, column 3]\n " shape="box"]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_10" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_6" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_10" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_7" ;
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_11" [label="11: DeclStmt \n VARIABLE_DECLARED(v1:int); [line 15, column 3]\n *&v1:int=0 [line 15, column 3]\n " shape="box"]
"choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_11" -> "choose_rvalue#5692558402038768020.7de6e1902b5c331a5715ba3f0f51e47e_10" ;
"div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_1" [label="1: Start div0_assign_conditional_bad\nFormals: \nLocals: \n " color=yellow style=filled]
"div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_1" -> "div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_3" ;
"div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_2" [label="2: Exit div0_assign_conditional_bad \n " color=yellow style=filled]
"div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_3" [label="3: Return Stmt \n n$0=_fun_assign_conditional(0:int) [line 39, column 48]\n " shape="box"]
"div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_3" -> "div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_4" ;
"div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_4" [label="4: Return Stmt \n *&return:int=(1 / n$0) [line 39, column 37]\n " shape="box"]
"div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_4" -> "div0_assign_conditional_bad#15392728490966978909.59445a1ff0409f58853678ecb2a0eeb6_2" ;
"div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_1" [label="1: Start div0_choose_lvalue_bad\nFormals: \nLocals: \n " color=yellow style=filled]
"div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_1" -> "div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_3" ;
"div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_2" [label="2: Exit div0_choose_lvalue_bad \n " color=yellow style=filled]
"div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_3" [label="3: Return Stmt \n n$0=_fun_choose_lvalue(1:int) [line 31, column 43]\n " shape="box"]
"div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_3" -> "div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_4" ;
"div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_4" [label="4: Return Stmt \n *&return:int=(1 / n$0) [line 31, column 32]\n " shape="box"]
"div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_4" -> "div0_choose_lvalue_bad#15922600891528658633.d3011cf95d516b230042aa269044a695_2" ;
"div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_1" [label="1: Start div0_choose_rvalue_bad\nFormals: \nLocals: \n " color=yellow style=filled]
"div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_1" -> "div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_3" ;
"div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_2" [label="2: Exit div0_choose_rvalue_bad \n " color=yellow style=filled]
"div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_3" [label="3: Return Stmt \n n$0=_fun_choose_rvalue(1:int) [line 35, column 43]\n " shape="box"]
"div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_3" -> "div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_4" ;
"div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_4" [label="4: Return Stmt \n *&return:int=(1 / n$0) [line 35, column 32]\n " shape="box"]
"div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_4" -> "div0_choose_rvalue_bad#4711054588210108571.343d2bcae71f9c3f5c3cfb41052dfb24_2" ;
"div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_1" [label="1: Start div0_temp_lvalue_bad\nFormals: \nLocals: \n " color=yellow style=filled]
"div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_1" -> "div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_3" ;
"div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_2" [label="2: Exit div0_temp_lvalue_bad \n " color=yellow style=filled]
"div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_3" [label="3: Return Stmt \n n$0=_fun_div_temp_lvalue(1:int,0:int) [line 43, column 37]\n " shape="box"]
"div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_3" -> "div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_4" ;
"div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_4" [label="4: Return Stmt \n *&return:int=n$0 [line 43, column 30]\n " shape="box"]
"div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_4" -> "div0_temp_lvalue_bad#762924255965163608.e2236a796f5186064a6ced7c1ad558e7_2" ;
"div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_1" [label="1: Start div1_assign_conditional_ok\nFormals: \nLocals: \n " color=yellow style=filled]
"div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_1" -> "div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_3" ;
"div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_2" [label="2: Exit div1_assign_conditional_ok \n " color=yellow style=filled]
"div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_3" [label="3: Return Stmt \n n$0=_fun_assign_conditional(1:int) [line 41, column 47]\n " shape="box"]
"div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_3" -> "div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_4" ;
"div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_4" [label="4: Return Stmt \n *&return:int=(1 / n$0) [line 41, column 36]\n " shape="box"]
"div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_4" -> "div1_assign_conditional_ok#386580495590546150.d2c51159bce0b01c70ad4bdfe249ccbe_2" ;
"div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_1" [label="1: Start div1_choose_lvalue_ok\nFormals: \nLocals: \n " color=yellow style=filled]
"div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_1" -> "div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_3" ;
"div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_2" [label="2: Exit div1_choose_lvalue_ok \n " color=yellow style=filled]
"div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_3" [label="3: Return Stmt \n n$0=_fun_choose_lvalue(0:int) [line 33, column 42]\n " shape="box"]
"div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_3" -> "div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_4" ;
"div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_4" [label="4: Return Stmt \n *&return:int=(1 / n$0) [line 33, column 31]\n " shape="box"]
"div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_4" -> "div1_choose_lvalue_ok#14794514121851844432.e6a75af880b689c083ff11acc983eb66_2" ;
"div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_1" [label="1: Start div1_choose_rvalue_ok\nFormals: \nLocals: \n " color=yellow style=filled]
"div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_1" -> "div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_3" ;
"div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_2" [label="2: Exit div1_choose_rvalue_ok \n " color=yellow style=filled]
"div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_3" [label="3: Return Stmt \n n$0=_fun_choose_rvalue(0:int) [line 37, column 42]\n " shape="box"]
"div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_3" -> "div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_4" ;
"div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_4" [label="4: Return Stmt \n *&return:int=(1 / n$0) [line 37, column 31]\n " shape="box"]
"div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_4" -> "div1_choose_rvalue_ok#15613531805403677222.429ad10e519e5d1b777d0c86b7c2e7c8_2" ;
"div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_1" [label="1: Start div1_temp_lvalue_ok\nFormals: \nLocals: \n " color=yellow style=filled]
"div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_1" -> "div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_3" ;
"div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_2" [label="2: Exit div1_temp_lvalue_ok \n " color=yellow style=filled]
"div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_3" [label="3: Return Stmt \n n$0=_fun_div_temp_lvalue(0:int,1:int) [line 45, column 36]\n " shape="box"]
"div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_3" -> "div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_4" ;
"div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_4" [label="4: Return Stmt \n *&return:int=n$0 [line 45, column 29]\n " shape="box"]
"div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_4" -> "div1_temp_lvalue_ok#4626871652686231614.8872cbb3e2dad1aa6aca69eca5075abc_2" ;
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_1" [label="1: Start div_temp_lvalue\nFormals: a:int b:int\nLocals: r:int const & 0$?%__sil_tmpSIL_materialize_temp__n$2:int const \n " color=yellow style=filled]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_1" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_11" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_2" [label="2: Exit div_temp_lvalue \n " color=yellow style=filled]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_3" [label="3: Return Stmt \n n$0=*&r:int const & [line 28, column 14]\n n$1=*n$0:int [line 28, column 14]\n " shape="box"]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_3" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_4" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_4" [label="4: Return Stmt \n *&return:int=(1 / n$1) [line 28, column 3]\n " shape="box"]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_4" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_2" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_5" [label="5: + \n " ]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_5" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_12" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_6" [label="6: Prune (true branch, boolean exp) \n n$3=*&a:int [line 27, column 18]\n PRUNE(n$3, true); [line 27, column 18]\n " shape="invhouse"]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_6" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_8" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_7" [label="7: Prune (false branch, boolean exp) \n n$3=*&a:int [line 27, column 18]\n PRUNE(!n$3, false); [line 27, column 18]\n " shape="invhouse"]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_7" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_9" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_8" [label="8: ConditionalStmt Branch \n n$4=*&b:int [line 27, column 22]\n *&0$?%__sil_tmpSIL_materialize_temp__n$2:int=n$4 [line 27, column 18]\n " shape="box"]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_8" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_5" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_9" [label="9: ConditionalStmt Branch \n *&0$?%__sil_tmpSIL_materialize_temp__n$2:int=1 [line 27, column 18]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_9" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_5" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_10" [label="10: DeclStmt \n VARIABLE_DECLARED(0$?%__sil_tmpSIL_materialize_temp__n$2:int const ); [line 27, column 18]\n " shape="box"]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_10" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_6" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_10" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_7" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_11" [label="11: DeclStmt \n VARIABLE_DECLARED(r:int const &); [line 27, column 3]\n " shape="box"]
[clang] fix bad interaction between ConditionalOperator and initializers Summary: This is several inter-connected changes together to keep the tests happy. The ConditionalOperator `b?t:e` is translated by first creating a placeholder variable to temporarily store the result of the evaluation in each branch, then the real thing we want to assign to reads that variable. But, there are situations where that changes the semantics of the expression, namely when the value created is a struct on the stack (eg, a C++ temporary). This is because in SIL we cannot assign the *address* of a program variable, only its contents, so by the time we're out of the conditional operator we cannot set the struct value correctly anymore: we can only set its content, which we did, but that results in a "shifted" struct value that is one dereference away from where it should be. So a batch of changes concern `conditionalOperator_trans`: - instead of systematically creating a temporary for the conditional, use the `trans_state.var_exp_typ` provided from above if available when translating `ConditionalOperator` - don't even set anything if that variable was already initialized by merely translating the branch expression, eg when it's a constructor - fix long-standing TODO to propagate these initialization facts accurately for ConditionalOperator (used by `init_expr_trans` to also figure out if it should insert a store to the variable being initialised or not) The rest of the changes adapt some relevant other constructs to deal with conditionalOperator properly now that it can set the current variable itself, instead of storing stuff inside a temp variable. This change was a problem because some constructs, eg a variable declaration, will insert nodes that set up the variable before calling its initialization, and now the initialization happens *before* that setup, in the translation of the inner conditional operator, which naturally creates nodes above the current one. - add a generic helper to force a sequential order between two translation results, forcing node creation if necessary - use that in `init_expr_trans` and `cxxNewExpr_trans` - adjust many places where `var_exp_typ` was incorrectly not reset when translating sub-expressions The sequentiality business creates more nodes when used, and the conditionalOperator business uses fewer temporary variables, so the frontend results change quite a bit. Note that biabduction tests were invaluable in debugging this. There could be other constructs to adjust similarly to cxxNewExpr that were not covered by the tests though. Added tests in pulse that exercises the previous bug. Reviewed By: da319 Differential Revision: D24796282 fbshipit-source-id: 0790c8d17
4 years ago
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_11" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_10" ;
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_12" [label="12: DeclStmt \n *&r:int const &=&0$?%__sil_tmpSIL_materialize_temp__n$2 [line 27, column 3]\n " shape="box"]
"div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_12" -> "div_temp_lvalue#2433393879580018854.ddda47c9e217adc2189e8c150a553f53_3" ;
}