SIZE_TYPE

SIZE_TYPE

[Aurelien Buhrig]

Hi,

What should be the correct setting of SIZE_TYPE for a target whose int
is HI (and Pmode is PSI) ?
long unsigned int (DI) or (short) unsigned int ?

Is it only used for size_t ?

Thanks,
Aurélien

Re: SIZE_TYPE

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

> What should be the correct setting of SIZE_TYPE for a target whose int
> is HI (and Pmode is PSI) ?
> long unsigned int (DI) or (short) unsigned int ?
>
> Is it only used for size_t ?

SIZE_TYPE is used for size_t.  It's value should normally be the
unsigned integer type which has the same number of bits as the type of a
pointer.

Ian

Re: SIZE_TYPE

[Aurelien Buhrig]

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 ?

Thanks,
Aurélien


2011/10/14 Ian Lance Taylor <iant@google.com>:
> Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:
>
>> What should be the correct setting of SIZE_TYPE for a target whose int
>> is HI (and Pmode is PSI) ?
>> long unsigned int (DI) or (short) unsigned int ?
>>
>> Is it only used for size_t ?
>
> SIZE_TYPE is used for size_t.  It's value should normally be the
> unsigned integer type which has the same number of bits as the type of a
> pointer.
>
> Ian
>

Re: SIZE_TYPE

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> 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

Re: SIZE_TYPE

[Aurelien Buhrig]

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@google.com>:
> Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> 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
>

Re: SIZE_TYPE

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

> 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 ???

Please don't top-post.  Thanks.

You mention POINTER_PLUS_EXPR at the end, but PLUS_EXPR in the middle.
Which is it?

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?

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.

Ian

> 2011/10/14 Ian Lance Taylor <iant@google.com>:
>> Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> 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
>>

Re: SIZE_TYPE

[Aurelien Buhrig]

> 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@gmail.com>:
> 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@google.com>:
>> Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> 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
>>
>

Re: SIZE_TYPE

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

> #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

Looks like you are using gcc 4.3 and you need the fix for PRs 36227 and
38835, which is in gcc 4.4 and later.

Ian

Re: SIZE_TYPE

[Aurelien Buhrig]

> Looks like you are using gcc 4.3 and you need the fix for PRs 36227 and
> 38835, which is in gcc 4.4 and later.
>
> Ian


Thanks, So I will try to port my backend to a more recent branch.

But since these bugs are flagged to be (also) in 4.3 branch, does it
mean 4.3 branch is not maintained any more (although last 4.3.6
release was on 2011-06-27)? Or Is it that fixes are not always applied
on previous branches ?

Are there some fixes applied in 4.5/4.6 which are not applied to 4.4 ?
So what is "right" branch to use so for my backend port ?

Again, thank you for your help!
Aurélien

Re: SIZE_TYPE

[Ian Lance Taylor]

Aurelien Buhrig <aurelien.buhrig.gcc@gmail.com> writes:

> But since these bugs are flagged to be (also) in 4.3 branch, does it
> mean 4.3 branch is not maintained any more (although last 4.3.6
> release was on 2011-06-27)? Or Is it that fixes are not always applied
> on previous branches ?

As seen on http://gcc.gnu.org/ , the currently maintained release
branches are 4.4, 4.5, and 4.6.  4.3 is no longer maintained.

> Are there some fixes applied in 4.5/4.6 which are not applied to 4.4 ?
> So what is "right" branch to use so for my backend port ?

My general rule is: if you plan to contribute the backend port to
mainstream gcc, you should use current mainline; if you plan to keep the
port private, you should use the most recent release branch and upgrade
to new release branches after the first release is made.

Ian