[Bug tree-optimization/86318] const local aggregates can be assumed not to be modified even when escaped

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318

--- Comment #5 from Richard Biener  ---
(In reply to Josh Haberman from comment #4)
> Is there any plan or timeline for fixing this bug?

No.  There's no agreed upon way on how to design such a fix.

[Bug tree-optimization/86318] const local aggregates can be assumed not to be modified even when escaped

[jhaberman at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318

--- Comment #4 from Josh Haberman  ---
Is there any plan or timeline for fixing this bug?

[Bug tree-optimization/86318] const local aggregates can be assumed not to be modified even when escaped

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318

Andrew Pinski  changed:

   What|Removed |Added

 CC||jhaberman at gmail dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 108217 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/86318] const local aggregates can be assumed not to be modified even when escaped

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318

Martin Sebor  changed:

   What|Removed |Added

   Host||90404

--- Comment #2 from Martin Sebor  ---
I should add that issuing a warning when an attempt is detected to modify a
const object (or subobject) as requested in pr90404 should help detect changes,
resulting from the optimization, to the behavior of code that deliberately
violates the restriction to modify constant subobjects.

[Bug tree-optimization/86318] const local aggregates can be assumed not to be modified even when escaped

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-26
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  It is the frontend doing the optimization likely during its
folding.

The middle-end doesn't in any way honor 'const' since

 const S s = {  };

can be expanded (gimplified) to a automatic variable initialized by
one or multiple assignments (so that automatic variable isn't "constant"):

For example g1:

g1 ()
{
  const int a[1];
  int _1;

   :
  a[0] = 1;
  f ();
  _1 = a[0];
  if (_1 != 1)

so here a[0] is assigned to.

If we'd always place such constants in .rodata (use a CONST_DECL) things
might work but then optimization cannot elide (parts of) such initializer.

Previously RTL had a thing like RTX_UNCHANGING which meant values do not
change once set.  But that was a recipie for desaster (wrong-code).

For simple cases like g1 the FE could fold the read from *a but I could
see the following case as difficult for the FE to "fold" (unless you
want to "constexpr" evaluate all stmts).

void g3 (void)
{
  const struct S s = { 1 };
  f ();
  struct S q = s;
  if (q.i != 1)
abort ();
}

A solution on the optimizer side is difficult, it would likely need to
separate "initialization" from "modification" somehow.  Like wrapping
the "const" a's in the accesses:

g1 ()
{
  const int a[1];
  int _1;

   :
  a[0] = 1;
  f ();
  _1 = CONST[0];

either by a bit on the reference trees or by an explicit handled-component.
The address-taking context is somewhat awkward to deal with I think.

In the end it would be the FEs responsibility to "wrap" stuff or the
gimplifier could wrap all but the initialization stmts.

Or we could do it the other way around, wrap the initialization refs.