isnan or isntnan?

[Nobody]

The option given by the user was

-ffast-math

and THAT option turns on IMPLICITELY finite-math

Sure. What did you expect it to do?

Or is there some law against making one option a superset of another?

-fast-math enables ... fast math, i.e. certain approximations which are
faster but less accurate. Assuming finiteness is one of them. Assuming
e.g. x/y = x*(1/y) is another.

At least you get the choice (Borland C would make the latter optimisation
regardless of switches). If you randomly enable optimisations without
reading the documentation, you deserve whatever you get.

 

[jacob navia]

Le 19/11/10 19:42, Nobody a écrit :

Which amounts to the same thing. If you don't understand this, you should
choose a different field of endeavour.

The idea of not using gnu stuff doesn'y even cross your mind.

It is a very good alternative really. Just say NO.

If the compiler assumes that values are never NaN, it can optimise isnan()
to constant zero.

The fact that isnan() is called should tell anyone with a small brain
that that assumption is NOT shared by the guy who wrote the program,
that considers that a NAN could really happen there.

But WHO CARES about correct results?

Important is only that results are delivered FAST.


< The usual point of making assumptions is to enable such

optimisations.

I could conceive that making those assumptions about data manipulated by
the compiler could be (maybe) OK. But just "pessimizing" away a call
to a function?

If isnan() actually did something, the compiler *wouldn't* be assuming
that values are never NaN, would it?

Sure. If I would have read the fine print I wouldn't have bought that
dammed appliance. Obviously it was my fault.

Well, I decided never to come to that store again.

Here is the same. Just say NO to GNU.

 

[Nobody]

The fact that isnan() is called should tell anyone with a small brain
that that assumption is NOT shared by the guy who wrote the program,
that considers that a NAN could really happen there.

But WHO CARES about correct results?

Not someone who uses -ffast-math or similar.

Important is only that results are delivered FAST.

If that was true, -fast-math would be enabled by default. It isn't. It
isn't even enabled by any level of -O.

If you ask for speed over correctness, you get it. If you don't want it,
don't ask for it.

< The usual point of making assumptions is to enable such

I could conceive that making those assumptions about data manipulated by
the compiler could be (maybe) OK. But just "pessimizing" away a call
to a function?

You're assuming that it's a call. I would assume that it's either a
macro or a built-in, and it gets optimised away because the code which
implements it is subject to the same assumptions of finiteness as any
other code (when -finite-math-only is used). By the time that it gets
optimised away, the compiler may not even know that the code originated
from isnan().

Even if the compiler left the call in, there's no guarantee that the
argument would actually be NaN when it ordinarily should be.

It's similar to the situation where if you do:
void foo(int *p)
...
int x = *p;
if (p) bar();

the compiler may optimise "if (p) bar();" to simply "bar();". If p happens
to be null, the code has invoked undefined behaviour by dereferencing it,
so the compiler is free to choose to execute bar() as its preferred
form of undefined behaviour.

Sure. If I would have read the fine print I wouldn't have bought that
dammed appliance. Obviously it was my fault.

Well, it does very much look as if you're trying to blame the compiler for
your own shortcomings. Most modern compilers have similar options; I guess
that they're all broken too? IMHO, a compiler which /didn't/ provide such
an option would be defective.

On some architectures, non-finite floating-point can be quite expensive
E.g. the Alpha's FPU doesn't support NaN or infinity; on this
architecture, you have to use -mieee-fp if you want the compiler to insert
software support for infinity and NaN. Note: the C standard doesn't
actually require an implementation to support inifinity or NaN.

Even on architectures which support NaN in hardware, foregoing
optimisations which are valid for all finite values may adversely
affect performance, and often for no good reason. NaN is often just as
much a "wrong answer" as any other value (it typically arises from
numerically unstable calculations).

 

[Nick]

Sure. If I would have read the fine print I wouldn't have bought that
dammed appliance. Obviously it was my fault.

Well, I decided never to come to that store again.

You seem to be arguing that if, instead of buying a device that could
work on a variety of voltages, you instead specifically asked to have
one imported from the US, and then complained that it blew up on
the European mains.

Here is the same. Just say NO to GNU.

I know you write your own compiler. And half the time you talk sense
about it. But the other half you come across a completely bonkers - did
you know that?

 

