bug-gnulib
[Top][All Lists]
Advanced

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

Re: GCC optimizes integer overflow: bug or feature?


From: Paul Eggert
Subject: Re: GCC optimizes integer overflow: bug or feature?
Date: Tue, 19 Dec 2006 01:44:38 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

>> Does the test hang forever?
> No, the timeout works.

So the app builds.  But it has latent bugs.  Wonderful.

Is the performance gain by this change to gcc -O2 really worth all
this software engineering hassle and breakage for typical
applications?  I'm talking about apps like 'date', 'touch', and
'expr'.  Also glibc.  Also Python.  (They're all affected.  Silently.
Ouch.)

I'm not much worried about bugs stemming from loop induction issues; I
think they're unlikely in mainline GNU apps, and at any rate we can
program around them by using unsigned indexes.

What worries me is code like this (taken from GNU expr; the vars are
long long int):

              val = l->u.i * r->u.i;
              if (! (l->u.i == 0 || r->u.i == 0
                     || ((val < 0) == ((l->u.i < 0) ^ (r->u.i < 0))
                         && val / l->u.i == r->u.i)))
                integer_overflow ('*');

This breaks if signed integer overflow has undefined behavior.

There's a lot of overflow-checking code like this in the GNU world.
I'll bet GCC itself has some.  Yes, we know this code doesn't conform
to the C Standard sans LIA-1 because signed integer overflow has
undefined behavior if you don't also conform to LIA-1.  But there is
no standard way to detect overflow.  So we assume wraparound signed
integer arithmetic a la Java and LIA-1.  What else can we do,
realistically?

I'm afraid I don't have time to do a code sweep looking for all
instances of where this change to gcc -O2 silently breaks GNU apps.

So unless someone can come up with a better suggestion, I'm inclined
to suggest that we modify coreutils and similar GNU applications so
that their 'configure' scripts and makefiles use -fwrapv when
compiling with gcc.  As I understand it, -fwrapv is supposed to fix
the problem.  We can also add whatever options non-GNU suppliers want
us to use.

This can be done in Autoconf and/or gnulib, so that the fixes are easy
for GNU apps to pick up by default.  This will work around the
problem, at least for the GNU programs I help maintain.




reply via email to

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