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

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

"Joseph S. Myers" <jsm@polyomino.org.uk> writes:

> Having these optimizations again is hardly new.  For example, GCC 3.0.4 
> optimizes out the multiplication and division in
> 
> int f (int a) { return (2 * a) / 2; }

OK, but GCC 3.3.2 doesn't optimize this closely-related version:

  int f (int a) { int b = 2 * a; return b / 2; }

even though it is semantically equivalent.  This latter example is
more typical of code in programs that attempt to detect signed integer
overflow, since they typically save intermediate results in
temporaries for later checking.  As long as GCC happens to not
optimize such programs we'll be OK; but things are clearly dicey.


> I suspect there have been other instances for longer (and -fwrapv
> may not yet work perfectly,

Perhaps, but other programs (not just glibc) attempt to check for
signed overflow and assume that signed integer arithmetic wraps around
in the usual way.

With the exception of the (now-disabled) GCC 2.2.2 optimization, GCC's
optimizations in this area haven't broken any real programs that I
know of.  Conversely, I don't expect that they have improved
performance all that much in real code, as not too many people write
"(2 * a) / 2", even after macro expansion.

A safer thing to do here would be to make -fwrapv the default.
Less safe would be to add default GCC optimizations in this area,
optimizations that will be more likely to break existing
overflow-checking code (the way GCC 2.2.2 did).

Another possibility would be for GCC to give programmers fine-grained
control over whether signed integer overflow wraps.
This was proposed for C99 as an LIA_WRAP pragma (see
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n752.htm>)
but I don't know of any implementations.

(All this discussion over what is merely a comment in a mktime.c patch
-- no code was changed!  But it's important stuff nonetheless....)