[Bug tree-optimization/83041] redundant assignment from member array not eliminated

2017-11-21 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83041

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Richard Biener  ---
Dup (has patch).

*** This bug has been marked as a duplicate of bug 23094 ***

[Bug tree-optimization/83041] redundant assignment from member array not eliminated

2017-11-20 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83041

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=23094

--- Comment #3 from Martin Sebor  ---
For what it's worth, I first noticed it in the following (arguably more
compelling) test case:

$ cat c.c && gcc -g -O2 -S -Wall -fdump-tree-strlen=/dev/stdout c.c
char a[4];

struct A { char a[4]; };

void f (struct A *p)
{
  __builtin_strcpy (a, p->a);
  __builtin_strcpy (a, p->a);
  __builtin_strcpy (a, p->a);
}

;; Function f (f, funcdef_no=0, decl_uid=1897, cgraph_uid=0, symbol_order=1)

f (struct A * p)
{
  char[4] * _1;

   [local count: 1]:
  _1 = &p_2(D)->a;
  __builtin_strcpy (&a, _1);
  __builtin_strcpy (&a, _1);
  __builtin_strcpy (&a, _1);
  return;

}

[Bug tree-optimization/83041] redundant assignment from member array not eliminated

2017-11-20 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83041

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> I think we have a duplicate bug for this looking like

Yes bug 23094.

[Bug tree-optimization/83041] redundant assignment from member array not eliminated

2017-11-20 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83041

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-20
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Both references get alias-set zero.  Given we do not know the dynamic type of
'a'
there can be very well a struct A live at that point which means p might point
to a.  For g there cannot be a B at a because it won't fit.

We do not figure the "redundant" assignments because we're not able to
CSE p->a[0] to the previous a[0] store.  This "trick" is not implemented.

I think we have a duplicate bug for this looking like

void foo (int *p, int *q)
{
  *p = 1;
  *q = 1;
  return *p;
}

which we should be able to optimize to return 1.