This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
fold-const change
- To: mark at codesourcery dot com
- Subject: fold-const change
- From: Jeffrey A Law <law at upchuck dot cygnus dot com>
- Date: Mon, 31 May 1999 20:17:57 -0600
- Cc: egcs-bugs at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
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