[Seebs]

The idea of not using gnu stuff doesn'y even cross your mind.

It's not an option for me, and hasn't been for years. Furthermore,
fundamentally, I don't see anything wrong with the GNU stuff in this case;
they offer a documented way to do a particular thing, and it works as
documented.

The fact that isnan() is called should tell anyone with a small brain
that that assumption is NOT shared by the guy who wrote the program,
that considers that a NAN could really happen there.

But WHO CARES about correct results?

Not someone who specifically requests that the compiler generate faster code
which optimizes out some tests.

Important is only that results are delivered FAST.

That is, indeed, what was communicated by the choice of compiler options.

I could conceive that making those assumptions about data manipulated by
the compiler could be (maybe) OK. But just "pessimizing" away a call
to a function?

Uh, yeah. Happens all the time. Do you honestly think that most compilers
generate a function call for strlen("foo")?

-s

 

[Keith Thompson]

Le 19/11/10 19:42, Nobody a écrit :

The idea of not using gnu stuff doesn'y even cross your mind.

In this case, the idea of not using -ffast-math or -ffinite-math-only
accomplishes exactly the same thing.

It is a very good alternative really. Just say NO.


The fact that isnan() is called should tell anyone with a small brain
that that assumption is NOT shared by the guy who wrote the program,
that considers that a NAN could really happen there.

Then the program shouldn't have been compiled with -ffast-math
or -ffinite-math-only.

But WHO CARES about correct results?

Important is only that results are delivered FAST.

gcc offers you an *option* to obtain fast results at the expense
of correctness in some cases. For some code, that might be a good
tradeoff. You don't have to take advantage of that option if you
don't want to. It isn't enabled by default. Would gcc be a better
compiler if the option were removed? Fine, then write a wrapper
that discards any occurrence of -ffast-math or -ffinite-math-only
on the command line. Problem solved.

< The usual point of making assumptions is to enable such

I could conceive that making those assumptions about data manipulated by
the compiler could be (maybe) OK. But just "pessimizing" away a call
to a function?


Sure. If I would have read the fine print I wouldn't have bought that
dammed appliance. Obviously it was my fault.

If you didn't read the fine print, you wouldn't know about those
options, would you?

[...]

 

[jacob navia]

Le 22/11/10 00:22, Seebs a écrit :

Uh, yeah. Happens all the time. Do you honestly think that most compilers
generate a function call for strlen("foo")?

So WHAT?

strlen("foo") can give only ONE result. isnan() surely NOT, unless
you apply bad specs to the limit of nonsense.

Finite math can be assumed. Optimizing away a call to isnan is another
thing.

 

[Noob]

The idea of not using gnu stuff doesn't even cross your mind.
It is a very good alternative really. Just say NO.

Your contempt for GCC is entertaining, in a weird way.

