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

[Paolo Bonzini]

> Surely you meant to write "when -fwrapv is _not_ given"?

Yes, sorry.

> Now -fwrapv in its current form is overkill, since it
> disables many useful optimizations that won't break anything
> (notably loop induction in the common case).  Perhaps we can
> think of a stripped-down version that enables the most
> useful optimizations without breaking C applications' tests
> for overflow.  We could then enable that stripped-down
> version by default, instead of -fwrapv.

Except that the problem in gnulib is indeed due to a loop, and would not 
be caught by the stripped down version that only ignored wrapping in the 
case of induction variables.  The case was:

  for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2)
    continue;
  time_t_max--;
  if ((time_t) -1 < 0)
    for (time_t_min = -1; (time_t) (time_t_min * 2) < 0; time_t_min *= 2)
      continue;

Which can easily (and more efficiently, and more readably) be written as 
(assuming you don't know the type of j):

  if (~((time_t) 0) > 0)
    {
      /* time_t is unsigned.  */
      time_t_max = ~(time_t) 0;
      time_t_min = 0;
    }
  else
    {
      /* time_t is signed.  */
      time_t_min = ((time_t)1) << (sizeof (time_t) * CHAR_BIT - 1);
      time_t_max = ~time_t_min;
    }

> gcc -O2 also could enable -ffast-math too.  That would
> conform to the minimal C99 standard, and it would generate
> faster code in some cases.  So why not do that as well?

Actually, a subset of the optimization performed by -ffast-math would 
make almost all programs more accurate (let's say, programs written by 
people who don't understand floating-point accuracy issues completely -- 
including me).  Maybe less precise, but more accurate.

> We can't expect every maintainer to agree on these issues,
> as their situations differ, so it's reasonable to provide an
> Autoconf option, and I'll do that in a future version of the
> patch.  However, prudence suggests that, if a maintainer
> expresses no preference, the Autoconf default should prefer
> safety to speed when we get into tricky areas like this.

I disagree.  One such bug (and one in loops, in particular) went 
unnoticed for 11 years: see the loop.c hunk in

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02126.html

Paolo