[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