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]

fold-const change



This change to fold-const.c is causing some headaches:

Wed May 26 09:53:05 1999  Mark Mitchell  <mark@codesourcery.com>

        * fold-const.c (fold): STRIP_NOPS when deciding whether or not
        something is a candidate for optimize_bit_field_compare.


Specifically bf64-1.c fails on mips-sgi-irix6.5 fails with this patch installed.

This is a wee bit of a rats nest, so I'm considering pulling it off the
release branch, but leaving it in the mainline sources (I think the patch
is just exposing a latent problem, thus I don't want to completely get rid
of it!)

We're trying to compare a 52bit field with something like 0xFFFFFF541FFF567FLL.

We get into this code in optimize_bit_field_compare:

  /* Otherwise, we are handling the constant case. See if the constant is too
     big for the field.  Warn and return a tree of for 0 (false) if so.  We do
     this not only for its own sake, but to avoid having to test for this
     error case below.  If we didn't, we might generate wrong code.

     For unsigned fields, the constant shifted right by the field length should
     be all zero.  For signed fields, the high-order bits should agree with
     the sign bit.  */

  [ unsigned case ]

  else
    {
      tree tem = const_binop (RSHIFT_EXPR, convert (signed_type, rhs),
                              size_int (lbitsize - 1), 0);
      if (! integer_zerop (tem) && ! integer_all_onesp (tem))
        {
          warning ("comparison is always %d due to width of bitfield",
                   code == NE_EXPR);
          return convert (compare_type,
                          (code == NE_EXPR
                           ? integer_one_node : integer_zero_node));
        }
    }

TEM will end up with a reasonable looking constant like:

(gdb) p debug_tree(tem)
 <integer_cst 0x82c0ff8 type <integer_type 0x82c3fec long long int> constant public static overflow -1>


However, note that we've set the overflow flag indicating that an overflow
occurred during constant folding (presumably because the constant overflowed
to start with, and thus any operation on it probably overflowed).

Anytime the overflow flag is set, integer_zerop & integer_all_onesp will
return zero, which causes us to emit the (possibly bogus) warning and generate
a comparison that we know is always one.

Other compilers seem to handle this testcase gracefully (ansi compilers on
SGI & HPs for example).  They do not generate a diagnostic and they generate
correct code.


I don't necessarily think your patch is wrong -- it's just exposing a latent
problem.

Thoughts?

jeff







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