This is the mail archive of the gcc-patches@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]

Re: [tree-ssa-cfg] BIND_EXPR removal


On Tue, 2003-10-07 at 13:53, Daniel Berlin wrote:
> 
> On Oct 7, 2003, at 1:41 PM, Zdenek Dvorak wrote:
> 
> > Hello,
> >
> >>> nope, both problems I have detected should also be on mainline. The
> >>> first is the dom_children allocated by gc (this I fixed).  The second
> >>> one is that dominance_info structure contains varray that is also
> >>> allocated by gc.  Both of these cause problems when dominators are
> >>> recomputed,
> >>
> >> I should also note that once Andrew fixes the remaining critical edge
> >> splitting bugs, so i can pre-split critical edges in PRE, we won't be
> >> needing to recompute dominators anymore in SSAPRE, so the problem goes
> >> away.

sure, its all my fault :-)

Interestingly, it simply looks like this case is something unexpected.
Did you see how ugly that hunk of code is its aborting on?

            case 103:
               if (general_operand(op, 0u) != 0)
                  result = 1;
               break;
            default:
               if (c != 'r' ? c != 'R' ? c != 'q' ? c != 'Q' ? c == 'f' ? target_flags & 1 || (target_flags >> 5u) & 1 : c == 't' ? target_flags & 1 || (target_flags >> 5u) & 1 : c == 'u' ? target_flags & 1 || (target_flags >> 5u) & 1 : c != 'a' ? c != 'b' ? c != 'c' ? c != 'd' ? c == 'x' ? (target_flags >> 14u) & 1 : c == 'Y' ? (target_flags >> 15u) & 1 : c == 'y' ? (target_flags >> 13u) & 1 : c == 'A' || (c == 'D' || c == 'S') : 1 : 1 : 1 : 1 : 1 : 1 : 1 : 1)
                  {
                     case 114:
                     if ((op->mode) == 55u)
                        break;
                     if (register_operand(op, 0u) != 0)
                        result = 1;

                  }


Look at where case 114: is..... is that truly allowed? especially
*after* the default label????

Thats what the original source does too.

The code is aborting because it is not expecting a case label there...
I think we could certainly handle it, but thats warthog level butt
ugly...

Andrew


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