> Please don't top-post. Thanks.
Yes, soeery about that.
>
> You mention POINTER_PLUS_EXPR at the end, but PLUS_EXPR in the middle.
> Which is it?
it is PLUS_EXPR. On 1 testcase, I tried converting PLUS_EXPR into
POINTER_PLUS_EXPR (removing NOP_EXPR) with success, but this works on
only 1 testcase (as you said, it is not the root cause).
> You originally said this happened when compiling __gcc_bcmp. I don't
> see any "pointer to int" types in __gcc_bcmp; where are they coming
> from?
the pb occurs each time a pointer is incremented/added inside a loop.
(*s1++ (I think) for __gcc_bcmp), in loop optimization pass.
Here a backtrace (gcc 4.3.6) of the gcc.c-torture/execute/20000819-1.c:
void foo(int *sp, int cnt)
{
int *p, *top;
top = sp; sp -= cnt;
for(p = sp; p <= top; p++)
if (*p < 2) exit(0);
}
#0 fold_binary (code=PLUS_EXPR, type=0x2aaaae38a9c0,
op0=0x2aaaae441900, op1=0x2aaaae438f60) at
../../src/gcc/fold-const.c:9553
#1 fold_build2_stat (code=PLUS_EXPR, type=0x2aaaae38a9c0,
op0=0x2aaaae441900, op1=0x2aaaae438f60) at
../../src/gcc/fold-const.c:13826
#2 fold_binary (code=PLUS_EXPR, type=0x2aaaae38a9c0,
op0=0x2aaaae438f60, op1=0x2aaaae441900) at
../../src/gcc/fold-const.c:9624
#3 fold_build2_stat (code=PLUS_EXPR, type=0x2aaaae38a9c0,
op0=0x2aaaae438f60, op1=0x2aaaae441900) at
../../src/gcc/fold-const.c:13826
#4 create_mem_ref (bsi=0x7fffffffd300, type=0x2aaaae37b540,
addr=0x7fffffffd320) at ../../src/gcc/tree-ssa-address.c:645
#5 rewrite_use_address (data=0x7fffffffd4f0, use=0xcad150,
cand=0xcc3da0) at ../../src/gcc/tree-ssa-loop-ivopts.c:5227
#6 rewrite_use (data=0x7fffffffd4f0, use=0xcad150, cand=0xcc3da0) at
../../src/gcc/tree-ssa-loop-ivopts.c:5286
#7 rewrite_uses (data=0x7fffffffd4f0) at
../../src/gcc/tree-ssa-loop-ivopts.c:5315
#8 tree_ssa_iv_optimize_loop (data=0x7fffffffd4f0,
loop=0x2aaaae375f00) at ../../src/gcc/tree-ssa-loop-ivopts.c:5485
#9 tree_ssa_iv_optimize () at ../../src/gcc/tree-ssa-loop-ivopts.c:5518
#10 tree_ssa_loop_ivopts () at ../../src/gcc/tree-ssa-loop.c:550
...
(gdb) call debug_tree (op0)
<nop_expr 0x2aaaae441900
type <pointer_type 0x2aaaae38a9c0
type <integer_type 0x2aaaae37b540 int public HI
size <integer_cst 0x2aaaae36c630 constant invariant 16>
unit size <integer_cst 0x2aaaae36c660 constant invariant 2>
align 16 symtab 0 alias set 3 canonical type
0x2aaaae37b540 precision 16 min <integer_cst 0x2aaaae36c6c0 -32768>
max <integer_cst 0x2aaaae36c6f0 32767>
pointer_to_this <pointer_type 0x2aaaae38a9c0>>
sizes-gimplified public unsigned PSI
size <integer_cst 0x2aaaae36c810 constant invariant 32>
unit size <integer_cst 0x2aaaae36c3c0 constant invariant 4>
align 16 symtab 0 alias set -1 canonical type 0x2aaaae38a9c0>
arg 0 <ssa_name 0x2aaaae438cc0
type <integer_type 0x2aaaae37b780 long unsigned int public
unsigned SI size <integer_cst 0x2aaaae36c810 32> unit size
<integer_cst 0x2aaaae36c3c0 4>
align 16 symtab 0 alias set -1 canonical type
0x2aaaae37b780 precision 32 min <integer_cst 0x2aaaae36c840 0> max
<integer_cst 0x2aaaae36c7e0 4294967295>>
var <var_decl 0x2aaaae443000 ivtmp.14> def_stmt <phi_node
0x2aaaae43b100>
version 1>>
(gdb) call debug_tree (op1)
<ssa_name 0x2aaaae438f60
type <pointer_type 0x2aaaae38a9c0
type <integer_type 0x2aaaae37b540 int public HI
size <integer_cst 0x2aaaae36c630 constant invariant 16>
unit size <integer_cst 0x2aaaae36c660 constant invariant 2>
align 16 symtab 0 alias set 3 canonical type
0x2aaaae37b540 precision 16 min <integer_cst 0x2aaaae36c6c0 -32768>
max <integer_cst 0x2aaaae36c6f0 32767>
pointer_to_this <pointer_type 0x2aaaae38a9c0>>
sizes-gimplified public unsigned PSI
size <integer_cst 0x2aaaae36c810 constant invariant 32>
unit size <integer_cst 0x2aaaae36c3c0 constant invariant 4>
align 16 symtab 0 alias set -1 canonical type 0x2aaaae38a9c0>
var <parm_decl 0x2aaaae435000 sp> def_stmt <gimple_modify_stmt
0x2aaaae433a80>
version 8
ptr-info 0x2aaaae43a260>
(gdb) call debug_tree (type)
<pointer_type 0x2aaaae38a9c0
type <integer_type 0x2aaaae37b540 int public HI
size <integer_cst 0x2aaaae36c630 constant invariant 16>
unit size <integer_cst 0x2aaaae36c660 constant invariant 2>
align 16 symtab 0 alias set 3 canonical type 0x2aaaae37b540
precision 16 min <integer_cst 0x2aaaae36c6c0 -32768> max <integer_cst
0x2aaaae36c6f0 32767> pointer_to_this <pointer_type
0x2aaaae38a9c0>>
sizes-gimplified public unsigned PSI
size <integer_cst 0x2aaaae36c810 type <integer_type 0x2aaaae37b0c0
bit_size_type> constant invariant 32>
unit size <integer_cst 0x2aaaae36c3c0 type <integer_type
0x2aaaae37b000 long unsigned int> constant invariant 4>
align 16 symtab 0 alias set -1 canonical type 0x2aaaae38a9c0>
> It's never a bug that fold_binary returns NULL. So you should look at
> the caller. You should look at every level in the call stack, in fact.
> Look at the code and the comments at each level. That should help you
> understand what is happening.
I keep trying, but I'm a bit lost in middle end. From create_mem_ref,
I don't see what could cause this.
And I don't know why such a call to fold_binary in fold_build2_stat
would not be correct...
Thanks,
Aurélien
2011/10/18 Aurelien Buhrig <aurelien.buhrig.gcc@xxxxxxxxx>:
> it seems the pb comes from a call to fold_binary (in fold_build2_stat)
> which return NULL, then falling into build2_stat with incorrect
> params.
>
> fold_binary parameters are
> code = PLUS_EXPR ,
> type --> pointer to INT
> op0 --> NOP_EXPR, type pointer to int, (converting size_t to pointer)
> op1 --> SSA_NAME, type pointer to int
>
> such a case is not handled by fold_binary.
> Does the pb comes from the fact that fold_binary does not handle such
> a case, or because such a call should not happen (ex a call with code
> POINTER_PLUS_EXPR with a pointer and an interger as operands ???
>
>
> thx,
> Aurélien
>
>
>
>
>
>
> 2011/10/14 Ian Lance Taylor <iant@xxxxxxxxxx>:
>> Aurelien Buhrig <aurelien.buhrig.gcc@xxxxxxxxx> writes:
>>
>>> Thanks, but when I do so, gcc ICE in build2_stat, at tree.c:3112,
>>> while compiling libgcc2 (__gcc_bcmp) during ivopt pass.
>>> __gcc_bcmp uses a size_t as loop iv.
>>>
>>> Here is the failed assert:
>>> if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR)
>>> && arg0 && arg1 && tt && POINTER_TYPE_P (tt))
>>> gcc_assert (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) ==
>>> INTEGER_CST);
>>>
>>> while I have
>>> code == PLUS_EXPR,
>>> TREE_CODE (arg0) = SSA_NAME and TREE_CODE(arg1) == NOP_EXPR.
>>>
>>>
>>> I have no such pb when I define size_t as an unsigned int (HImode),
>>> which is different from my Pmode=PSI mode (32bits).
>>>
>>> Any idea where it may come from ? Bad macro definition in my target.h ?
>>
>> You would have to look at the caller of build2_stat to see what is
>> happening here. It seems a bit odd that changing the size of SIZE_TYPE
>> causes something to be POINTER_TYPE_P.
>>
>> Ian
>>
>
