This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization


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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]