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 middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
tree built by

0x00000000009f4f2a in associate_trees (loc=0, t1=0x7ffff69ea230, 
    t2=0x7ffff69e9378, code=MULT_EXPR, type=0x7ffff68d09d8)
    at /space/rguenther/src/svn/trunk/gcc/fold-const.c:919
919           return build2_loc (loc, code, type, fold_convert_loc (loc, type,
t1),
920                              fold_convert_loc (loc, type, t2));

#1  0x0000000000a1870e in fold_binary_loc (loc=0, code=MULT_EXPR, 
    type=0x7ffff68d09d8, op0=0x7ffff69ea208, op1=0x7ffff69fe0e0)
    at /space/rguenther/src/svn/trunk/gcc/fold-const.c:9565
#2  0x0000000000a2653c in fold_build2_stat_loc (loc=0, code=MULT_EXPR, 
    type=0x7ffff68d09d8, op0=0x7ffff69ea208, op1=0x7ffff69fe0e0)
    at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12422
#3  0x0000000000a09f78 in extract_muldiv_1 (t=0x7ffff69ea1b8, 
    c=0x7ffff68e9318, code=MULT_EXPR, wide_type=0x7ffff68d09d8, 
    strict_overflow_p=0x7fffffffc747)
    at /space/rguenther/src/svn/trunk/gcc/fold-const.c:6153
#4  0x0000000000a088d9 in extract_muldiv (t=0x7ffff69ea1b8, c=0x7ffff68e9318, 
    code=MULT_EXPR, wide_type=0x7ffff68d09d8, strict_overflow_p=0x7fffffffc747)
    at /space/rguenther/src/svn/trunk/gcc/fold-const.c:5877

so extract_muldiv goes berzerk somewhere (ugh, how I hate this beast...)

Hmm, no, it looks wide-int related:

      /* If these are the same operation types, we can associate them
         assuming no overflow.  */
      if (tcode == code)
        {
          bool overflow_p = false;
          bool overflow_mul_p;
          signop sign = TYPE_SIGN (ctype);
          wide_int mul = wi::mul (op1, c, sign, &overflow_mul_p);
          overflow_p = TREE_OVERFLOW (c) | TREE_OVERFLOW (op1);
          if (overflow_mul_p
              && ((sign == UNSIGNED && tcode != MULT_EXPR) || sign == SIGNED))
            overflow_p = true;
          if (!overflow_p)
            return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
                                wide_int_to_tree (ctype, mul));

so we have op1 == -2, c == 2, both 'int' but ctype is unsinged long.  What
wide_int_to_tree does now is _not_ sign-extend mul properly!?

Richard?


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