This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix ICEs in simplify_immed_subreg on OImode/XImode subregs (PR target/63910)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Mike Stump <mikestump at comcast dot net>, Richard Sandiford <rdsandiford at googlemail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 19 Nov 2014 13:07:43 +0100
- Subject: Re: [PATCH] Fix ICEs in simplify_immed_subreg on OImode/XImode subregs (PR target/63910)
- Authentication-results: sourceware.org; auth=none
- References: <20141118215235 dot GP1745 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1411190956070 dot 374 at zhemvz dot fhfr dot qr> <20141119114947 dot GD1745 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1411191257510 dot 374 at zhemvz dot fhfr dot qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Nov 19, 2014 at 12:59:06PM +0100, Richard Biener wrote:
> > So perhaps something like this? Don't know how much more inefficient it is
> > compared to what it used to do before.
>
> Yes, that looks good.
>
> > Or just keep the existing code and just remove the assert and instead return
> > NULL whenever outer_submode is wider than MAX_BITSIZE_MODE_ANY_INT? At
> > least during propagation that will make zero change.
> > Though, in that case I have still doubts about the current code handling right
> > modes wider than HOST_BITS_PER_DOUBLE_INT but smaller than
> > MAX_BITSIZE_MODE_ANY_INT (none on i?86/x86_64). If TARGET_SUPPORTS_WIDE_INT
> > == 0, we still silently throw away the upper bits, don't we?
>
> Well - not with your added check, no?
For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
is it still bound to wide_int (i.e. MAX_BITSIZE_MODE_ANY_INT rounded up)
precision? Mike?
Jakub