>> 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.