Open Quuxplusone opened 14 years ago
Which Boost header is using __builtin_fpclassify?
(In reply to comment #1)
> Which Boost header is using __builtin_fpclassify?
>
The include stack at the point of the error testifies:
In file included from boost-test.cpp:112:
In file included from /usr/include/boost/bimap.hpp:13:
In file included from /usr/include/boost/bimap/bimap.hpp:61:
In file included from /usr/include/boost/bimap/detail/bimap_core.hpp:38:
In file included from /usr/include/boost/bimap/relation/mutant_relation.hpp:26:
In file included from /usr/include/boost/functional/hash/hash.hpp:15:
In file included from /usr/include/boost/functional/detail/hash_float.hpp:25:
In file included from
/usr/include/boost/functional/detail/float_functions.hpp:9:
In file included from /usr/include/boost/config/no_tr1/cmath.hpp:21:
/usr/include/c++/4.4.1/cmath:499:14: error: use of undeclared identifier
'__builtin_fpclassify'
return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL,
So, I guess boost is including cmath.
Cheers,
Maurice
The only interesting thing I see about this is here:
http://archives.free.net.ph/message/20080523.164003.a971bed4.ja.html
Apparently this is used like this:
#define FP_NAN 1
#define FP_INF 2
#define FP_INFINITE 2
#define FP_NORMAL 3
#define FP_SUBNORMAL 4
#define FP_ZERO 5
__builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL, FP_SUBNORMAL, FP_ZERO, (X))
With this patch, we should be able to parse the header:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100118/026684.html
However, we'll still reject the code if something actually tries to codegen the
builtin. Here's the GCC implementation of this feature if anyone is interested:
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01255.html
I've added Sema support for __builtin_fpclassify in r96291. I'll post a codegen patch soon.
Attached builtin_fpclassify_codegen.patch
(5495 bytes, text/plain): first shot at codegen support
Hey Benjamin, it's probably best to email the patch to cfe-commits to get someone to review it, not many people watch bugzilla.
WebKit uses isfinite(), which also requires builtin support.
This isn't actually Boost-related, so it doesn't block Boost.
_Bug 6987 has been marked as a duplicate of this bug._
Just to confirm, this isn't blocking boost.
It is however blocking including
isinf is implemented in r103166
__builtin_isfinite is implemented in r103168
I added some todo's for isinf_sign and isnormal in r103169. I don't plan to
implement these, and they are need fpclassify. Benjamin, your patch looks
basically right, but please use the algorithms and APFloat methods mentioned in
the comment I added. For fpclassify, I recommend actually emitting a branching
structure, like this:
if (x == 0.0) {
res = ZERO;
} else {
xabs = fabs(x);
if (xabs == infinity)
res = INFINITY;
else if (xabs == xabs)
res = NORMAL;
else
res = NAN;
}
Emitting actual branches is good for the branch predictor, codegen can decide
to fold together the blocks if it wants to.
__builtin_isnormal is implemented in r104118.
Attached codegen_builtin_fpclassify.patch
(2902 bytes, text/plain): CodeGen __builtin_fpclassify implementation
(In reply to comment #16)
> I created an implementation of __builtin__fpclassify the way Chris Lattner
> described.
Very nice, commited as r105936.
On linux, linking a trivial program like:
int main(void)
{ return __builtin_fpclassify(1,2,3,4,5,1.0); }
produces the error:
undefined reference to 'fabs'
Which goes away if I add -lm. However, -lm is not required with gcc. This does
not occur on Darwin.
Just a FYI. gcc rejects calls to __builtin_fpclassify if any of the first 5 parameters (the constant list) are non-constant. Of course there is nothing wrong with allowing more values, I just wanted to check this case had been considered, as gcc purposefully rejects it.
Comment 18 is caused by the issue in bug 9019.
builtin_fpclassify_codegen.patch
(5495 bytes, text/plain)codegen_builtin_fpclassify.patch
(2902 bytes, text/plain)