[Bug c/101925] New: reversed storage order when compiling with -O3 only

[Bug c/101925] New: reversed storage order when compiling with -O3 only

[george.thopas at gmail dot com]

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

            Bug ID: 101925
           Summary: reversed storage order when compiling with -O3 only
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: george.thopas at gmail dot com
  Target Milestone: ---

/*
     reversed storage order when compiling with -O3 only. 
     this time sets up an all big-endian struct 
     from an all little-endian one
     no warnings 

     Target: x86_64-pc-linux-gnu
     gcc versie 11.1.0 (Gentoo 11.1.0-r2 p3) 
     gcc-trunk too

     $ gcc -Wall -Wextra -O3 test.c 
     $ ./a.out 
     Abort 

 */


#define BIG_ENDIAN   __attribute__((scalar_storage_order("big-endian")))

/* host order version (little endian)*/
struct _ip6_addr {
    union {
        char addr8[16];
        int  addr32[4];
    } u;
};

typedef struct _ip6_addr t_ip6_addr;

struct _net_addr {
    char is_v4;
    union {
        int        addr;
        t_ip6_addr addr6;
    } u;
};

typedef struct _net_addr t_net_addr;

/* big endian version */
struct _be_ip6_addr {
    union {
        char addr8[16];
    } BIG_ENDIAN u;
} BIG_ENDIAN;

typedef struct _be_ip6_addr t_be_ip6_addr;

struct _be_net_addr {
    char is_v4;
    union {
        t_be_ip6_addr addr6;
        int           addr;
    } BIG_ENDIAN u;
} BIG_ENDIAN;

typedef struct _be_net_addr t_be_net_addr;

/* convert */
t_be_ip6_addr be_ip6_addr(const t_ip6_addr ip6)
{
    t_be_ip6_addr rc = {
        .u.addr8[0] = ip6.u.addr8[0],
        .u.addr8[1] = ip6.u.addr8[1],
        .u.addr8[2] = ip6.u.addr8[2],
        .u.addr8[3] = ip6.u.addr8[3],
        .u.addr8[4] = ip6.u.addr8[4],
        .u.addr8[5] = ip6.u.addr8[5],
        .u.addr8[6] = ip6.u.addr8[6],
        .u.addr8[7] = ip6.u.addr8[7],
        .u.addr8[8] = ip6.u.addr8[8],
        .u.addr8[9] = ip6.u.addr8[9],
        .u.addr8[10] = ip6.u.addr8[10],
        .u.addr8[11] = ip6.u.addr8[11],
        .u.addr8[12] = ip6.u.addr8[12],
        .u.addr8[13] = ip6.u.addr8[13],
        .u.addr8[14] = ip6.u.addr8[14],
        .u.addr8[15] = ip6.u.addr8[15],
    };
    return rc;
}

t_be_net_addr be_net_addr(const t_net_addr ip)
{
    t_be_net_addr rc = {.is_v4 = ip.is_v4 };
    if (ip.is_v4) {
        rc.u.addr = ip.u.addr;
    } else {
        rc.u.addr6 = be_ip6_addr(ip.u.addr6);
    }
    return rc;
}

int main(void)
{
    t_be_net_addr out = { };

    t_net_addr in = {
        .is_v4 = 0,
        .u.addr6.u.addr8 =
            { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 }
    };

    out = be_net_addr(in);

    // actually first 4 bytes are swapped
    if (in.u.addr6.u.addr8[0] != out.u.addr6.u.addr8[0])
        __builtin_abort();

    return 0;
}

[Bug tree-optimization/101925] reversed storage order when compiling with -O3 only

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |tree-optimization
   Last reconfirmed|                            |2021-08-15
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like the SLP vectorizer this.
-O3 -fno-tree-slp-vectorize works.

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org
            Summary|reversed storage order when |[10/11/12 Regression]
                   |compiling with -O3 only     |reversed storage order when
                   |                            |compiling with -O3 only

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r10-4742-g9b75f56d4b7951c6.

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |ebotcazou at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
   Target Milestone|---                         |10.4
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, I suppose when the vectorizer detects grouped loads/stores in
vect_analyze_data_ref_accesses we have to give up.

OTOH even w/o grouped loads the vectorizer will rewrite a.b.c[i] to
MEM_REFs based on 'a' and thus not properly retain the reverse storage
attributes.

Which means a fix in vect_analyze_data_refs would be better?  OTOH other
loop optimizations also rely on refs that pass through data-ref analysis
to be reconstructible from the analyzed base + offset so even better
fail in data-ref analysis already?  I suppose that for regular loop opts
it might work to just set REF_REVERSE_STORAGE_ORDER on a MEM_REF
created from base + offset when the original DR_REF had that set?
But when vectorizing we're using a vector type for the access and clearly
the storage order bits apply to the component (which we _usually_ do not
change).

