This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: SIZE_TYPE
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
>