On Wed, Aug 29, 2012 at 1:03 PM, Deepti Sharma
<deepti.gccretar...@gmail.com> wrote:
> Hello Richard,
>
>> -----Original Message-----
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Richard Guenther
>> Sent: 31 May 2012 14:27
>> To: Mohamed Shafi
>> Cc: GCC; d...@redhat.com; Ahmed Sherif
>> Subject: Re: ICE with MEM_REF when Pmode is different from word_mode
>>
>> On Wed, May 30, 2012 at 4:31 PM, Mohamed Shafi <shafi...@gmail.com>
>> wrote:
>> > On 29 May 2012 17:31, Richard Guenther <richard.guent...@gmail.com>
>> wrote:
>> >> 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.
>> >>
>> >
>> > This is present in the trunk also. Will you be submitting a patch for
>> this?
>>
>> I put it on my TODO list. Something like
>
> Is this issue fixed now for gcc 4.6.3? I am not able to find a bug entry for
> this. Could you please share the link?
It's only fixed on trunk, not 4.6.x or 4.7.x.
Richard.
> Thanks.
>
>
>> Index: gcc/tree-data-ref.c
>> ===================================================================
>> --- gcc/tree-data-ref.c (revision 188008)
>> +++ gcc/tree-data-ref.c (working copy)
>> @@ -720,13 +720,12 @@ dr_analyze_innermost (struct data_refere
>> {
>> if (!integer_zerop (TREE_OPERAND (base, 1)))
>> {
>> + double_int moff = mem_ref_offset (base);
>> + tree mofft = double_int_to_tree (sizetype, moff);
>> if (!poffset)
>> - {
>> - double_int moff = mem_ref_offset (base);
>> - poffset = double_int_to_tree (sizetype, moff);
>> - }
>> + poffset = mofft;
>> else
>> - poffset = size_binop (PLUS_EXPR, poffset, TREE_OPERAND
>> (base, 1));
>> + poffset = size_binop (PLUS_EXPR, poffset, mofft);
>> }
>> base = TREE_OPERAND (base, 0);
>> }
>>
>>
>> > Shafi
>
