User account creation filtered due to spam.

Bug 30088 - [4.2 Regression] Unexpected compilation results: -O1 vs. -O1 -fstrict-aliasing
Summary: [4.2 Regression] Unexpected compilation results: -O1 vs. -O1 -fstrict-aliasing
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.1
: P1 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: alias, monitored, wrong-code
: 33573 (view as bug list)
Depends on: 30567
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-06 16:59 UTC by Heikki Tauriainen
Modified: 2009-03-30 19:43 UTC (History)
9 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 4.0.3 4.3.0
Known to fail: 4.1.0 4.1.1 4.1.2 4.2.0 4.2.1 4.2.2 4.2.5
Last reconfirmed: 2006-12-07 07:17:26


Attachments
Preprocessed source of test case (52.62 KB, application/octet-stream)
2006-12-06 17:01 UTC, Heikki Tauriainen
Details
reduced testcase (880 bytes, text/plain)
2007-02-05 14:07 UTC, Richard Biener
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heikki Tauriainen 2006-12-06 16:59:47 UTC
The following C++ program (preprocessed source attached) produces unexpected results when compiled with -O1 -fstrict-aliasing (as opposed to -O1 only) or with any higher level of optimization (-O2 or -O3).  No compilation warnings are emitted in any of the cases.


#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;
};

struct B
{
  B(const char* s) : _s(s) { }
  std::string g() { return std::string(_s); }
  const char* _s;
};

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

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


Compilation results:

$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../src/configure --prefix=/opt/gcc-4.1.1
Thread model: posix
gcc version 4.1.1
$ g++ -W -Wall -O1 testcase.cc      
$ ./a.out
$ g++ -W -Wall -O1 -fstrict-aliasing testcase.cc
$ ./a.out
a.out: testcase.cc:34: int main(): Assertion `a._x > 0.0 && a._y > 0.0' failed.
Aborted


The assertion ceases to fail (with -O1 -fstrict-aliasing) when adding any (single one) of the options -fno-tree-copy-prop, -fno-tree-dce, -fno-tree-salias or -fno-inline to the compiler command line.
Comment 1 Heikki Tauriainen 2006-12-06 17:01:10 UTC
Created attachment 12757 [details]
Preprocessed source of test case
Comment 2 Wolfgang Bangerth 2006-12-07 07:17:26 UTC
Confirmed. There are also no warnings with -Wstrict-aliasing.
The code certainly seems ok, so this is either a bug in
gcc or libstdc++...

W.
Comment 3 Wolfgang Bangerth 2006-12-07 07:23:24 UTC
This is a regression from 4.0 and the last 4.1 snapshot I have (which is 
from 20051109 -- I know, I don't get to work on gcc any more :-( ). As per
the reporter's report, the bug has apparently been backported to the 4.1 branch.

I would rate this as a critical wrong-code regression worth looking at by
the aliasing people...

W.
Comment 4 Richard Biener 2007-02-05 12:17:13 UTC
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.
Comment 5 Richard Biener 2007-02-05 12:30:38 UTC
We have (alias1):

Type memory tags

TMT.89, UID 17988, struct basic_string<char,std::char_traits<char>,std::allocator<char> >, is an alias tag, is addressable, is global, call clobbered
...
TMT.95, UID 17994, float, is addressable, may aliases: { SFT.74 SFT.75 }

a, UID 16758, struct A, is addressable, sub-vars: { SFT.75 SFT.74 }

Variable: SFT.74, UID 17973, float, is addressable, call clobbered, default def: SFT.74_11, may aliases: { TMT.89 }

Variable: SFT.75, UID 17974, float, is addressable, call clobbered, default def: SFT.75_9, may aliases: { TMT.89 }


I believe this is all caused because we cannot prove that the string data
cannot point to a.

Note that the testcase passes if you change the signature from A::f() to
get 'i' as value and not reference.
Comment 6 Richard Biener 2007-02-05 14:07:58 UTC
Created attachment 13008 [details]
reduced testcase

This is a reduced testcase (still requires libstdc++ at link time) where you
can see the wrong alias symbols used after copyprop1 with
-O -fstrict-aliasing --param max-aliased-vops=0
Comment 7 Richard Biener 2007-02-05 14:10:19 UTC
4.1.0 works, so this is a regression on the branch.  Janis, can you hunt what broke it?
Comment 8 Richard Biener 2007-02-05 14:52:07 UTC
Actually the original testcase also fails with 4.1.0.
Comment 9 Janis Johnson 2007-04-25 01:11:57 UTC
The test also fails on powerpc-linux, so it's not specific to i686-linux.  The results seem to be inconsistent, so I'm doing more testing to determine whether the failure is intermittent.
Comment 10 Andrew Pinski 2007-04-25 01:16:56 UTC
This is most likely related to PR 30567.
Comment 11 Steven Bosscher 2007-11-14 10:00:11 UTC
Is this still a problem?
Comment 12 Janis Johnson 2007-11-14 17:51:27 UTC
The submitter's testcase fails on powerpc-linux with the current 4.1 and 4.2 branches but has passed on mainline for several months.  In comment #9 I said that results seemed to be intermittent; if it would be worthwhile I can try with more revisions between 4.0 and 4.1 to find where it started failing, and also later dates to find when it stopped failing.
Comment 13 Manuel López-Ibáñez 2007-11-14 18:35:55 UTC
(In reply to comment #12)
> The submitter's testcase fails on powerpc-linux with the current 4.1 and 4.2
> branches but has passed on mainline for several months.  In comment #9 I said
> that results seemed to be intermittent; if it would be worthwhile I can try
> with more revisions between 4.0 and 4.1 to find where it started failing, and
> also later dates to find when it stopped failing.

Shouldn't the testcase be added to the testsuite?
Comment 14 Volker Reichelt 2007-12-26 16:17:13 UTC
The original testcase fails on i686-pc-linux-gnu with -O2 on the 4.1 branch and the 4.2 branch.
Comment 15 Volker Reichelt 2007-12-26 16:18:40 UTC
*** Bug 33573 has been marked as a duplicate of this bug. ***
Comment 16 Volker Reichelt 2007-12-26 16:37:59 UTC
The following reduced testcase (which should return 0) returns 1 on the 4.1 branch and 4.2 branch when compiled with "-O -fstrict-aliasing" or "-O2" on
i686-pc-linux-gnu:

=======================================================
#include <string>

struct A
{
  float x, y;
  A() : x(), y() {}
  float& foo(const int& i) { return i ? x : y; }
};

int main()
{
  if (!"")
    return 1;
  A a;
  if (!std::string("").compare(std::string("")))
    a.foo(0) = 1;
  else if (std::string("").compare(std::string("")))
    std::string("").compare(std::string(""));
  return !a.y;
}
=======================================================
Comment 17 Richard Biener 2008-02-04 16:09:35 UTC
Trunk is fine.
Comment 18 Joseph S. Myers 2008-07-04 21:45:13 UTC
Closing 4.1 branch.
Comment 19 Joseph S. Myers 2009-03-30 19:43:42 UTC
Closing 4.2 branch, fixed in 4.3.