[Bug tree-optimization/95493] New: [10 Regression] test for vector members apparently reordered with assignment to vector members

[Bug tree-optimization/95493] New: [10 Regression] test for vector members apparently reordered with assignment to vector members

[kretz at kde dot org]

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

            Bug ID: 95493
           Summary: [10 Regression] test for vector members apparently
                    reordered with assignment to vector members
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kretz at kde dot org
  Target Milestone: ---

Test case (https://godbolt.org/z/egnkd7), compile with `-O2 -std=c++17`:

#include <cstdio>

struct verify
{
  const bool m_failed = false;

  [[gnu::noinline]] void print_hex(const void* x, int n) const
  {
    const auto* bytes = static_cast<const unsigned char*>(x);
    for (int i = 0; i < n; ++i)
      __builtin_fprintf(stderr, (i && i % 4 == 0) ? "'%02x" : "%02x",
bytes[i]);
    __builtin_fprintf(stderr, "\n");
  }

  template <typename... Ts>
  verify(bool ok, const Ts&... extra_info) : m_failed(!ok)
  {
    if (m_failed)
      (print_hex(&extra_info, sizeof(extra_info)), ...);
  }

  ~verify()
  {
    if (m_failed)
      __builtin_abort();
  }
};

using K [[gnu::vector_size(16)]] = int;

int
main()
{
  int count = 1;
  asm("" : "+m"(count));
  verify(count == 1, 0, "", 0);

  {
    struct SW
    {
      K d;
    };
    struct
    {
      SW d;
    } xx;
    SW& x = xx.d;
    x = SW(); // [0, 0, 0, 0]
    for (int i = 3; i >= 2; --i)
      {
        x.d[i] = -1; // [0, 0, 0, -1] ...
        int a = [](K y) {
          for (int j = 0; j < 4; ++j)
            if (y[j] != 0)
              return j;
          return -1;
        }(x.d);
        verify(a == i, 0, 0, 0, 0, i, x);
      }
  }
}


The relevant code here is:
```
using K [[gnu::vector_size(16)]] = int;
K x = K(); // [0, 0, 0, 0]
int i = 3;
x[i] = -1; // [0, 0, 0, -1]
int j;
for (j = 0; j < 4; ++j)
  if (x[j] != 0)
     break;
if (i != j) abort();
```

In a larger testcase I could see the assignment `x[i] = -1` getting reordered
with the "count zero" function in the disassembled test case.

[Bug tree-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |9.3.0
                 CC|                            |jamborm at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
            Summary|[10 Regression] test for    |[10/11 Regression] test for
                   |vector members apparently   |vector members apparently
                   |reordered with assignment   |reordered with assignment
                   |to vector members           |to vector members since
                   |                            |r10-7523-gb90061c6ec090c6b
   Last reconfirmed|                            |2020-06-03
     Ever confirmed|0                           |1
      Known to fail|                            |10.1.0, 11.0

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r10-7523-gb90061c6ec090c6b.

[Bug middle-end/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.2
          Component|tree-optimization           |middle-end
           Keywords|                            |alias
             Target|                            |x86_64-linux-gnu

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
  VIEW_CONVERT_EXPR<int[4]>(MEM[(struct SW &)&xx].d)[i.1_2] = -1;
  _4 = MEM[(struct SW &)&xx].d;
  y = _4;

There is some aliasing issues with the store and the next load.

THe tree level is correct, it goes wrong on the RTL level.

(In reply to Martin Liška from comment #1)
> Confirmed, started with r10-7523-gb90061c6ec090c6b.

No just exposed.

[Bug rtl-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |rtl-optimization

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
>   VIEW_CONVERT_EXPR<int[4]>(MEM[(struct SW &)&xx].d)[i.1_2] = -1;
>   _4 = MEM[(struct SW &)&xx].d;
>   y = _4;
> 
> There is some aliasing issues with the store and the next load.
> 
> THe tree level is correct, it goes wrong on the RTL level.

;; VIEW_CONVERT_EXPR<int[4]>(MEM[(struct SW &)&xx].d)[i.1_2] = -1;

(insn 28 27 29 (set (reg:DI 92)
        (sign_extend:DI (reg:SI 83 [ i.1_2 ]))) "t.C":50:16 -1
     (nil))

(insn 29 28 0 (set (mem/j:SI (plus:DI (plus:DI (mult:DI (reg:DI 92)
                        (const_int 4 [0x4]))
                    (reg/f:DI 77 virtual-stack-vars))
                (const_int -32 [0xffffffffffffffe0])) [1 MEM[(struct ._anon_0
*)_42] S4 A32])
        (const_int -1 [0xffffffffffffffff])) "t.C":50:16 -1
     (nil))

;; y = _5;

(insn 30 29 31 (set (reg:V4SI 93)
        (mem/c:V4SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
                (const_int -32 [0xffffffffffffffe0])) [1 MEM[(struct SW
&)_42].d+0 S16 A128])) -1
     (nil))

(insn 31 30 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
                (const_int -16 [0xfffffffffffffff0])) [1 MEM[(vector(4) int
*)_69]+0 S16 A128])
        (reg:V4SI 93)) -1
     (nil))

alias-sets look OK, the bases look sane as well.  The only odd thing
is that (anon *) which might confuse path-based analysis.

PRE indeed decides that insn 29 does not affect the load in insn 30:

deleting insn with uid = 30.
PRE: redundant insn 30 (expression 3) in bb 4, reaching reg is 110
scanning new insn with uid = 146. 
deleting insn with uid = 34.
PRE: redundant insn 34 (expression 1) in bb 5, reaching reg is 111
PRE: edge (13,4), copy expression 1
PRE: edge (13,4), copy expression 3
PRE:  store updated with reaching reg (reg:V4SI 110 [ MEM[(struct SW &)_42].d
]): 
        (insn 109 108 110 13 (set (mem/c:V4SI (plus:DI (reg/f:DI 19 frame)
                                (const_int -32 [0xffffffffffffffe0])) [1
MEM[(struct SW *)_42].d+0 S16 A128])
                        (reg:V4SI 103)) "t.C":47:7 1347 {movv4si_internal}
                     (expr_list:REG_DEAD (reg:V4SI 103)
                        (nil)))


> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r10-7523-gb90061c6ec090c6b.
> 
> No just exposed.

[Bug rtl-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so the issue is we're getting these MEM_ATTRs when expanding the base
as

(mem/c:V4SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
        (const_int -32 [0xffffffffffffffe0])) [5 MEM[(struct ._anon_0 *)_42]+0
S16 A128])

and set_mem_attributes_minus_bitpos due to the variable array-ref wouldn't
assign any here but inherits the already set ones.

  /* Default values from pre-existing memory attributes if present.  */
  refattrs = MEM_ATTRS (ref);
  if (refattrs)
    {
      /* ??? Can this ever happen?  Calling this routine on a MEM that
         already carries memory attributes should probably be invalid.  */
      attrs.expr = refattrs->expr;
      attrs.offset_known_p = refattrs->offset_known_p;
      attrs.offset = refattrs->offset;
      attrs.size_known_p = refattrs->size_known_p;
      attrs.size = refattrs->size;
      attrs.align = refattrs->align;
    }

so the following fixes the issue, the MEM_ATTRs are not what the code
expects them to be set with otherwise.  Because clearly offset_known_p
should be false.

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 2b790636366..0a72269e2ce 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2114,6 +2114,10 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, int
objectp,
            }
          while (TREE_CODE (t2) == ARRAY_REF);

