[Bug tree-optimization/30088] [4.1 Regression] Unexpected compilation results: -O1 vs. -O1 -fstrict-aliasing

["rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #4 from rguenth at gcc dot gnu dot org  2007-02-05 12:17 -------
Slightly reduced testcase:

#include <cassert>
#include <string>

struct A
{
  A() : _x(0.0), _y(0.0) { }
  float& f(const int& i) { return (i == 0 ? _x : _y); }
  float _x, _y;
};

A h(const char* s)
{
  A a;
  std::string b("");
  std::string s_(s);
  if (s_.compare(b) == 0)
    a.f(0) = a.f(1) = 1.0;
  else if (std::string(s).compare(std::string("")))
    s_.compare(b);
  return a;
}

int main()
{
  A a(h(""));
  assert(a._x > 0.0 && a._y > 0.0);
  return 0;
}

For some reason we see the stores to a._x and a._y in TMT.89:

  #   TMT.89_678 = V_MAY_DEF <TMT.89_677>;
  a._x = 0.0;
  #   TMT.89_679 = V_MAY_DEF <TMT.89_678>;
  a._y = 0.0;

but later discover they have SFTs (after copyprop1 where we cprop &a._x and
&a._y into the PHI node from the COND_EXPR inlined from A::f()):

  #   SFT.74_209 = V_MAY_DEF <SFT.74_11>;
  #   SFT.75_208 = V_MAY_DEF <SFT.75_9>;
  *D.17209_8 = 1.0e+0;
  #   VUSE <SFT.74_209>;
  #   VUSE <SFT.75_208>;
  D.16796_566 = *D.17209_8;

so this is either (again) a pruning issue or we get it wrong in the sense
that TMT.89 also is used for integer type.


-- 


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