Skip to content
Snippets Groups Projects
  • Jakub Jelinek's avatar
    f9d2a95b
    fold-const: Avoid infinite recursion in +-*&|^minmax reassociation [PR114084] · f9d2a95b
    Jakub Jelinek authored
    In the following testcase we infinitely recurse during BIT_IOR_EXPR
    reassociation.
    One operand is (unsigned _BitInt(31)) a << 4 and another operand
    2147483647 >> 1 | 80 where both the right shift and the | 80
    trees have TREE_CONSTANT set, but weren't folded because of delayed
    folding, where some foldings are apparently done even in that case
    unfortunately.
    Now, the fold_binary_loc reassocation code splits both operands into
    variable part, minus variable part, constant part, minus constant part,
    literal part and minus literal parts, to prevent infinite recursion
    punts if there are just 2 parts altogether from the 2 operands and then goes
    on with reassociation, merges first the corresponding parts from both
    operands and then some further merges.
    The problem with the above expressions is that we get 3 different objects,
    var0 (the left shift), con1 (the right shift) and lit1 (80), so the infinite
    recursion prevention doesn't trigger, and we eventually merge con1 with
    lit1, which effectively reconstructs the original op1 and then associate
    that with var0 which is original op0, and associate_trees for that case
    calls fold_binary.  There are some casts involved there too (the T typedef
    type and the underlying _BitInt type which are stripped with STRIP_NOPS).
    
    The following patch attempts to prevent this infinite recursion by tracking
    the origin (if certain var comes from nothing - 0, op0 - 1, op1 - 2 or both - 3)
    and propagates it through all the associate_tree calls which merge the vars.
    If near the end we'd try to merge what comes solely from op0 with what comes
    solely from op1 (or vice versa), the patch punts, because then it isn't any
    kind of reassociation between the two operands, if anything it should be
    handled when folding the suboperands.
    
    2024-02-26  Jakub Jelinek  <jakub@redhat.com>
    
    	PR middle-end/114084
    	* fold-const.cc (fold_binary_loc): Avoid the final associate_trees
    	if all subtrees of var0 come from one of the op0 or op1 operands
    	and all subtrees of con0 come from the other one.  Don't clear
    	variables which are never used afterwards.
    
    	* gcc.dg/bitint-94.c: New test.
    f9d2a95b
    History
    fold-const: Avoid infinite recursion in +-*&|^minmax reassociation [PR114084]
    Jakub Jelinek authored
    In the following testcase we infinitely recurse during BIT_IOR_EXPR
    reassociation.
    One operand is (unsigned _BitInt(31)) a << 4 and another operand
    2147483647 >> 1 | 80 where both the right shift and the | 80
    trees have TREE_CONSTANT set, but weren't folded because of delayed
    folding, where some foldings are apparently done even in that case
    unfortunately.
    Now, the fold_binary_loc reassocation code splits both operands into
    variable part, minus variable part, constant part, minus constant part,
    literal part and minus literal parts, to prevent infinite recursion
    punts if there are just 2 parts altogether from the 2 operands and then goes
    on with reassociation, merges first the corresponding parts from both
    operands and then some further merges.
    The problem with the above expressions is that we get 3 different objects,
    var0 (the left shift), con1 (the right shift) and lit1 (80), so the infinite
    recursion prevention doesn't trigger, and we eventually merge con1 with
    lit1, which effectively reconstructs the original op1 and then associate
    that with var0 which is original op0, and associate_trees for that case
    calls fold_binary.  There are some casts involved there too (the T typedef
    type and the underlying _BitInt type which are stripped with STRIP_NOPS).
    
    The following patch attempts to prevent this infinite recursion by tracking
    the origin (if certain var comes from nothing - 0, op0 - 1, op1 - 2 or both - 3)
    and propagates it through all the associate_tree calls which merge the vars.
    If near the end we'd try to merge what comes solely from op0 with what comes
    solely from op1 (or vice versa), the patch punts, because then it isn't any
    kind of reassociation between the two operands, if anything it should be
    handled when folding the suboperands.
    
    2024-02-26  Jakub Jelinek  <jakub@redhat.com>
    
    	PR middle-end/114084
    	* fold-const.cc (fold_binary_loc): Avoid the final associate_trees
    	if all subtrees of var0 come from one of the op0 or op1 operands
    	and all subtrees of con0 come from the other one.  Don't clear
    	variables which are never used afterwards.
    
    	* gcc.dg/bitint-94.c: New test.