[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Jan 20 12:52:00 GMT 2016
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.
More information about the Gcc-bugs
mailing list