[Boost-bugs] [Boost C++ Libraries] #6459: long double functions not built on Linux ARM

Subject: [Boost-bugs] [Boost C++ Libraries] #6459: long double functions not built on Linux ARM
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-01-27 15:25:31

#6459: long double functions not built on Linux ARM
------------------------------------------------+---------------------------
 Reporter:  Petr Machata <pmachata@…>           |       Owner:  johnmaddock
     Type:  Bugs                                |      Status:  new        
Milestone:  To Be Determined                    |   Component:  TR1        
  Version:  Boost 1.48.0                        |    Severity:  Problem    
 Keywords:                                      |  
------------------------------------------------+---------------------------
 On Linux on ARM (with GNU libc in any case), the semantics of
 __NO_LONG_DOUBLE_MATH seem to be that there's no distinct bit width for
 variables of long double type.  The prototypes of impacted functions
 (asinhl etc.) are still visible, but they are aliased to their "plain"
 variant.  The syntax for "long double" was present since the first version
 of both C and C++ standards, so the prototypes are just always visible,
 and __NO_LONG_DOUBLE_MATH only determines whether long double has a
 distinct bit width, i.e. whether a distinct set of _implementations_ is
 necessary.

 On boost side, BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS seems to be
 defined on targets where compiler or system libraries are buggy or the
 syntax is missing altogether, but it's apparently also used in the same
 sense as above ("Dinkumware's std C lib doesn't have true long double
 precision").

 I don't think it is right to omit long double functions just because long
 double doesn't provide the extra accuracy.  I understand that you would
 want to skip this on targets where stuff gets miscompiled or similar.  But
 ARM implementation is correct, it just happens to have "double" and "long
 double" of the same length.  The code using long double can be compiled
 and works as expected.  It seems correct to simply ignore the value of
 __NO_LONG_DOUBLE_MATH and build long double functions unless it's known-
 broken.

 It's possible that I don't see some other motivation, but I didn't really
 find much data about this.  FWIW, the test_tr1.cpp passes on ARM.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/6459>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.