+         attrs.expr = NULL_TREE;
+         attrs.offset_known_p = false;
+         attrs.offset = 0;
+         apply_bitpos = 0;
          if (DECL_P (t2)
              || (TREE_CODE (t2) == COMPONENT_REF
                  /* For trailing arrays t2 doesn't have a size that

[Bug rtl-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Now, the real issue is of course that we fail to properly expand the inner
MEM_REF since get_inner_reference strips that away and so we expand the
decl resulting in bogus mem_attrs being applied.  That is, we like to
fix the set_mem_attrs_minus_bitpos without clearing attrs.expr but that
makes the testcase still fail.

Now, in this particular case the MEM_ATTRs should be still fine
(the access modification on the MEM_REF is a simple down-cast) so we _do_
have an underlying issue in path-based disambiguation I think.  Or
from the !MEM_OFFSET_KNOWN_P path in ao_ref_from_mem which makes the
access appear as a full def of the structure (but that shouldn't be
wrong here either).

In aliasing_component_refs_p cmp_outer is zero (accesses have the same
size), then aliasing_component_refs_walk figures cmp == 0 && same_p == 0
for record_type 0x7ffff6975e70 ._anon_0 and record_type 0x7ffff6975d20 SW.
In the opposite direction it suddenly is cmp == 1 for
vector_type 0x7ffff696bdc8 K (size 128) and record_type 0x7ffff6975e70 ._anon_0
(size 128)!?  That's because compare_type_sizes special-handling of
arrays and vectors.  So we get non-conclusive result here as well but
maybe_match remains false (don't we need to set maybe_match to true here?)

So we fall down to

  return (base2_alias_set == ref1_alias_set
          || alias_set_subset_of (base2_alias_set, ref1_alias_set));

but oddly enough we have base2_alias_set 4 and ref1_alias_set 1 here
which does not match up as ref1_type has alias-set 5.  That might be
because we have MEM_KEEP_ALIAS_SET_P set on the RTX.  Documented as

/* 1 if RTX is a mem and we should keep the alias set for this mem
   unchanged when we access a component.  Set to 1, or example, when we
   are already in a non-addressable component of an aggregate.  */
#define MEM_KEEP_ALIAS_SET_P(RTX)                                       \

this "optimization" defeats the assumptions by path-based disambiguation
which expects a match between alias sets and components here.  The
flag is set because of the VIEW_CONVERT_EXPR.

Ah, and we've updated the alias-set from the
VIEW_CONVERT_EXPR<int[4]>(MEM[(struct SW &)&xx].d)[i.1_2] expression but choose
to keep
the original one (which had a different alias-set).  That's another
source of confusion for the path-based disambiguation.  If we fix that
down the drain store_field will break it again via

7249          if (!MEM_KEEP_ALIAS_SET_P (to_rtx) && MEM_ALIAS_SET (to_rtx) !=
0)
7250            set_mem_alias_set (to_rtx, alias_set);

we can fix _that_ by adjusting the caller to preserve a MEM_ALIAS_SET if
present rather than looking at the GENERIC tree again.

[Bug rtl-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:80d6f89e78fc3b772701988cc73aa8e8006283be

commit r11-963-g80d6f89e78fc3b772701988cc73aa8e8006283be
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Jun 4 13:44:58 2020 +0200

    middle-end/95493 - bogus MEM_ATTRS for variable array access

    The following patch avoids keeping the inherited MEM_ATTRS when
    set_mem_attributes_minus_bitpos is called with a variable ARRAY_REF.
    The inherited ones may not reflect the correct offset and neither
    does the updated alias-set match the inherited MEM_EXPR.  This all
    ends up confusing path-based alias-analysis, causing wrong-code.

    The fix is to stop not adopting a MEM_EXPR for certain kinds of
    expressions and instead handle everything we can.  There's still
    the constant kind trees case which I'm too lazy to look into right
    now.  I did refrain from adding SSA_NAME there and instead avoided
    calling set_mem_attributes_minus_bitpos when debug expression
    expansion ended up expanding a SSA definition RHS which should
    already have taken care of setting the appropriate MEM_ATTRS.

    2020-06-04  Richard Biener  <rguenther@suse.de>

            PR middle-end/95493
            * cfgexpand.c (expand_debug_expr): Avoid calling
            set_mem_attributes_minus_bitpos when we were expanding
            an SSA name.
            * emit-rtl.c (set_mem_attributes_minus_bitpos): Remove
            ARRAY_REF special-casing, add CONSTRUCTOR to the set of
            special-cases we do not want MEM_EXPRs for.  Assert
            we end up with reasonable MEM_EXPRs.

            * g++.dg/torture/pr95493.C: New testcase.

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |11.0
      Known to fail|11.0                        |
            Summary|[10/11 Regression] test for |[10 Regression] test for
                   |vector members apparently   |vector members apparently
                   |reordered with assignment   |reordered with assignment
                   |to vector members since     |to vector members since
                   |r10-7523-gb90061c6ec090c6b  |r10-7523-gb90061c6ec090c6b

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493
Bug 95493 depends on bug 95690, which changed state.

Bug 95690 Summary: [11 Regression] ICE in set_mem_attributes_minus_bitpos, at emit-rtl.c:2092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95690

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This also fixes a regression introduced by:

    alias.c (ao_ref_from_mem): Move stack-slot sharing rewrite ...

    2019-05-22  Richard Biener  <rguenther@suse.de>

            * alias.c (ao_ref_from_mem): Move stack-slot sharing
            rewrite ...
            * emit-rtl.c (set_mem_attributes_minus_bitpos): ... here.

    From-SVN: r271510

See https://gcc.gnu.org/pipermail/gcc-help/2020-June/139060.html which has the
following testcase (modified by me to abort instead of just print things out):

#include <array>
#include <iostream>

struct Point
{
    std::array<int, 3> array;

    Point(int x, int y, int z) : array{x, y, z} {}

    Point(const Point & other) : array{other.array} {} // OK if commented
    //Point(const Point &) = default; // OK

    //Point(Point && other) = default; // OK

    int  operator[] (std::size_t i) const { return array[i]; }
    int& operator[] (std::size_t i)       { return array[i]; }
};

//using Point = std::array<int, 3>; // OK

struct Cell
{
    Point point;
    Cell(Point const& pt) : point(pt) {}
    int   operator[] (std::size_t i) const { return point[i]; }
    int&  operator[] (std::size_t i)       { return point[i]; }
};

//using Cell = Point; // OK

std::ostream & operator<< (std::ostream & out, Cell const& object)
//std::ostream & operator<< (std::ostream & out, Cell object) // Fails with f2
too
{
    for ( std::size_t i = 0; i < 3; ++i )
        out << object[ i ] << " ";
    return out;
}


struct DirIterator
{
    std::size_t dir;
    Cell cell;

    DirIterator(Cell c)
        : dir(0), cell(c)
    {
        find(); // OK if commented
    }

    void find()
    {
        //while (dir < 3) // Fails with f2 too
        while (dir < 3 && (cell[dir] % 2) == 0)
            ++dir;
    }
};

Cell uIncident(Cell c, std::size_t k)
//Cell uIncident(Cell& c, std::size_t k) // OK
{
    --c[k];
    return c;
}

Cell uSpel(Point p)
{
    for (std::size_t i = 0; i < 3; ++i)
        p[i] += p[i] + 1;
    return Cell(p);
}


int main () {
    Cell c = uSpel(Point{0, 0, 0}); // Fails
    //Cell c( Point(1, 1, 1) ); // OK

    auto q = DirIterator( c );

    Cell f1 = uIncident( c, q.dir ); // Fails
    //Cell f1 = uIncident( c, 0 ); // OK

    Cell f2 = f1; // f2 is the right cell that f1 should be

    std::cout << "q.dir = " << q.dir << " ; f1 = " << f1 << " ; f2 = " << f2 <<
std::endl;
    //std::cout << "q.dir = " << q.dir << " ; f1 = " << f1[0] << " " << f1[1]
<< " " << f1[2] << " ; f2 = " << f2[0] << " " << f2[1] << " " << f2[2] <<
std::endl; // OK

    for (int i = 0; i < 3; ++i)
      if (f1[i] != f2[i])
        __builtin_abort();

    return 0;
}

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:d4b0f996fc497fba8724960107c3b52d3011c117

commit r11-1408-gd4b0f996fc497fba8724960107c3b52d3011c117
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Jun 16 23:14:23 2020 +0100

    middle-end: Add another testcase for PR 95493

    This was reported on the gcc-help mailing list. The regression started
    with r10-589 and was fixed by r11-963.

    gcc/testsuite/ChangeLog:

            * g++.dg/torture/pr95493-1.C: New test.

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[kretz at kde dot org]

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

--- Comment #10 from Matthias Kretz (Vir) <kretz at kde dot org> ---
(In reply to Richard Biener from comment #7)
> Fixed on trunk sofar.

Is there anything I can help to get this backported to 10? I applied your patch
on my GCC 10 checkout since you committed it to master and have not had any
issues.

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Matthias Kretz (Vir) from comment #10)
> (In reply to Richard Biener from comment #7)
> > Fixed on trunk sofar.
> 
> Is there anything I can help to get this backported to 10? I applied your
> patch on my GCC 10 checkout since you committed it to master and have not
> had any issues.

It will certainly make 10.2 but I was afraid of fallout (which eventually
happened, see PR95690), so now waiting some more for the fallout from the
fallout fix ;)

But I hope to get to a round of backporting next week.

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:7d919c33fbd29a996326840dae3b5e093c3190f4

commit r10-8355-g7d919c33fbd29a996326840dae3b5e093c3190f4
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Jun 4 13:44:58 2020 +0200

    middle-end/95493 - bogus MEM_ATTRS for variable array access

    The following patch avoids keeping the inherited MEM_ATTRS when
    set_mem_attributes_minus_bitpos is called with a variable ARRAY_REF.
    The inherited ones may not reflect the correct offset and neither
    does the updated alias-set match the inherited MEM_EXPR.  This all
    ends up confusing path-based alias-analysis, causing wrong-code.

    The fix is to stop not adopting a MEM_EXPR for certain kinds of
    expressions and instead handle everything we can.  There's still
    the constant kind trees case which I'm too lazy to look into right
    now.  I did refrain from adding SSA_NAME there and instead avoided
    calling set_mem_attributes_minus_bitpos when debug expression
    expansion ended up expanding a SSA definition RHS which should
    already have taken care of setting the appropriate MEM_ATTRS.

    It also avoids calling set_mem_attributes on the
    DECL_INITIAL of a CONST_DECL which seems pointless since there
    cannot be a sensible MEM_EXPR derived from that.  We're overwriting
    both other possibly useful info, alias-set and alignment immediately
    so the following patch simply removes the call instead of making
    the function deal with even more (unexpected) trees that are not
    memory accesses.

    2020-06-23  Richard Biener  <rguenther@suse.de>

            PR middle-end/95493
            PR middle-end/95690
            * cfgexpand.c (expand_debug_expr): Avoid calling
            set_mem_attributes_minus_bitpos when we were expanding
            an SSA name.
            * emit-rtl.c (set_mem_attributes_minus_bitpos): Remove
            ARRAY_REF special-casing, add CONSTRUCTOR to the set of
            special-cases we do not want MEM_EXPRs for.  Assert
            we end up with reasonable MEM_EXPRs.
            * varasm.c (build_constant_desc): Remove set_mem_attributes call.

            * g++.dg/torture/pr95493.C: New testcase.
            * g++.dg/torture/pr95493-1.C: Likewise.
            * gfortran.dg/pr95690.f90: Likewise.

[Bug rtl-optimization/95493] [10 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |10.1.1
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED
           Priority|P3                          |P2

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.