Re: mktime.c fixes (part 4 of 6): verify assumptions at compile-time

[Paul Eggert <eggert at CS dot UCLA dot EDU>]

[This is following up to a thread that started on the libc-alpha list;
see <http://sources.redhat.com/ml/libc-alpha/2003-12/msg00246.html>.]

Richard Henderson <rth@twiddle.net> writes:

> On Wed, Dec 31, 2003 at 12:41:30AM -0800, Paul Eggert wrote:
> > +/* The code also assumes that signed integer overflow silently wraps
> > +   around, but this assumption can't be stated without causing a
> > +   diagnostic on some hosts.  */
> 
> Such an assumption requires that you compile with -fwrapv with gcc.
> Otherwise we may infer that a signed value cannot legitimately overflow,
> and may reason based on that.

-fwrapv is new, right?  Then it ought to be the default.

This subject came up with GCC a dozen years ago.  The DEC SRC Modula-3
runtime had code that looked something like this:

  int i, n; ...
  if (0 < i && n + i < n)
    report_integer_overflow ();

GCC 2.2.2 came out with a new optimization (on the SPARC, with -O)
that decided to optimize away the entire `if' statement, on the
grounds that the only way that the 'if' could succeed was for integer
overflow to occur, and the resulting behavior was undefined.

C89 allows this optimization, as does C99 without LIA-1.  But a
reasonable amount of C code will break if you do it, and some of this
code is in glibc and has been in glibc for quite some time.  As well
as in other programs like the Modula-3 implementation.

This is why the optimization was removed from GCC soon after GCC 2.2.2
came out.

Section H.2.2 of the C99 standard gives two choices for C
implementations that wish to conform to ISO/IEC 10967-1 (LIA-1).
They can either define signed integer types as being modulo and not
detect integer overflow (the traditional approach, which gcc -fwrapv
apparently supports), or they can reliably detect integer overflow at
runtime (the gcc -ftrapv approach, I guess).

If you are modifying GCC to do GCC-2.2.2-style optimization again,
please disable the optimization by default.  It's quite OK to have it
as an option, but it shouldn't be enabled by any of the commonly-used
existing optimization options, for the reasons cited above.  The
-fwrapv semantics ought to be the default.