[Bug c++/31809] [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code

["mark at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #6 from mark at codesourcery dot com  2007-05-30 23:02 -------
Subject: Re:  [4.1/4.2/4.3 Regression] sometimes TREE_READONLY
 is still set for non read only variables causing wrong code

mueller at gcc dot gnu dot org wrote:
> ------- Comment #5 from mueller at gcc dot gnu dot org  2007-05-30 22:46 -------
> is it okay that was_readonly will eventually turn on TREE_READONLY()
> afterwards?

I wondered about this too, but was_readonly is only set for
REFERENCE_TYPEs.  I'm not sure what happens with something like:

  int& f() { return *new int; }
  int& i = f();

Jakub, does the reference end up TREE_READONLY in that case?  If so, do
we have a problem there too?  I think we might, for something like:

  int& f() { static int x; return x; }
  int& i = f();
  int& j = i;

The compiler must not reorder this to:

  j = i;
  i = &x;

which I guess it might, since it might think that "i" never changes, and
therefore "j" can access its value at any point?

Of course, it's sad that we lose TREE_READONLY on references or "const"
variables, as we know they cannot change after initialization.  There's
no question that Jakub's change is going to make use generate inferior
code in some cases.

In fact, for the reference case, we know that "i" does not change in the
scope of any function except the static initialization function that
assigns the return value of "f" to "i".

One possible way to get some of this performance back would be to avoid
marking references as clobbered by calls -- except to the static
initialization function, which is only called from .ctors, so we can
probably ignore that.  In other words, even though "i" is not
TREE_READONLY, treat it as such when computing what can clobber it.


-- 


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