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: Mike Stump <mikestump at comcast dot net>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Richard Sandiford <rdsandiford at googlemail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 19 Nov 2014 10:53:53 -0800
- 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> <20141119120743 dot GE1745 at tucnak dot redhat dot com>
On Nov 19, 2014, at 4:07 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>
> 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?
So, you can generate any finite size const_int you want. That is safe. The question, what does the entire rest of the compiler do with these bigger than max things, well that’s the part that I’ll defer to others on. Generally when Kenny and I did the code, I think we had a tendency to treat wide_int as a maximal size.