I'm not sure whether this is the proper method for reporting errors in the documentation. However, I believe there is a serious error in the GCC documentation that needs to be addressed. The error is at http://gcc.gnu.org/bugs.html#nonbugs_general. This section refers to inherent limitations of floating-point types because most numbers can be represented only approximately. The problem is that this "non-bug", which is connected to problem report #323 and has a hyperlink to it, encompasses many other problem reports that are not accurately described by this documentation section. Some are due to the inherent limitations, but others are actual bugs in which the compiler is generating incorrect instructions (such as #12331); others are due to a particular floating-point processor feature that can be defeated with a flag (but it could be considered a bug that the compiler is not able to take proper advantage of this feature); still others could marginally be considered "bugs" because a compiler could, in theory, generate correct code although expecting it to do so may not be reasonable. For honesty's sake, since so many problem reports end up with users being referred to this section, the documentation should accurately describe the situation (including the fact that there are known bugs which may be difficult to fix), rather than giving the false implication that all such problems are the user's fault for doing something ignorant. I believe this to be a serious inaccuracy in the documentation, and one that I think has been leaving users in an unhelpful state of confusion.
> but others are actual bugs in which the compiler is generating incorrect instructions (such as #12331); That is not incorrect instructions. Just different than what you are expecting. All can be defected by the compiler option to turn the fp precision differently. *** This bug has been marked as a duplicate of 323 ***
(In reply to comment #1) > > but others are > actual bugs in which the compiler is generating incorrect instructions > (such as #12331); > > That is not incorrect instructions. Just different than what you are > expecting. I suppose that if the chip has an instruction that would allow it to store the correct value without losing any precision, and the compiler instead chooses to generate an instruction that causes the computation to lose precision, that could be considered "different than what I am expecting", yes. Actually, I like that response. I might try to use it myself next time one of our customers reports a problem.
@Adam, If you think that something is wrong in the documentation, please point out exactly which text should be removed and what should be added. Also, feel free to submit a documentation patch: http://gcc.gnu.org/contribute.html#docchanges A patch would certainly help to clarify why you think the current doc is wrong and what you think should be the correct wording. As for GCC issues with fp precision, it is an ongoing debate. It is not crystal clear which optimizations (if any) GCC should avoid for the sake of precision. The main sources of info right now are: http://gcc.gnu.org/wiki/FP_BOF http://gcc.gnu.org/wiki/Math_Optimization_Flags http://gcc.gnu.org/wiki/GeertBosch If after reading those, you think that you can contribute something new or you still think that some issue should be revisited, then submit an email to the gcc@gcc.gnu.org list. Please, focus on a particular issue, with examples and reasoning. As always, patches and testcases would further help your cause. Thanks.
(In reply to comment #2) > > Actually, I like that response. I might try to use it myself next time one of > our customers reports a problem. I guess that your contracted GCC support developers may give you a reply that you like even more, so better go ask them. (That wouldn't be a nice reply, would it? So please understand that your jest isn't nice to us either. We are happy to receive and fix bug reports, but politeness certainly helps when asking for something.)