[EMAIL PROTECTED] (Richard Kenner) writes: > (1) What is the maximum performance loss that can be shown using a real > program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when > one assumes wrapping semantics? > > (2) In the current SPEC, how many programs benefit from undefined overflow > semantics and how much does each benefit?
Those questions are more for the opponents of -fwrapv, so I'll let them answer them. But why are they relevant? Having -fwrapv on by default shouldn't affect your SPEC score, since you can always compile with -fnowrapv if the application doesn't assume wraparound. The SPEC CPU2006 run and reporting rules for peak and base builds <http://www.spec.org/cpu2006/Docs/runrules.html#rule_1.5> are directly on point here: Because the SPEC CPU benchmarks are drawn from the compute intensive portion of real applications, some of them use popular practices that compilers must commonly cater for, even if those practices are nonstandard. In particular, some of the programs (and, therefore, all of base) may have to be compiled with settings that do not exploit all optimization possibilities that would be possible for programs with perfect standards compliance. If the only goal is to get a high SPEC score, it's pretty clear: disable -fwrapv, and if the SPEC program passes its benchmark tests, you're happy. But people who are building reliable software (as opposed to running benchmarks) cannot be so blase about latent bugs due to wrapv assumptions being violated. > (3) How many programs are known to rely on wrap semantics? For each: > (a) How hard was it to determine there was a problem with that assumption? I'm not sure what you're asking for here. For example, GCC assumes wrapv internally. No doubt there is a problem with this assumption if you go out of your way to make it a problem (bootstrap GCC with -ftrapv, for example). Is this "a problem" in the sense that you describe? Or do you mean, "how hard is it to determine whether some real-world compiler, used by a real-world builder of GCC, won't build GCC correctly due to this problem"? If that's the question, then all I can say is that I think it's verrry hard. There are a lot of compilers out there, and they're used in a lot of ways. > (b) How much work was it to modify the program to not > rely on such semantics? Nobody knows the answer to that question either. I could throw out an estimate for GCC (three person-months, say? six?) these are just wild guesses. And that's just one program. Part of the problem is that there's no easy way to determine whether a program relies on these semantics.
