[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

From: Richard Kenner
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Fri, 29 Dec 2006 23:17:49 EST

> 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"?


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]