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 Oct 7, 2003, at 2:37 PM, Andrew MacLeod wrote:


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 :-)

:P
I don't blame you, i know you are busy.
That's why i just file bug reports, rather than show up at your door or something.
I think you are the only one who understands switch insertion, unfortunately, and that's where all the bugs have been popping up.



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????
whoa.
that *is* weird.
I didn't even notice.


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]