This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reporting bugs: there is nothing to gain in frustrating reporters


On 2005-06-16 12:12:26 -0400, Robert Dewar wrote:
> Everyone would agree that per se unnecessary non-determinism is a
> bad thing.

Yes, but not all people would agree on the meaning of "necessary"
(for performance? for security?).

> However, most people would also agree that poor performance
> is a bad thing.

Getting incorrect results is even worse. Anyway a bug isn't invalid
just because fixing it would make the code less efficient.

> All this stuff about allowing extra precision is actually about
> allowing efficient code.
> 
> Lacking in this discussion is a good quantitative measurement
> over a reasonable set of benchmarks as to what eliminating the
> excess precision in all cases would cost.

Why not compile benchmarks with options that allow to keep
extra precision?

Also fixing the bug would not necessarily make code less efficient.
2 solutions:
  * A diagnostic is sufficient.
  * Not declaring that the compiler is conforming to the C standard
    would also be sufficient.

Whether this should be done by default or not could be discussed
later (the behavior could be different depending on FP-related
standard pragmas or options like -std=c99).

> Note that just setting the precision to 64-bits is not enough if
> you agree with Vincent that 32-bit float variables have to be
> normalized on every assignment.

I agree. This would not fix the bug, but make it less visible.
This would thus be an improvement.

> Data would help. Almost everyone will agree with eliminating the
> extra precision if it has only a 3% impact, almost everyone
> will disagree if it doubles execution time (I suspect the asnwer
> is in that range :-)

What about having the choice?

Anyway, if the only reason is the performance, then the bug shouldn't
have been marked as INVALID (the SUSPENDED status is for such kind of
problems -- and SUSPENDED doesn't mean that the bug is resolved).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]