This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ping] Fix PR debug/66728
- From: Mike Stump <mikestump at comcast dot net>
- To: Richard Sandiford <richard dot sandiford at arm dot com>
- Cc: Bernd Schmidt <bschmidt at redhat dot com>, Ulrich Weigand <uweigand at de dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 2 Nov 2015 12:33:48 -0800
- Subject: Re: [ping] Fix PR debug/66728
- Authentication-results: sourceware.org; auth=none
- References: <20151028115839 dot 1E7C85C3D at oc7340732750 dot ibm dot com> <87ziz3ta4t dot fsf at e105548-lin dot cambridge dot arm dot com> <5630D8AE dot 1090608 at redhat dot com> <87h9l4v2pi dot fsf at e105548-lin dot cambridge dot arm dot com> <87611kuzz4 dot fsf at e105548-lin dot cambridge dot arm dot com>
On Nov 2, 2015, at 8:29 AM, Richard Sandiford <richard.sandiford@arm.com> wrote:
> switch (GET_CODE (rtl))
> {
> case CONST_INT:
> - {
> - HOST_WIDE_INT val = INTVAL (rtl);
> + if (mode != BLKmode)
This changes BLKmode for CONST_INT, but I didn’t see this discussed. I didn’t see a test case? I’d like to think that BLKmode things here would be fine. I think they would be use for 1024 bit things that are representable in 20 bits, for example. A value that is 1 (representable in 20 bits) can be trivially communicated the debugger. The existing add_AT_unsigned I think can represent them, no? Similarly for wide-int BLKmode support. I think the real problem is simply the precision 0 part. In the CONST_INT and CONST_DOUBLE there is no code that handled precision 0, and there is no code in the wide-int case either. From wide-int.h:
The precision and length of a wide_int are always greater than 0.
If is was 0, then we have failed. When that bug is fixed, then the precision won’t be 0 and the existing code will work. Where is the 0 first generated, and from what?