Eric, any suggestions?  Given the above I'd just fix vect_analyze_data_refs
and leave other loop opts "latent" (I can't actually think of a broken one)?

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Eric, any suggestions?  Given the above I'd just fix vect_analyze_data_refs
> and leave other loop opts "latent" (I can't actually think of a broken one)?

Fine with me.

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So surprisingly the following is not enough to fix it.  We still get some
vectorizations but those are obviously not with reverse storage accesses.

Forcing be_net_addr to be -O0 works around the issue so it's vectorizing
of this function.  Likewise not inlining be_ip6_addr fixes it as well.

Disabling SRA fixes it also, and I think that SRA drops the rev storage order
access attribute.  Oddly enough for be_ip6_addr I see the rc.u.addr8[]
accesses do _not_ result in reverse_storage_order_for_component_p being true.
Why's that so?  How should I detect this is subject to re-ordering?

diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index d594c0a1b1e..9591d8b9d1a 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -4291,6 +4291,27 @@ vect_analyze_data_refs (vec_info *vinfo, poly_uint64
*min_vf, bool *fatal)
       stmt_info->dr_aux.dr = dr;
       stmt_info->dr_aux.stmt = stmt_info;

+      /* We cannot preserve reverse storage order accesses when
+         vectorizing.  */
+      if (reverse_storage_order_for_component_p (DR_REF (dr)))
+       {
+         if (dump_enabled_p ())
+           dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+                            "not vectorized: ref with reverse storage "
+                            "order in %G", stmt_info->stmt);
+         if (is_a <bb_vec_info> (vinfo))
+           {
+             /* In BB vectorization the ref can still participate
+                in dependence analysis, we just can't vectorize it.  */
+             STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+             continue;
+           }
+         return opt_result::failure_at (stmt_info->stmt,
+                                        "not vectorized:"
+                                        " ref with reverse storage order: %G",
+                                        stmt_info->stmt);
+       }
+
       /* Check that analysis of the data-ref succeeded.  */
       if (!DR_BASE_ADDRESS (dr) || !DR_OFFSET (dr) || !DR_INIT 


I've used for debuggging

diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index d6e63d6e57f..ac5d760efeb 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -665,6 +665,9 @@ dump_gimple_assign (pretty_printer *buffer, const gassign
*gs, int spc,
        {
          dump_generic_node (buffer, gimple_assign_lhs (gs), spc, flags,
false);
          pp_space (buffer);
+
+         if (reverse_storage_order_for_component_p (gimple_assign_lhs (gs)))
+           pp_string (buffer, "{rev}");
          pp_equal (buffer);

          if (gimple_assign_nontemporal_move_p (gs))
@@ -673,6 +676,8 @@ dump_gimple_assign (pretty_printer *buffer, const gassign
*gs, int spc,
          if (gimple_has_volatile_ops (gs))
            pp_string (buffer, "{v}");

+         if (reverse_storage_order_for_component_p (gimple_assign_rhs1 (gs)))
+           pp_string (buffer, "{rev}");
          pp_space (buffer);
        }

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Interestingly when I use

struct _be_ip6_addr {
    union {
        short addr8[16];
    } BIG_ENDIAN u;
} BIG_ENDIAN;

(note 'short' instead of 'char') I _do_ get

      rc.u.addr8[0] {rev}= _2;
...
      rc.u.addr8[1] {rev}= _4;
...

so either the testcase is bogus or I fail to capture the desired semantics
here.  We do end up with aggregate copies here after inlining:

  rc.u.addr6 = D.2017;

(note also no reverse storage marker).  But then SRA comes along and
scalarizes that aggregate copy:

   <bb 3> :
   _3 = ip.u.addr;
-  rc.u.addr {rev}= _3;
+  rc$u$addr_152 = _3;
   goto <bb 5>; [INV]
...
+  rc.u.addr6.u.addr8[0] = SR.48_91;
+  rc.u.addr6.u.addr8[1] = SR.49_92;
+  rc.u.addr6.u.addr8[2] = SR.50_93;
+  rc.u.addr6.u.addr8[3] = SR.51_94;
+  rc.u.addr6.u.addr8[4] = SR.52_95;
+  rc.u.addr6.u.addr8[5] = SR.53_96;
+  rc.u.addr6.u.addr8[6] = SR.54_97;
+  rc.u.addr6.u.addr8[7] = SR.55_98;
+  rc.u.addr6.u.addr8[8] = SR.56_99;
+  rc.u.addr6.u.addr8[9] = SR.57_100;
+  rc.u.addr6.u.addr8[10] = SR.58_101;
+  rc.u.addr6.u.addr8[11] = SR.59_102;
+  rc.u.addr6.u.addr8[12] = SR.60_103;
+  rc.u.addr6.u.addr8[13] = SR.61_104;
+  rc.u.addr6.u.addr8[14] = SR.62_105;
+  rc.u.addr6.u.addr8[15] = SR.63_106;
+  rc$u$addr_123 ={rev} MEM <int32_t> [(union  *)&rc + 4B];
(??)
...
+  rc.is_v4 {rev}= rc$is_v4_74;
+  rc.u.addr {rev}= rc$u$addr_8;
+  MEM <char> [(struct _be_net_addr *)&rc + 8B] = rc$u$addr6$u$addr8$4_47;
+  MEM <char> [(struct _be_net_addr *)&rc + 9B] = rc$u$addr6$u$addr8$5_48;
+  MEM <char> [(struct _be_net_addr *)&rc + 10B] = rc$u$addr6$u$addr8$6_49;
+  MEM <char> [(struct _be_net_addr *)&rc + 11B] = rc$u$addr6$u$addr8$7_50;
+  MEM <char> [(struct _be_net_addr *)&rc + 12B] = rc$u$addr6$u$addr8$8_51;
+  MEM <char> [(struct _be_net_addr *)&rc + 13B] = rc$u$addr6$u$addr8$9_52;
+  MEM <char> [(struct _be_net_addr *)&rc + 14B] = rc$u$addr6$u$addr8$10_53;
+  MEM <char> [(struct _be_net_addr *)&rc + 15B] = rc$u$addr6$u$addr8$11_54;
+  MEM <char> [(struct _be_net_addr *)&rc + 16B] = rc$u$addr6$u$addr8$12_55;
+  MEM <char> [(struct _be_net_addr *)&rc + 17B] = rc$u$addr6$u$addr8$13_56;
+  MEM <char> [(struct _be_net_addr *)&rc + 18B] = rc$u$addr6$u$addr8$14_57;
+  MEM <char> [(struct _be_net_addr *)&rc + 19B] = rc$u$addr6$u$addr8$15_58;
   <retval> = rc;

I'm somewhat lost as to how this works.

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Disabling SRA fixes it also, and I think that SRA drops the rev storage order
> access attribute.  Oddly enough for be_ip6_addr I see the rc.u.addr8[]
> accesses do _not_ result in reverse_storage_order_for_component_p being true.
> Why's that so?  How should I detect this is subject to re-ordering?

Because semantically this does not change anything, but I agree that the flag
should be set in this case too for the sake of the optimizer.  Please remove
the test on QImode on line 8844 in c/c-decl.c.

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 16 Aug 2021, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101925
> 
> --- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > Disabling SRA fixes it also, and I think that SRA drops the rev storage order
> > access attribute.  Oddly enough for be_ip6_addr I see the rc.u.addr8[]
> > accesses do _not_ result in reverse_storage_order_for_component_p being true.
> > Why's that so?  How should I detect this is subject to re-ordering?
> 
> Because semantically this does not change anything, but I agree that the flag
> should be set in this case too for the sake of the optimizer.  Please remove
> the test on QImode on line 8844 in c/c-decl.c.

OK, so that fixes it with the vectorizer patch.  But then I have no
idea why it breaks in the first place.  With -fdbg-cnt=4:4 (the
only "single" vect case that breaks) I see

   <bb 2> [local count: 1073741824]:
   ip$is_v4_20 = ip.is_v4;
-  rc = {};
+  MEM <char[3]> [(struct _be_net_addr *)&rc + 1B] = {};
   if (ip$is_v4_20 != 0)

(huh, guess DSE goes bonkers)

-  _85 = MEM <unsigned int> [(union  *)&ip + 4B];
+  vect_ip6_u_addr8_0_21.88_86 = MEM <const vector(4) char> [(union  *)&ip 
+ 4B];
...

-  MEM <unsigned int> [(union  *)&rc + 4B] = _85;
-  rc$u$addr_41 ={rev} MEM <int32_t> [(union  *)&rc + 4B];
+  _39 = VIEW_CONVERT_EXPR<int>(vect_ip6_u_addr8_0_21.88_86);

looks like bogus FRE here.

So both not really vectorization but followup opt issues.  
-fdisable-tree-fre5 makes the testcase work.  We're copying
REF_REVERSE_STORAGE_ORDER in copy_reference_ops_from_ref but
vn_reference_eq doesn't compare .reverse, it only has some
early complete out on V_C_E with reverse (aka storage order
barriers - whatever those exactly are).  Also vn_reference_lookup_3
uses contains_storage_order_barrier_p in two places but that
again only checks for the V_C_E barrier, not for reverse accesses.

So we're running into

  /* 4) Assignment from an SSA name which definition we may be able
     to access pieces from or we can combine to a larger entity.  */
  else if (known_eq (ref->size, maxsize)
           && is_gimple_reg_type (vr->type)
           && !contains_storage_order_barrier_p (vr->operands)
           && gimple_assign_single_p (def_stmt)
           && TREE_CODE (gimple_assign_rhs1 (def_stmt)) == SSA_NAME)
    {
...
      reverse = reverse_storage_order_for_component_p (lhs);
      tree def_rhs = gimple_assign_rhs1 (def_stmt);
      if (!reverse
          && !storage_order_barrier_p (lhs)
          && known_size_p (maxsize2)
          && known_eq (maxsize2, size2)
          && adjust_offsets_for_equal_base_address (base, &offset,
                                                    base2, &offset2))
        {

since LHS is

MEM <vector(4) char> [(union  *)&rc + 4B] = vect_ip6_u_addr8_0_21.88_86;

that doesn't trigger anything.  But the ref we're looking at (vr) is
from

rc$u$addr_41 ={rev} MEM <int32_t> [(union  *)&rc + 4B];

but we don't check that for reverse_storage_order_for_component_p.
We do have check contains_storage_order_barrier_p which easily(?)
could at least look for other .reverse == 1 compontents but
reverse_storage_order_for_component_p is a bit more complicated
due to how it handles array and component refs based on their
aggregate base TYPE_REVERSE_STORAGE_ORDER.  I suppose we could
set .reverse for those in copy_reference_ops_from_ref as well.

That fixes it.

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 51308
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51308&action=edit
patch

I am testing this patch.

[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 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:0215b3559e55f39f38e10984a804c53907f7491c

commit r12-2939-g0215b3559e55f39f38e10984a804c53907f7491c
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Aug 16 15:17:08 2021 +0200

    tree-optimization/101925 - fix VN with reverse storage order

    This fixes value-numbering breaking reverse storage order accesses
    due to a missed check.  It adds a new overload for
    reverse_storage_order_for_component_p and sets reversed on the
    VN IL ops for component and array accesses accordingly.
    It also compares the reversed reference ops flag on reference
    lookup.

    2021-08-16  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/101925
            * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Set
            reverse on COMPONENT_REF and ARRAY_REF according to
            what reverse_storage_order_for_component_p does.
            (vn_reference_eq): Compare reversed on reference ops.
            (reverse_storage_order_for_component_p): New overload.
            (vn_reference_lookup_3): Check
reverse_storage_order_for_component_p
            on the reference looked up.

            * gcc.dg/sso-16.c: New testcase.

[Bug tree-optimization/101925] [10/11 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-8965-g7f584a309092896bdbe83655fb5f425ac8adc019
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Aug 16 15:17:08 2021 +0200

    tree-optimization/101925 - fix VN with reverse storage order

    This fixes value-numbering breaking reverse storage order accesses
    due to a missed check.  It adds a new overload for
    reverse_storage_order_for_component_p and sets reversed on the
    VN IL ops for component and array accesses accordingly.
    It also compares the reversed reference ops flag on reference
    lookup.

    2021-08-16  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/101925
            * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Set
            reverse on COMPONENT_REF and ARRAY_REF according to
            what reverse_storage_order_for_component_p does.
            (vn_reference_eq): Compare reversed on reference ops.
            (reverse_storage_order_for_component_p): New overload.
            (vn_reference_lookup_3): Check
reverse_storage_order_for_component_p
            on the reference looked up.

            * gcc.dg/sso-16.c: New testcase.

    (cherry picked from commit 0215b3559e55f39f38e10984a804c53907f7491c)

[Bug tree-optimization/101925] [10 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[cvs-commit at gcc dot gnu.org]

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

--- 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:66615029ec831da23b481cd3a01e90cff02c6891

commit r10-10207-g66615029ec831da23b481cd3a01e90cff02c6891
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Aug 16 15:17:08 2021 +0200

    tree-optimization/101925 - fix VN with reverse storage order

    This fixes value-numbering breaking reverse storage order accesses
    due to a missed check.  It adds a new overload for
    reverse_storage_order_for_component_p and sets reversed on the
    VN IL ops for component and array accesses accordingly.
    It also compares the reversed reference ops flag on reference
    lookup.

    2021-08-16  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/101925
            * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Set
            reverse on COMPONENT_REF and ARRAY_REF according to
            what reverse_storage_order_for_component_p does.
            (vn_reference_eq): Compare reversed on reference ops.
            (reverse_storage_order_for_component_p): New overload.
            (vn_reference_lookup_3): Check
reverse_storage_order_for_component_p
            on the reference looked up.

            * gcc.dg/sso-16.c: New testcase.

    (cherry picked from commit 0215b3559e55f39f38e10984a804c53907f7491c)

[Bug tree-optimization/101925] [10 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |10.3.1
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

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