This is the mail archive of the gcc@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: Question on operand_equal_p on different type conversion expressions


On Mon, May 20, 2013 at 10:50 PM, Bin.Cheng <amker.cheng@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


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