public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/101925] New: reversed storage order when compiling with -O3 only
@ 2021-08-15 23:43 george.thopas at gmail dot com
2021-08-15 23:50 ` [Bug tree-optimization/101925] " pinskia at gcc dot gnu.org
` (12 more replies)
0 siblings, 13 replies; 14+ messages in thread
From: george.thopas at gmail dot com @ 2021-08-15 23:43 UTC (permalink / raw)
To: gcc-bugs
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;
}
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] reversed storage order when compiling with -O3 only
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
@ 2021-08-15 23:50 ` pinskia at gcc dot gnu.org
2021-08-16 8:08 ` [Bug tree-optimization/101925] [10/11/12 Regression] " marxin at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-15 23:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
2021-08-15 23:50 ` [Bug tree-optimization/101925] " pinskia at gcc dot gnu.org
@ 2021-08-16 8:08 ` marxin at gcc dot gnu.org
2021-08-16 8:22 ` [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
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-08-16 8:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
2021-08-15 23:50 ` [Bug tree-optimization/101925] " pinskia at gcc dot gnu.org
2021-08-16 8:08 ` [Bug tree-optimization/101925] [10/11/12 Regression] " marxin at gcc dot gnu.org
@ 2021-08-16 8:22 ` rguenth at gcc dot gnu.org
2021-08-16 9:27 ` ebotcazou at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-16 8:22 UTC (permalink / raw)
To: gcc-bugs
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)?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (2 preceding siblings ...)
2021-08-16 8:22 ` [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
@ 2021-08-16 9:27 ` ebotcazou at gcc dot gnu.org
2021-08-16 10:45 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2021-08-16 9:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (3 preceding siblings ...)
2021-08-16 9:27 ` ebotcazou at gcc dot gnu.org
@ 2021-08-16 10:45 ` rguenth at gcc dot gnu.org
2021-08-16 11:20 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-16 10:45 UTC (permalink / raw)
To: gcc-bugs
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);
}
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (4 preceding siblings ...)
2021-08-16 10:45 ` rguenth at gcc dot gnu.org
@ 2021-08-16 11:20 ` rguenth at gcc dot gnu.org
2021-08-16 12:20 ` ebotcazou at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-16 11:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (5 preceding siblings ...)
2021-08-16 11:20 ` rguenth at gcc dot gnu.org
@ 2021-08-16 12:20 ` ebotcazou at gcc dot gnu.org
2021-08-16 13:16 ` rguenther at suse dot de
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2021-08-16 12:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (6 preceding siblings ...)
2021-08-16 12:20 ` ebotcazou at gcc dot gnu.org
@ 2021-08-16 13:16 ` rguenther at suse dot de
2021-08-16 13:21 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2021-08-16 13:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (7 preceding siblings ...)
2021-08-16 13:16 ` rguenther at suse dot de
@ 2021-08-16 13:21 ` rguenth at gcc dot gnu.org
2021-08-17 7:25 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-16 13:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (8 preceding siblings ...)
2021-08-16 13:21 ` rguenth at gcc dot gnu.org
@ 2021-08-17 7:25 ` cvs-commit at gcc dot gnu.org
2021-09-06 8:50 ` [Bug tree-optimization/101925] [10/11 " cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-08-17 7:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10/11 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (9 preceding siblings ...)
2021-08-17 7:25 ` cvs-commit at gcc dot gnu.org
@ 2021-09-06 8:50 ` cvs-commit at gcc dot gnu.org
2021-10-13 11:09 ` [Bug tree-optimization/101925] [10 " cvs-commit at gcc dot gnu.org
2021-10-13 11:10 ` rguenth at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-09-06 8:50 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (10 preceding siblings ...)
2021-09-06 8:50 ` [Bug tree-optimization/101925] [10/11 " cvs-commit at gcc dot gnu.org
@ 2021-10-13 11:09 ` cvs-commit at gcc dot gnu.org
2021-10-13 11:10 ` rguenth at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-10-13 11:09 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug tree-optimization/101925] [10 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
` (11 preceding siblings ...)
2021-10-13 11:09 ` [Bug tree-optimization/101925] [10 " cvs-commit at gcc dot gnu.org
@ 2021-10-13 11:10 ` rguenth at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-10-13 11:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-10-13 11:10 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-15 23:43 [Bug c/101925] New: reversed storage order when compiling with -O3 only george.thopas at gmail dot com
2021-08-15 23:50 ` [Bug tree-optimization/101925] " pinskia at gcc dot gnu.org
2021-08-16 8:08 ` [Bug tree-optimization/101925] [10/11/12 Regression] " marxin at gcc dot gnu.org
2021-08-16 8:22 ` [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
2021-08-16 9:27 ` ebotcazou at gcc dot gnu.org
2021-08-16 10:45 ` rguenth at gcc dot gnu.org
2021-08-16 11:20 ` rguenth at gcc dot gnu.org
2021-08-16 12:20 ` ebotcazou at gcc dot gnu.org
2021-08-16 13:16 ` rguenther at suse dot de
2021-08-16 13:21 ` rguenth at gcc dot gnu.org
2021-08-17 7:25 ` cvs-commit at gcc dot gnu.org
2021-09-06 8:50 ` [Bug tree-optimization/101925] [10/11 " cvs-commit at gcc dot gnu.org
2021-10-13 11:09 ` [Bug tree-optimization/101925] [10 " cvs-commit at gcc dot gnu.org
2021-10-13 11:10 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).