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 14:39:49 +0000
- Subject: Re: [PATCH] Fix for PR c/57563
- References: <BF230D13CA30DD48930C31D4099330003A42D3CA at FMSMSX101 dot amr dot corp dot intel dot com>
On Sun, 9 Jun 2013, Iyer, Balaji V wrote:
> Attached, please find a patch that will fix the bug reported in PR
> 57563. There are a couple issues that went wrong. First, in the test
> case, we have a double multiplied to a double. When -std=c99 flag is
> used, they get converted to long double. The way to fix this is to add a
> type cast to the array notation to the same type as identity variable
> and thus they will all be double.
You don't say what the actual error was, and neither does the original PR.
But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the
gimplifier, that suggests that c_fully_fold isn't getting called somewhere
it should be - and probably calling c_fully_fold is the correct fix rather
than inserting a cast. If you can get such ICEs for
EXCESS_PRECISION_EXPR, it's quite possible you might get them for
C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound literals of
variably modified type, in various places in the affected expressions),
which should be fixed by using c_fully_fold but not by inserting a cast.
--
Joseph S. Myers
joseph@codesourcery.com