Re: [PATCH] Fix fold_indirect_ref

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

On Thu, 12 May 2005, Jakub Jelinek wrote:

> On Thu, May 12, 2005 at 01:20:08PM -0600, Jeffrey A Law wrote:
> > On Thu, 2005-05-12 at 15:10 -0400, Andrew Pinski wrote:
> > > On May 12, 2005, at 2:42 PM, Jakub Jelinek wrote:
> > >
> > > > On Tue, May 10, 2005 at 05:40:32PM +0200, Richard Guenther wrote:
> > > >> 2005-04-28  Richard Guenther  <rguenth@gcc.gnu.org>
> > > >>
> > > >> 	* fold-const.c (fold_indirect_ref_1): Avoid removing
> > > >> 	NOP_EXPRs with type qualifiers like const.
> > > >
> > > > This patch causes a regression on gcc-4_0-branch in g++.dg/opt/temp1.C,
> > > > which is now miscompiled on at least i386/x86_64/ppc/ppc64/ia64.
> > > > Can you please look into it or revert?
> > >
> > > God I how I hate GCC's type system.
> > Something doesn't make any sense here -- Richard's change merely reduces
> > the number of NOP_EXPRs that are stripped.  If it's causing a regression
> > then it must be exposing some kind of latent bug elsewhere.
>
> Sure, I just think that such patches shouldn't be present on the release
> branches until the latent bugs are resolved on the mainline
> (FYI g++.dg/opt/temp1.C fails on mainline too).

I'll revert the patch on the 4.0 branch.  The difference is (.03.generic):


(before)

void f() ()
{
  a = operator+ (&b, &c);
}


(after)

void f() ()
{
  struct T D.2069;
  struct T * D.2073;

  D.2069 = operator+ (&b, &c);
  D.2073 = &D.2069;
  a = *D.2073;
}


so it looks like STRIP_TYPE_NOPS is too strict in rejecting valid
optimizations, but we do not have a STRIP_*_NOPS that perserves
type qualifiers.

Please someone with more knowledge of the middle-end type system
look at this and the related
http://gcc.gnu.org/ml/gcc/2005-05/msg00521.html


Thanks,
Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/