https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69355
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #11) > --- 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? No, it has various checks to verify % BITS_PER_UNIT is zero but no unchecked division by it. Even though the above suggests otherwise. It must be a more subtle bug.
