On the plus side, I'm glad to see the conclusions of the last couple of posts.
From Mehdi:
Hope this clarify where I see the direction going, and even if you don’t agree with my
reasoning, the conclusion should be satisfactory on your side 
I'd say that summarizes my thoughts on this well.
And from Nicolai:
Right. I'm not fundamentally opposed to having these flags, ...
I do agree with much of what you both say, but definitely not all of it. The philosophy of not providing what a customer requests and instead guiding them to a better alternative is something I agree with -- we don't just give them a pony. And I agree *strongly* that just because a program gets the answer a user wants with GCC (using fast-math) and we get an answer they view as "wrong", doesn't mean it's a bug of ours and that we need to change to get the same answer as GCC. That's not what our goal of GCC compatibility means to me.
But we do have a switch '-fno-reciprocal-math' that we accept, and even process/implement to some extent. But that implementation has a bug. Fixing that bug so that when a user says '-ffast-math -fno-reciprocal-math', we enable the fast-math transformations but explicitly disable the reciprocal transformations is, in my view, the right thing to do. Simply, that is a bug that we ought to fix -- unless we agree to abandon support of '-fno-reciprocal-math', which I think isn't under consideration at this stage. And FTR, I'd oppose that, not surprisingly.
I'm not at all trying to justify the "pony" use-case from this customer, but if we provide '-fno-reciprocal-math', I think we ought to fix bugs we find in our implementation of it. Fixing that bug doesn't guarantee we'll then get the same answers as GCC does on every program when compiled with '-ffast-math -fno-reciprocal-math', but IMO that isn't required for us to describe our behavior as "GCC compatibility" in this respect.
Fast-math is "unusual", in that the user is explicitly opening the door to allowing us to do non-compliant transformations. As compared with GCC, our implementation can have a subset or a superset of these non-compliant transformations, and we can still call that "GCC compatibility". As an analogous "not unusual" feature, both we and GCC do type based alias analysis. It's a perfectly standard-compliant thing to do optimizations based on conclusions from the tbaa. We both support the switch '-f[no-]strict-aliasing' to control this (and we both enable it by default). Referring to this as "GCC compatibility" is perfectly legitimate, in my view. But if a user program has an aliasing bug in it, and our tbaa directs us to aggressively optimize it, whereas GCC's doesn't (and so the user gets the answer they wanted with GCC, but not with us), this does not mean we have a bug, or that saying we're GCC compatible in terms of '-f[no-]strict-aliasing' is a "lie". We can do a superset or subset of the optimizations that GCC does in terms of alias analysis, and we can quite reasonably describe us a GCC compatible in terms of us providing this capability. A user insisting we have a bug in this tbaa situation is analogous to your "pony" request about "float test_div(float a, float b) { return a/b; }". And (unrelated to Clang/LLVM) I've had this sort of objection from users in tbaa situations in the past, where I've had to defend my point that just because GCC didn't optimize it as aggressively as the compiler I was providing, it wasn't a bug in our compiler. So I'm all for not giving everyone a pony.
But irrespective of how silly a test-case it may be to do:
{
float x = a / c;
float y = b / c;
if (y == 1.0f) {
// do some processing for when 'b' and 'c' are equal
} else {
// do other processing
}
use(x, y);
}
I cannot in good conscience tell the customer that it's OK for us to do:
float tmp = 1.0f / c;
float x = a * tmp;
float y = b * tmp;
when they specified '-ffast-math -fno-reciprocal-math'. They can rightfully come back and say "what do you mean by '-fno-reciprocal-math'?" I have to call that a compiler-bug.
Thanks!
-Warren