[PATCH PR94574] ICE during GIMPLE pass: ccp

Richard Biener richard.guenther@gmail.com
Tue Apr 14 12:18:27 GMT 2020


On Tue, Apr 14, 2020 at 1:57 PM yangyang (ET) <yangyang305@huawei.com> wrote:
>
> Hi,
>
> > -----Original Message-----
> > From: Richard Biener [mailto:richard.guenther@gmail.com]
> > Sent: Tuesday, April 14, 2020 4:44 PM
> > To: yangyang (ET) <yangyang305@huawei.com>
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH PR94574] ICE during GIMPLE pass: ccp
> >
> > On Mon, Apr 13, 2020 at 11:38 AM yangyang (ET) <yangyang305@huawei.com>
> > wrote:
> > >
> > > Hi,
> > >
> > >   This is a simple fix for pr94574.
> > >
> > >   testcase testsuite/gcc.target/aarch64/sve/acle/general/deref_1.c ICEs
> > when testing GCC trunk with -O2 -msve-vector-bits=256
> > -march=armv8.2-a+sve.
> > >
> > >   There is a gimple statement before the ccp pass as follow:
> > >
> > >   MEM[(svuint32_t *)&res] = _2;
> > >
> > >   The ccp pass tries to convert this gimple into:
> > >
> > >   _7 = VIEW_CONVERT_EXPR<vector(8) unsigned int>(_2);
> > >   res_9 = BIT_INSERT_EXPR <res_8(D), _7, 0>;
> > >
> > >   However,  the size of _7 is larger than res_8(D) , leading to a
> > verify_gimple failure. Since the replaced bits of BIT_INSERT_EXPR are supposed
> > to fully inside the container, before doing the above optimitzaion, a check shall
> > be added.
> > >
> > >   With this fix, a MEM_REF which visits the address of a vector will be
> > rewritten into a BIT_INSERT_EXPR only when the size of the vector is larger
> > than the size of MEM_REF. In this way, this kind of ICE can be avoided.
> > >
> > >   a test case with which this problem will be exposed more easily is
> > extracted and added for this. Bootstrapped/regtested on both x86_64 and
> > aarch64 Linux platform.
> > >   Any suggestion?
> >
> > OK.
> >
> > Thanks,
> > Richard.
>
>
>   Thanks for reviewing this.
>
>   The attached patch has been adjusted to be suitable for git am. Can you sponsor it if it's OK to go?

Will do.

> Thanks,
> Yang Yang


More information about the Gcc-patches mailing list