Ian Lance Taylor <[EMAIL PROTECTED]> writes: > I fully appreciate that there is a real problem here which > needs to be addressed, but this does not seem like the > best solution to me.
I agree. It's meant to be a stopgap. I support coming up with a better solution than the stopgap. > The result will be to make gcc look worse than it is. No, the proposed stopgap patch to Autoconf will make actually GCC look _better_. First, the patch will continue to give GCC an advantage over random non-GCC compilers. The default GCC compiler options will be -g -O2 -fwrapv (assuming recent-enough GCC). With typical non-GCC compilers, the default options will be plain -g. That's a big advantage for GCC, albeit not quite as big as -g -O2 would be. Second, if you look at the fine print of the patch, you'll find that it actually _disfavors_ icc, big-time. Currently, the default options for icc are -g -O2, because icc currently mimics gcc well enough to pacify 'configure'. But with the proposed patch, icc will default to -g only. This is because icc does not support -fwrapv, and 'configure' will discover this and disable all optimization with icc (because that's the only way I know to get wrapv semantics with icc). > You will recall that the problem with the original code > was not in the loop optimizers; it was in VRP. I think we > would be better served by changing VRP to not rely on > undefined signed overflow. Or, at least, to not rely on > it without some additional option. A change in behavior, or an additional option in that area, would be a help, yes. Another short-term possibility is for configure to default to '-O2 -fno-tree-vrp' rather than to '-O2 -fwrapv'. I don't know whether that would be a win for typical apps, though. And it would be harder to explain, which is why I chose -fwrapv. The longer-term goal here is to come up with a way for ordinary application programmers to easily find code that has signed overflow problems, and replace it with simple, portable code that can either avoid the overflow, or detect it. Part of the strategy might include "If you use GCC, be careful not to use options such-and-such, because they're not safe". Or it might include calls to gcc-specific builtins. But whatever rules we use, they should be simple and easy to apply. Also, they shouldn't hurt performance much, compared to the current (nonportable) code. Currently we don't have anything even close to what would be necessary here, and it'll be nontrivial to add it. So the shorter-term goal is merely to put up a temporary railing. > Does anybody think that Paul's proposed patch to autoconf would be > better than changing VRP? I don't. I haven't noticed anyone else addressing this question, which I think is a good one.
