[Bug tree-optimization/30088] [4.1 Regression] Unexpected compilation results: -O1 vs. -O1 -fstrict-aliasing
------- 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
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Reply to: