On Tue, May 29, 2012 at 1:57 PM, Mohamed Shafi <shafi...@gmail.com> wrote: > Hi, > > I am porting a private target in GCC 4.6.3 version. For my target > pointer size is 24bits and word size is 32bits. Moreover a byte is > 32bit > > For the testcase gcc.c-torture/compile/921111-1.c i get the following ICE > > 921111-1.c: In function 'f': > 921111-1.c:18:5: internal compiler error: in size_binop_loc, at > fold-const.c:1436 > Please submit a full bug report, > with preprocessed source if appropriate. > See <http://gcc.gnu.org/bugs.html> for instructions > > This is the reduced testcase of the same > > struct vp { > int wa; > }; > > typedef struct vp *vpt; > > typedef struct vc { > int o; > vpt py[8]; > } *vct; > > typedef struct np *npt; > struct np { > vct d; > int di; > }; > > int f(npt dp) > { > vpt *py; > > py = &dp->d->py[dp->di]; > return (int)(py[1])->wa; > } > > The ICE happens in tree_slp_vectorizer pass. The following is the tree > dump just before that > > ;; Function f (f) > > f (struct np * dp) > { > struct vp * D.1232; > int D.1230; > unsigned int D.1228; > int D.1227; > struct vc * D.1225; > > <bb 2>: > D.1225_2 = dp_1(D)->d; > D.1227_4 = dp_1(D)->di; > D.1228_5 = (unsigned int) D.1227_4; > D.1232_9 = MEM[(struct vp * *)D.1225_2 + 4B].py[D.1228_5]{lb: 0 sz: 4}; > D.1230_10 = D.1232_9->wa; > return D.1230_10; > } > > The ICE happens for > > D.1232_9 = MEM[(struct vp * *)D.1225_2 + 4B].py[D.1228_5]{lb: 0 sz: 4}; > > This is due to the addition of the new code in tree-data-ref.c (this > is was not there in 4.5 series) > > if (TREE_CODE (base) == MEM_REF) > { > if (!integer_zerop (TREE_OPERAND (base, 1))) > { > if (!poffset) > { > double_int moff = mem_ref_offset (base); > poffset = double_int_to_tree (sizetype, moff); > } > else > poffset = size_binop (PLUS_EXPR, poffset, TREE_OPERAND (base, 1));
This should use mem_ref_offset, too. > } > base = TREE_OPERAND (base, 0); > } > else > base = build_fold_addr_expr (base); > > the assert check in size_binop fails > > > gcc_assert (int_binop_types_match_p (code, TREE_TYPE (arg0), > TREE_TYPE (arg1))); > > This is because the mode of arg0 and arg1 are different, one is Pmode > and other is word_mode. > This is present in m32c target which also has different Pmode and word_mode. > Is this a know failure? I cannot find a bug entry for this issue. > Should i report this? > > Regards, > Shafi
