This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] Fix for PR c/57563
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "Iyer, Balaji V" <balaji dot v dot iyer at intel dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, "mpolacek at gcc dot gnu dot org" <mpolacek at gcc dot gnu dot org>
- Date: Mon, 10 Jun 2013 22:45:34 +0000
- Subject: RE: [PATCH] Fix for PR c/57563
- References: <BF230D13CA30DD48930C31D4099330003A42D3CA at FMSMSX101 dot amr dot corp dot intel dot com> <Pine dot LNX dot 4 dot 64 dot 1306101432120 dot 15706 at digraph dot polyomino dot org dot uk> <BF230D13CA30DD48930C31D4099330003A42D6CC at FMSMSX101 dot amr dot corp dot intel dot com> <Pine dot LNX dot 4 dot 64 dot 1306101509500 dot 15706 at digraph dot polyomino dot org dot uk> <BF230D13CA30DD48930C31D4099330003A42D776 at FMSMSX101 dot amr dot corp dot intel dot com> <Pine dot LNX dot 4 dot 64 dot 1306102116100 dot 13702 at digraph dot polyomino dot org dot uk> <BF230D13CA30DD48930C31D4099330003A42D8CE at FMSMSX101 dot amr dot corp dot intel dot com>
On Mon, 10 Jun 2013, Iyer, Balaji V wrote:
> > This version is better, but if removing an EXCESS_PRECISION_EXPR there caused
> > problems, why is it OK to remove CONVERT_EXPR and NOP_EXPR like you still
> > do - won't that also cause type mismatches (at least if the conversions are to
> > types that count as sufficiently different for GIMPLE purposes - say conversions
> > between 32-bit and 64-bit integers)? Maybe you actually need to fold without
> > removing any such wrappers first at all?
>
> I looked into it and they were an artifact of previous implementation.
> Those while loops were not even being entered. Thus, I took them out.
> Here is a fixed patch.
Thanks, this patch is OK.
--
Joseph S. Myers
joseph@codesourcery.com