On Mon, May 20, 2013 at 10:50 PM, Bin.Cheng <amker.ch...@gmail.com> wrote: > Hi, > I ran into a call of operand_equal_p for two type conversion tree nodes like: > arg0: > <nop_expr 0xb737a974 > type <integer_type 0xb74faae0 public unsigned HI > size <integer_cst 0xb74e87c4 constant 16> > unit size <integer_cst 0xb74e87e0 constant 2> > align 16 symtab 0 alias set -1 canonical type 0xb74faae0 > precision 16 min <integer_cst 0xb74e8b28 0> max <integer_cst > 0xb74e8a64 65535>> > > arg 0 <ssa_name 0xb73222f8 > type <integer_type 0xb74fa420 long int sizes-gimplified public SI > size <integer_cst 0xb74e855c constant 32> > unit size <integer_cst 0xb74e8578 constant 4> > align 32 symtab 0 alias set 5 canonical type 0xb74fa420 > precision 32 min <integer_cst 0xb74e8888 -2147483648> max <integer_cst > 0xb74e88a4 2147483647> context <translation_unit_decl 0xb76a7d80 > D.6120> > pointer_to_this <pointer_type 0xb75017e0>> > visiteddef_stmt _23 = *_22; > > version 23>> > > arg1: > <convert_expr 0xb737a3e8 > type <integer_type 0xb74fa2a0 short int sizes-gimplified public HI > size <integer_cst 0xb74e87c4 constant 16> > unit size <integer_cst 0xb74e87e0 constant 2> > align 16 symtab 0 alias set 4 canonical type 0xb74fa2a0 > precision 16 min <integer_cst 0xb74e8770 -32768> max <integer_cst > 0xb74e878c 32767> context <translation_unit_decl 0xb76a7d80 D.6120> > pointer_to_this <pointer_type 0xb72db600>> > > arg 0 <ssa_name 0xb73222f8 > type <integer_type 0xb74fa420 long int sizes-gimplified public SI > size <integer_cst 0xb74e855c constant 32> > unit size <integer_cst 0xb74e8578 constant 4> > align 32 symtab 0 alias set 5 canonical type 0xb74fa420 > precision 32 min <integer_cst 0xb74e8888 -2147483648> max <integer_cst > 0xb74e88a4 2147483647> context <translation_unit_decl 0xb76a7d80 > D.6120> > pointer_to_this <pointer_type 0xb75017e0>> > visiteddef_stmt _23 = *_22; > > version 23>> > > Though arg0 is a nop_expr, the conversion is actually not NOP and it > seems arg0 equals arg1.
NOP_EXPR here is a misnamed tree really. It could also be a CONVERT_EXPR and still have the same issue as the types are not the same. > The problem is operand_equal_q simply return false because arg0/arg1 > have different tree code. No it returns false because the types are two different. One is signed and the other is unsigned. > > Should operand_equal_q take two kinds of conversion expression into > consideration, or arg0/arg1 are not equal? Thanks. Yes why would it not? Look at the resulting types again. Thanks, Andrew
