https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #5 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
In:
_1 = src_6(D)->a;
dst$val_9 = _1;
_2 = BIT_FIELD_REF <dst$val_9, 8, 0>;
_3 = _2 & 64;
if (_3 != 0)
src, dst and the BIT_FIELD_REF carry storage order flags which result in either
bswaps being emitted or, in case of the bitfield, the constant for the compare
to be adjusted. So from reading "src" to evaluating "_2" 3 "bswaps" will be
applied. After dropping the assignment to dst only two remain which cancel each
other out. So in the end we access the value without any adjustments.
Just to check I did:
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index b36dd97802b..b858194a432 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -1820,6 +1820,7 @@ handle_scalar_storage_order_attribute (tree *node, tree
name, tree args,
}
TYPE_REVERSE_STORAGE_ORDER (type) = reverse;
+ TYPE_VOLATILE (type) = reverse;
return NULL_TREE;
}
As expected this "fixes" the problem but is probably too big of a hammer here
since it basically voids many of the advantages of the attribute which is
folding away many of the bswaps.
