This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GCC 7] Remove broken path in extract_bit_field_1
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org, iant at google dot com
- Date: Mon, 4 Apr 2016 15:24:44 +0200
- Subject: Re: [PATCH][GCC 7] Remove broken path in extract_bit_field_1
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1604041449590 dot 13384 at t29 dot fhfr dot qr> <20160404130617 dot GD19207 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1604041508400 dot 13384 at t29 dot fhfr dot qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Apr 04, 2016 at 03:10:34PM +0200, Richard Biener wrote:
> On Mon, 4 Apr 2016, Jakub Jelinek wrote:
>
> > On Mon, Apr 04, 2016 at 02:56:51PM +0200, Richard Biener wrote:
> > > The testcase gcc.target/i386/pr37870.c will already ICE with that
> > > patch, so no additional testcase.
> >
> > In theory you could validate_subreg first and use that code if validation
> > went ok, otherwise go through memory.
> > But I admit I don't have anything in particular in mind where it would
> > trigger this code and the subreg would successfully validate.
>
> Not sure if it would help as that has
>
> /* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though
> store_bit_field
> is the culprit here, and not the backends. */
> else if (osize >= UNITS_PER_WORD && isize >= osize)
> ;
>
> and thus we'd return true anyway for (subreg:XF (reg:TI) 0)
If XFmode subreg of TImode reg passes validation, where does it ICE then?
Jakub