[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: Paolo Bonzini
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Thu, 21 Dec 2006 09:29:43 +0100
User-agent: Thunderbird (Macintosh/20061207)

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)
  if ((time_t) -1 < 0)
    for (time_t_min = -1; (time_t) (time_t_min * 2) < 0; time_t_min *= 2)

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;
      /* 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


reply via email to

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