Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I'm not entirely happy with what I take to be stampeding it by > introducing what I believe would be a completely inappropriate patch > to autoconf, rather than, say, opening a gcc bugzilla problem report > for the cases you feel gcc should handle differently.
Ralf Wildenhues suggested bugzilla originally, but Andrew Pinski responded <http://gcc.gnu.org/ml/gcc/2006-12/msg00460.html> that the problem "has been observed many, many times and talked about a lot of time on this list" and implied strongly that the issue was settled and was not going to change. And bugzilla entries complaining about the issue (e.g., 18700, 26358, 26566, 27257, 28777) have been closed with resolution INVALID and workaround "use -fwrapv". So it seemed to me like it would have been a waste of everybody's time to open another bugzilla entry; the recommended solution, apparently, was to use -fwrapv. Hence the "Subject:" line of this thread. > Historically we've turned on -fstrict-aliasing at -O2. I think it > would take a very strong argument to handle signed overflow > differently from strict aliasing. I take your point that it might be cleaner to establish a new GCC option rather than overload -O2. That would be OK with me. So, for example, we might add an option to GCC, "-failsafe" say, to disable "unsafe" optimizations that may well cause trouble with traditional/mainstream applications. We can then change Autoconf to default to -O2 -failsafe. However, in thinking about it more, I suspect most application developers would prefer the safer optimizations to be the default, and would prefer enabling the riskier ones only with extra -f options. Thus, perhaps it would be better to add an option "-frisky" to enable these sorts of optimizations. Whichever way it's done, the idea is to give a convenient way to enable/disable the more-controversial optimization strategies that cause problems with many real-world programs that don't conform strictly to the C standard. > You are asserting that most programmers assume -fwrapv, but, except > for your initial example, you are presenting examples which gcc > already does not change. That's true, but so far the only position that the GCC developers have taken that users can rely on, is that all these examples rely on undefined behavior, and that unless you specify -fwrapv GCC is entitled to break them in the future if it doesn't already break them. For many C applications, that is not a tenable situation: right or wrong, there are simply too many places where the code assumes wrapv semantics. In the long run, there has to be a better way. In the short run, all we have now is -fwrapv, so we can use that. > I already took the time to go through all the cases for which gcc > relies on signed overflow being undefined. I also sent a very > preliminary patch providing warnings for those cases. I believe that > we will get the best results along those lines, not by introducing an > autoconf patch. I think in the long run the best results will come from a series of changes, some to GCC, some to Autoconf, some to Gnulib, and some no doubt elsewhere. I welcome adding warnings to GCC so that programmers are made aware of the problems. If the warnings are reliable and do not have too many false alarms, they will go a long way towards fixing the problem. However, I doubt whether they will solve the problem all by themselves. I have not installed the Autoconf patch (much less published a new version of Autoconf with the patch) because I too would prefer a better solution. But the bottom line is that many, many C applications need a solution that errs on the side of reliability, not one that errs on the side of speed. As far as I can tell the Autoconf patch is so far the only proposal on the table with this essential property.