This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251

--- Comment #14 from vries at gcc dot gnu.org 2011-09-02 10:28:52 UTC ---
> but for some reason it doesn't trigger?

The bb containing the __builtin_stack_restore has 2 successors:
...
<bb 6>:
  D.2099_18 = MEM[(int *)&D.2129][5]{lb: 0 sz: 4};
  __builtin_stack_restore (saved_stack.3_5);
  if (D.2099_18 != 15)
    goto <bb 7>;
  else
    goto <bb 8>;
...

This case doesn't fall into the cases described in the header comment.
...
/* Try to optimize out __builtin_stack_restore.  Optimize it out
   if there is another __builtin_stack_restore in the same basic
   block and no calls or ASM_EXPRs are in between, or if this block's
   only outgoing edge is to EXIT_BLOCK and there are no calls or
   ASM_EXPRs after this __builtin_stack_restore.  */
...

It hits this piece of code in optimize_stack_restore and returns, so it doesn't
reach second_stack_restore:
...
  /* Allow one successor of the exit block, or zero successors.  */
  switch (EDGE_COUNT (bb->succs))
    {
    case 0:
      break;
    case 1:
      if (single_succ_edge (bb)->dest != EXIT_BLOCK_PTR)
    return NULL_TREE;
      break;
    default:
      return NULL_TREE;
    }
 second_stack_restore:
...


For the stack-save-restore.c, if I declare p inside the function, cse creates a
(set (sp) (sp)), which is eliminated.
But for the 20010209-1.c example, that doesn't happen.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]