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