http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
--- Comment #34 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-18 10:03:53 UTC --- (In reply to comment #32) > To be honest, this bug report is not under any discussion anymore. I tried to > get any sort of sanity, but in the end it's all about egos; you won't > get what you want, it's really useless to reopen this particular report. > The libstdc++ maintainers aren't as sensible as the Apple maintainers, the > middle-end maintainers aren't as useful as they should be (hiding behind less > than useful "but that's how it's documented" arguments). And just generally > the > responses to understandable requests are more than lacking in defense of not > implementing it. > > (I think it's hopeless to include even more justifications for your use cases, > it'll just be food for the reverse-trolls) > > He's not a troll. The bug-closers _are_, and the answers to closing are > severely lacking in any sort of justification. And yes, I'm aware of past > discussions. And no, I don't think any of it has much merit for the > discussion > at hand. They are either exaggerating (but, OMG, what to do with the > RTL "<>" -> "!=" transformation???) (answer, "nothing"), and "it's all quite > difficult", or "but currently we do builtin_isnan to 'x!=x', and we can't > recover from that" or they're not capturing the problem at all. Many of the > justifications even just turn back to "but that's how it's documented since > <whenever>", and that's even more sorry than any other sort of > "justification". > Just because a past mistake was documented as such doesn't mean it's right. > > So, reporter, please go away, GCC won't fix your problem, even though it would > be reasonable to change. Instead I'd advise you to some other more reasonable > compiler, LLVM, or maybe a commercial one. GCC is all about defending past > mistakes in order not to change anything, not at all about being helpful to > the user. > > From the proponents of the current state of affairs I would appreciate at > least > a hint of where this was "discussed to death" already, the three PRs from > Andrew certainly are not a case. I'd speculate most of them were argued from > the point of "let's not change anything but rather argue that current > behaviour > is the right one (because that's less work, although I won't say that)". Feel free to provide a patch that splits -ffinite-math-only into two pieces, excempting optimizing the classification builtins from -ffast-math. Please make sure that with that code generation quality is not worse comparing the new -ffast-math to the old -ffast-math -fno-finite-math-only (thus make sure the classification macros are still expanded inline). For that to work you probably have to change RTL optimizers to not do comparison code folding based on flag_finite_math_only (so you can expand isnan to !(x==x) even with -ffinite-math-only). Tree optimizers should have already converted all these codes (so you still need to make sure to not fold the classification builtins to comparisons at the tree level). I would approve a patch along the above lines but I won't spend any time on producing such patch. I will also approve a patch that amends the current documentation of -ffinite-math-only to say that it includes optimizing FP classification macros.
