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/81931] [8 regression] r251260 breaks many tests on powerpc64


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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
The problem here is that get_nonzero_bits() is being called with an SSA whose
precision is 0 (_Complex float).  This is causing this code in
get_nonzero_bits():

  range_info_def *ri = SSA_NAME_RANGE_INFO (name);
  if (!ri)
    return wi::shwi (-1, precision);

...to return a wide int of:

(gdb) p nonzero_bits.dump()
[0], precision = 0

whereas previous to the aforementioned patch, we were returning:

(gdb) p nonzero_bits.dump()
[0xffffffffffffffff], precision = 0

This discrepancy is causing the CCP code to think a value is a known constant,
instead of a VARYING:

  if (flag_tree_bit_ccp
      && ((is_constant && TREE_CODE (val.value) == INTEGER_CST)
          || !is_constant)
      && gimple_get_lhs (stmt)
      && TREE_CODE (gimple_get_lhs (stmt)) == SSA_NAME)
    {
      tree lhs = gimple_get_lhs (stmt);
      wide_int nonzero_bits = get_nonzero_bits (lhs);
      if (nonzero_bits != -1)
        {
          if (!is_constant)
...

nonzero_bits is no longer equal to -1, so we think we have a known value.

IMO, a precision of 0 makes no sense.  Perhaps we should even hard fail in
get_nonzero_bits for this case, and have all callers fix their nonsense.

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