> 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.
(1) If -fwrapv isn't the default, it won't be as well tested as it will if it were the default. (2) People don't always read every detail of the manual to find out the set of options to use. 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. > 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"? Right. > 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. Unfortunately, what you, I, or somebody else might think isn't DATA! 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. > > (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. Again, data is needed, not guesses. If I had to guess, I'd say there were AT MOST a handful of places in GCC that needed changing and the total time to fix them would be measured in MINUTES, not months. But real data would be nice here. (Note that here I mean the time to FIX the program: the previous question was the amount of time to LOCATE the error.)
