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