This is the mail archive of the gcc@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]

Re: suspect code in fold-const.c


On 11/15/2013 04:07 AM, Eric Botcazou wrote:
this code from fold-const.c starts on line 13811.

          else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi
               && TREE_INT_CST_LOW (arg1) == signed_max_lo
               && TYPE_UNSIGNED (arg1_type)
               /* We will flip the signedness of the comparison operator
              associated with the mode of arg1, so the sign bit is
              specified by this mode.  Check that arg1 is the signed
              max associated with this sign bit.  */
               && width == GET_MODE_BITSIZE (TYPE_MODE (arg1_type))
               /* signed_type does not work on pointer types.  */
               && INTEGRAL_TYPE_P (arg1_type))
with width defined as:

	unsigned int width = TYPE_PRECISION (arg1_type);

it seems that the check on bitsize should really be a check on the
precision of the variable.   If this seems right, i will correct this on
the trunk and make the appropriate changes to the wide-int branch.
Do you mean

   && width == GET_MODE_PRECISION (TYPE_MODE (arg1_type))

instead?  If so, that would probably make sense, but there are a few other
places with the same TYPE_PRECISION/GET_MODE_BITSIZE check, in particular the
very similar transformation done in fold_single_bit_test_into_sign_test.

yes. I understand the need to do this check on the mode rather than the precision of the type itself. The point is that if the mode under this type happens to be a partial int mode, then that sign bit may not even be where the bitsize points to.

However, having just done a few greps, it looks like this case was just the one that i found while doing the wide-int work, there may be several more of these cases. Just in fold-const, there are a couple in fold_binary_loc. The one in tree.c:int_fits_type_p looks particularly wrong.

I think that there are also several in tree-vect-patterns.c.

Kenny


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