http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
--- Comment #31 from Ethan Tira-Thompson <ejtttje at gmail dot com> 2011-10-18
00:33:41 UTC ---
I don't see what the hurry is to close the bug while it's still under
discussion. I guess you guys just like hit that 'resolved' button before
you've actually committed any resolution. OK, when in Rome...
> Maybe you should consider that the maintainers have actually thought about
> it and might know what they're talking about? What is __isnan? Is that
> reliably available on all supported platforms? (Hint: no) Is __builtin_isnan
> reliably available? (Hint: yes)
This was exactly the information I was asking for. I explicitly asked if it
was a portability issue (vs. performance or licensing, thought perhaps maybe it
was some GPL thing). Maybe it sounded patronizing because it was such a
obvious question to you, but please have a little patience with people who are
new to the project internals. Heck, how many people do you think even know
that __isnan is from libm and __builtin_isnan is from gcc, or the relationship
between the two? This stuff is not well documented nor common knowledge, and
if maintainers don't want to answer questions then what do you expect?
A fair bit of this thread has been wasted on a subset of maintainers saying
'gcc hasn't changed, finite-math has always been this way', directly in
response to me showing code demonstrating the change and eventually tracking
down the patch that caused it in spite of the derogatory comments, like even
yours just now. So similarly you might consider a user who has spent a fair
bit of time finding the problem and presenting it to you on a silver platter,
is probably not hallucinating the whole thing. (Hint: no) Fair enough?
This is probably moot, but if you'd like to get this back on topic, I'm still
on board.
So then, just for reference, does no part of gcc rely on libm now? Or is there
a config mechanism that lets parts of gcc use libm when it is available? I ask
because gcc (well, libstdc++) used to use libm, so that begs the question what
is the current status?
> If you want your code to conform to floating point standards THEN DON'T
> USE -ffinite-math-only! It's there in the manual for all to see.
My concern is not 'conformance' per se. Obviously then I just wouldn't be
using the flag.
1) Inconsistency between math.h and cmath (unpredictable optimization
application, maybe I use math.h, but someone includes cmath before my header,
perhaps a precompiled header across translation units, now my code behaves
differently, and this might vary per-translation unit within the program.)
2) Inconsistency with older versions/forks of gcc (breaking legacy
code/portability, maybe even security issues?)
3) Insufficient documentation regarding the expected degree of non-compliance
("arithmetic" includes classification?)
4) What is really the *desired* degree of non-compliance in practical usage, is
this throwing out the baby with the bathwater? (For most of the finite-math
effects, garbage-in-garbage-out is fair enough; but the classification
functions often lead to code paths with side effects, e.g. triggering UI,
skipping data records, etc, so it's a much broader effect.)
So yes, I could just not use the flag. But it's useful, it's just gotten too
aggressive. As a user, it's hard to reproduce isnan (and friends) to do
validation when finite-math is active (and since build systems make it easy for
end users to recompile with additional flags, it's not entirely controllable
either, other than saying "don't do that", I'd rather it wasn't
all-or-nothing.) Since gcc used to provide this more limited finite-math
optimization, I was hoping it would not be hard to restore it. I also used to
think there would be a concern regarding how the user-visible scope of
finite-math had changed, breaking code. *shrug*
> That would be something for user code to do, not the library.
> Feel free to do it in your code.
I can't add an attribute to the system isnan from my user code, or can I? I've
never been quite sure what Paolo was referring to, can someone clue me in? It
sounded like he was saying the builtins could be given an attribute to specify
-fno-finite-math-only which would only affect their specific usage? Maybe he
just meant I could apply different flags in different translation units of my
own code, in which case I've misunderstood. Basically, what's the "new
optimization attribute and pragma"?
Thanks!
