https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jamborm at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- gcc/tree-dfa.c.jj 2016-01-04 14:55:50.000000000 +0100
+++ gcc/tree-dfa.c 2016-01-20 11:06:15.226682927 +0100
@@ -395,7 +395,7 @@ get_ref_base_and_extent (tree exp, HOST_
if (mode == BLKmode)
size_tree = TYPE_SIZE (TREE_TYPE (exp));
else
- bitsize = int (GET_MODE_PRECISION (mode));
+ bitsize = int (GET_MODE_BITSIZE (mode));
}
if (size_tree != NULL_TREE
&& TREE_CODE (size_tree) == INTEGER_CST)
fixes that and DJ has tested it on msp430 without regressions.
As that is consistent with what e.g. get_inner_reference does, I'd prefer to
apply it this way, but I must say I still don't really understand, even on the
simplified testcase, what is going on during SRA there with the shorter access
sizes.
On the reduced testcase there are 7 calls of get_ref_base_and_extent where mode
here is XFmode (one with different precision from bitsize).
Created a replacement for D.3172 offset: 0, size: 64: SR.24
-Created a replacement for D.3174 offset: 0, size: 64: SR.25
-Created a replacement for D.3592 offset: 0, size: 64: SR.26
-Created a replacement for D.3593 offset: 0, size: 64: SR.27
+Created a replacement for D.3173 offset: 0, size: 128: SR.25
+Created a replacement for D.3174 offset: 0, size: 64: SR.26
+Created a replacement for D.3174 offset: 128, size: 128: SR.27
+Created a replacement for D.3592 offset: 0, size: 64: SR.28
+Created a replacement for D.3593 offset: 0, size: 64: SR.29
is unpatched to patched gcc for the div function. Is SRA assuming the access
sizes are power of two and misbehaving if it gets access size 80 bits?
