autoconf-patches
[Top][All Lists]
Advanced

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

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


From: Paul Eggert
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Fri, 29 Dec 2006 23:56:47 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

>> Nor would I relish the prospect of keeping wrapv assumptions out of
>> GCC as other developers make further contributions, as the wrapv
>> assumption is so natural and pervasive.
>
> It's neither natural not pervasive to me!  I would never write code
> that way

That's great, but GCC has had many other hands stirring the pot.
I daresay a careful scan would come up with many other examples of
undefined behavior due to signed integer overflow.  (No doubt
you'll be appalled by them as well, but there they are.)

> I think it's good that the issue of wrapping semantics would make
> them more visible because they each represent poor quality code that
> needs to be fixed.

Of course it's OK if GCC developers make a careful manual sweep of
their large code base.  However, I don't think this is a realistic
default strategy for most application developers: the process is
too time-consuming and error-prone.

> People often do "apples to apples" comparisons between compilers
> or else just use the highest -O level.  And they'll come back
> and say that GCC isn't as good as some other compiler because of it.

It's obviously OK to enable these optimizations at the highest
optimization level.  The thing I'm worried about is enabling them
at -O2, which is the default level for Autoconf-generated
'configure' scripts.

> What we need to have is some example of real-world program and a real-world
> compiler that caused the program to malfunction because the program assumed
> wrap semantics and the compiler didn't.  We need to know how long it took
> to debug this and find out what was the cause.

We have one recent example of this.  The problem was reported here:
<http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00084.html>
I don't know how long it took Ralf to debug it, but he's
subscribed to the bug-gnulib list (which this is being CC'ed to)
so perhaps he can fill us in.

I have better figures for the fixing effort, since I did most of
that work.  The bug was fixed 3 days later, here:
<http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00212.html>
The fix is small, but I would not call it trivial; it does not
match the fix Ralf originally proposed, which missed some
problems.  I didn't keep track, but I'd guess my overall effort
took two to four person-hours total, including integration,
testing, etc.

In that particular gnulib module (mktime) I'd guess there are five
more problems like it.  I haven't had the time to look at them or
fix them, though.

Gnulib has about 400 modules.  Most of them are far simpler than
mktime, but I'm sure some of these other modules have wrapv
related problems too.  And Gnulib is just a small part of a large
number of GNU applications.  It would take a loooong time to wade
through all that code looking for all wrapv issues.

If you still want lots more concrete examples, I'm afraid we'll
have to spend more resources, resources that I don't have right
now.  But the initial data do not look promising to me.  I think
it will take a lot of time to find these problems in real-world
programs, and that fixing them will not always be trivial.




reply via email to

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