[Bug tree-optimization/19637] Missed constant propagation with placement new

[Bug tree-optimization/19637] Missed constant propagation with placement new

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2005-10-09 09:47 -------
The non-null check is now removed for the foo_char() case by VRP (note that
the non-null check for the two viod-cases are _not_ removed by VRP but by DOM1.

The propagation of the initialization in foo_void_offset is layed ground
for by FRE, which changes

  iftmp.3_6 = (struct Foo *) __p_5;
  if (iftmp.3_6 != 0B) goto <L0>; else goto <L1>;

<L0>:;
  this_11 = (struct Foo * const) iftmp.3_6;
  this_11->i[0] = 1;
  iftmp.3_12 = iftmp.3_6;
  goto <bb 3> (<L2>);

<L1>:;
  iftmp.3_10 = iftmp.3_6;

<L2>:;
  D.2114_7 = (struct Foo *) &i[0];
  D.2113_8 = D.2114_7->i[0];
  return D.2113_8;


to


  iftmp.3_6 = (struct Foo *) __p_5;
  if (iftmp.3_6 != 0B) goto <L0>; else goto <L1>;

<L0>:;
  this_11 = iftmp.3_6;
  this_11->i[0] = 1;
  iftmp.3_12 = iftmp.3_6;
  goto <bb 3> (<L2>);

<L1>:;
  iftmp.3_10 = iftmp.3_6;

<L2>:; 
  D.2114_7 = iftmp.3_6;
  D.2113_8 = D.2114_7->i[0];


which can then be optimized further.  This doesn't happen for the exact
same example with void * exchanged with char * -- is FRE paying attention
to some strict-aliasing rules here?  Note there is no difference in alias
information after CCP1.

For the record, the char* example mentioned would look like

int foo_char(void)
{
        int i[2];
        new (reinterpret_cast<char *>(&i[0])) Foo();
        return reinterpret_cast<Foo *>(&i[0])->i[0];
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637

[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2005-10-09 09:56 -------
Another one is the following (without any possible aliasing problems):

int foo_charchar(void)
{
        char i[2*sizeof(int)];
        new (i) Foo();
        return reinterpret_cast<Foo*>(&i[0])->i[0];
}

where we miss the FRE opportunity for the cast:

<bb 0>:
  iftmp.0 = (struct Foo *) &i[0];
  iftmp.0->i[0] = 1;
  D.2097 = (struct Foo *) &i[0];
  return D.2097->i[0];


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Missed constant propagation |Missed VRP and FRE
                   |with placement new          |opportunities in the
                   |                            |presence of casts


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637

[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-01-08 05:35 -------
(In reply to comment #8)
> Another one is the following (without any possible aliasing problems):

Actually that is still a violation of the aliasing rules, as you are acessing a
character as a Foo.  Yes that is violation, though I think GCC does not define
it as one.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637

[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2006-01-08 10:35 -------
(In reply to comment #9)
> Actually that is still a violation of the aliasing rules, as you are acessing a
> character as a Foo.  Yes that is violation, though I think GCC does not define
> it as one.

I think the code is fine - memory is accessed only as Foo (though it is
declared
as char).  This simulates

int foo_charchar(void)
{
        void *i = alloca(2*sizeof(int));
        new (i) Foo();
        return reinterpret_cast<Foo*>(i)->i[0];
}

by making the storage explicit.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637

[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts

[patchapp at dberlin dot org]

------- Comment #11 from patchapp at dberlin dot org  2007-03-05 16:30 -------
Subject: Bug number PR19637

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00295.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637

[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2008-03-17 14:35 -------
Subject: Bug 19637

Author: rguenth
Date: Mon Mar 17 14:34:21 2008
New Revision: 133291

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133291
Log:
2008-03-17  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/19637
        * fold-const.c (fold_unary): Remove restrictions of removing
        intermediate pointer-conversions (P2)(P1)P0.
        * tree-ssa-ccp.c (maybe_fold_stmt_addition): Recover from
        conversion to void pointer.
        (get_maxval_strlen): Handle addresses of the form &(*p)[0].

        * g++.dg/tree-ssa/pr19637.C: New testcase.

Added:
    trunk/gcc/testsuite/g++.dg/tree-ssa/pr19637.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-ccp.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637

[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2008-03-17 15:03 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637