[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

From: Ian Lance Taylor
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: 30 Dec 2006 23:53:45 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Gabriel Dos Reis <address@hidden> writes:

> for this specific function (vrp_int_const_binop), I'm issuing a
> warning inside the else-if  branch that tests for the overflowed
> result.  I'm unclear why that is a false positive since the result is
> known to overflow.  Could you elaborate? 

Within VRP, calculations are made on ranges.  The upper and lower
limits of those ranges need not actually appear in the program.  If
you warn whenever vrp_int_const_binop produces an overflow, you will
get an enormous number of false positives.

I have a patch which issues warnings whenever gcc assumes that signed
overflow is undefined, except in loop IV calculations.  I'm tweaking
it to see whether it is possible to bootstrap gcc with this patch.  It
currently builds libcpp with no warnings, but falls over on this code
in decDivideOp in decNumber.c in libdecnumber:

                  /* count the trailing zeros */
                  Int drop = 0;
                  for (;; drop++)
                    {           /* [will terminate because lsu!=0] */
                      if (exponent >= maxexponent)
                        break;  /* don't chop real 0s */
#if DECDPUN<=4
                      if ((lsu - QUOT10 (lsu, drop + 1)
                           * powers[drop + 1]) != 0)
                        break;  /* found non-0 digit */
                      if (lsu % powers[drop + 1] != 0)
                        break;  /* found non-0 digit */
                  if (drop > 0)
                      accunits = decShiftToLeast (accnext, accunits, drop);
                      accdigits = decGetDigits (accnext, accunits);
                      accunits = D2U (accdigits);
                      /* [exponent was adjusted in the loop] */

The problem is that VRP computes that "drop" may overflow.  VRP also
wants to eliminate the "drop > 0" test in the case where the loop was
executed at least once.  As far as VRP can tell, eliminating that test
is a case where it is making an assumption about the behaviour of
signed overflow: basically, it is assuming that "drop" does not
overflow, although it can not prove otherwise.  So with my patch, it
issues a warning.

I'm not sure what, if anything, can be done about this (other than
simply disabling this VRP optimization in that case).  Suggestions

I've attached the patch for reference.  You will note that the warning
messages are obscure.  They are also not tied to any particular source
location.  This patch is thus completely useless for end users.  I'm
just testing the possibilities.

You will also note that I had to rework VRP to explicitly keep track
of overflow values, and to do arithmetic on them differently.  This
was an essential step to avoid scads of false positives.


Attachment: foo5.patch
Description: undefined overflow warning patch

reply via email to

[Prev in Thread] Current Thread [Next in Thread]