Perhaps you should contribute to LLVM? (Scratch that. It's written in C++)

 

[William Hughes]

Finite math can be assumed. Optimizing away a call to isnan is another
thing.

Why. You told the compiler what the answer to isnan(x) should be.
It used that answer. Remember "if you lie to the compiler it will get
it's revenge". And I can think of a case where depending on where I
got
the data, I might or might not be sure that the program will not
get a nan. If so, I might want to have a version of the program
compiled with -ffinite-math-only which would only be safe to use on
certain
data sets. So compiling code that contains isnan with -ffinite-math-
only
can be quite reasonable.

As a general principle, choosing speed over safety is a bad idea.
However, in some cases it can be justified.

- William Hughes

 

[Seebs]

So WHAT?

So we've established that compilers are allowed to optimize away calls
that they know produce a specific value.

strlen("foo") can give only ONE result.

Actually, it can in fact give more than one, for some reasonably common
cases of undefined behavior. (Consider a string-constant-folding compiler,
and someone concatenating onto the "foo" constant.)

But! Here's the thing: If the compiler is allowed to assume that
there are no NaNs, then isnan(x) can give only ONE result -- 0. Because
x is not a NaN, *by definition*.

Finite math can be assumed. Optimizing away a call to isnan is another
thing.

No. If you are assuming finite math, isnan() must always return 0, and
failure to do so means the assumption was violated.

Another way to look at it: -ffinite-math declares any operation which
can produce an infinity or NaN to be undefined behavior.

-s

 

[Tim Rentsch]

Le 16/11/10 20:04, Nick Bowler a @C3{A9}crit :

Since I didn't see it posted elsewhere in this thread, it should be
noted that GCC's -ffast-math option implies -ffinite-math-only, which
tells the compiler that it may assume all floating point values are
finite. This means that GCC can and will replace all calls to isnan or
isinf with a constant 0.

!!!!!!!!!!!!!!!!!!!!!!!!

This is one of the worst bugs of gcc I have ever seen.
[snip elaboration]

Why does it bother you so much that gcc has an option
supporting a non-conforming extension? Doesn't lccwin
have options that support non-conforming extensions?

 

[Nobody]

Finite math can be assumed. Optimizing away a call to isnan is another
thing.

No. It. Isn't.

For a start, the standard explicitly states that isnan() is a macro. Once
the preprocessor has done its business, the compiler may not even
know that there *was* a call to isnan().

Beyond that, once a compiler starts optimising, there's a good chance that
the expression which was being passed to isnan() doesn't actually exist in
any shape or form.

Have you ever tried debugging optimised code? If you do, you'll find that
lots of variables no longer exist, entire statements no longer exist.
Because the compiler basically treats the original code as a specification
and then generates entirely different code whose only resemblance to the
original is that it produces the same result.

If the compiler was obliged to call the same functions in the same
sequence, there wouldn't be much point in enabling optimisation in the
first place.

 

[Keith Thompson]

Le 16/11/10 22:36, Keith Thompson a écrit :
You are confusing

The option given by the user was

-ffast-math

and THAT option turns on IMPLICITELY finite-math

But obviously, you are right.

When I buy a coffee machine "guaranted 3 months",
I can't fix it in the store because in a very small paragraph
of the thick contract (that was less than gcc's doc about options)
was written in small print that "I have to pay the transport to
the workshop"... that costs more than the machine

Clever isn't it?

Here's a better analogy.

You buy a coffee machine. When used in the normal manner, it makes
good coffee and works in a reasonably intuitive way.

Somewhere in the coffee machine's manual, there's a paragraph that
says that, if you really want to, you can remove three screws on the
base, open up a panel, and flip a switch to change the setting on
the heater. By doing so, you can make your coffee 10% faster, but
you risk starting a fire if you don't have just the required ratio
of coffee beans and water. (If you don't flip the switch, a safety
feature turns off the heater before that can happen, but it can't
act quickly enough at the higher setting.) And the ratio is such
that you can't make really strong coffee with the switch flipped.

Flipping the switch gives you better speed at the expense of reduced
functionality and greater risk of malfunction. It's just the thing
for those coffee brewing speed competitions all the kids are into
these days.

There is no reasonable way you'd even know about the switch if you
didn't read the manual, you couldn't flip it accidentally if you
didn't know about it, and if you did read the manual you'd know about
the risks. You'd also know that the bean/water ratio requirement
means you can't make really strong coffee if the switch is enabled,
and you happen to like your coffee really string. (No cream, no sugar,
just a sprinkling of NaNs.)

What you seem to be doing is buying this coffee maker with the
intention of making really strong coffee, and complaining that
it's defective because it doesn't work the way you want it to if
you flip the switch.

Except that you didn't actually buy the coffee maker (even though
it's free); you're just complaining about it because somebody else
(who had no problem with it) described the switch's behavior.
(I won't assume that this has anything to do with the fact that
you manufacture a competitive coffee maker.)

What exactly was your problem again?

 

[Tom St Denis]

Le 22/11/10 00:22, Seebs a crit :



So WHAT?

strlen("foo") can give only ONE result. isnan() surely NOT, unless
you apply bad specs to the limit of nonsense.

Finite math can be assumed. Optimizing away a call to isnan is another
thing.

Why not just not pass -ffast-math if you don't want this behaviour?

-ffast-math is an OPTIMIZATION not a requisite to compile code.

Tom

 

[Noob]

Why not just not pass -ffast-math if you don't want this behaviour?

-ffast-math is an OPTIMIZATION not a requisite to compile code.

You see, the problem is, if he were to do that, he'd have to give up
a perfectly "good" excuse to diss GCC.