Re: [boost] [Numeric/Interval] Mingw-3.4.1 failures

From: Jonathan Wakely (cow_at_[hidden])
Date: 2004-09-22 05:19:00

On Wed, Sep 22, 2004 at 11:27:09AM +0200, Guillaume Melquiond wrote:

> Le mar 21/09/2004 ? 22:59, Bronek Kozicki a ?crit :
> > Aaron W. LaFramboise wrote:
> > > Actually, the newest is 3.5, 
> > 
> > indeed, however it's not listed at http://www.mingw.org/download.shtml
> > 
> > I wonder if should I switch regression tests of mingw 3.3.1 and mingw 
> > 3.4.1 release candidate to runtime 3.5? And possibly w32api 3.1?
> > 
> > > -The compiler: GCC or something else
> > > -The linker and assembler: binutils or something else
> > > -The C library: glibc, mingw-runtime, or something else.
> > > The functionality of the whole is described by the functionality of each
> > > of these three parts.
> > 
> > right. Version of GCC is being used in numeric/interval/detail/bugs.hpp 
> > to discover capabilities of runtime, thus problem.
> 
> Not to discover capabilities, it is to discover namespaces. At the time
> of GCC 3.4, the developers decided that the inverse hyperbolic functions
> should not be in the std namespace anymore (they were before). It is the
> reason why the GCC version is tested.
> 
> You still haven't say how I can detect that it's the mingw runtime that
> will be used. I need to know a preprocessor test so that i can adapt the
> interval library to this runtime.

http://lists.boost.org/MailArchives/boost/msg71816.php

However, another test in boost/numeric/interval/detail/bugs.hpp seems
wrong to me:

#  if defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ > 3)
#    define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using ::a
#  elif defined(BOOST_HAS_INV_HYPERBOLIC)
#    define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using std::a
#  endif

This implies that GCC 3.3 (and earlier) puts the inverse hyperbolic
functions in namespace std. According to a simple test (*) I've just run,
none of GCC 3.0.4 on linux, 3.3.3 on FreeBSD or 3.4.3 on FreeBSD declares
acosh in namespace std.

Only GCC 2.x seems to declare those functions in namespace std, but
that's probably because namespace std == global namespace in GCC 2.x
(all std:: qualifiers are effectively ignored)

Should the first line of the test above be changed as follows?

#  if defined(__GNUC__) && (__GNUC__ == 3)

I believe the regression tests pass because the top of the file says:

#if defined(__GLIBC__) && !defined(__GLIBCPP__) && (defined(__USE_MISC) || defined(__USE_XOPEN_EXTENDED) || defined(__USE_ISOC99)) && !defined(__ICC)
#  define BOOST_HAS_INV_HYPERBOLIC
#endif

This is not true if using GCC 3.3's libstdc++ (which defines __GLIBCPP__),
so BOOST_HAS_INV_HYPERBOLIC is not defined. This means neither condition
here is met:

#  if defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ > 3)
#    define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using ::a
#  elif defined(BOOST_HAS_INV_HYPERBOLIC)
#    define BOOST_NUMERIC_INTERVAL_using_ahyp(a) using std::a
#  endif

And so this runs instead:

#ifndef BOOST_NUMERIC_INTERVAL_using_ahyp
#  define BOOST_NUMERIC_INTERVAL_using_ahyp(a)
#endif

This means that no using decl is given for the inverse hyperbolics, 
but they are in the global namespace and so are found anyway.

i.e. if I understand correctly there is a lot of jumping through hoops
for GCC that is completely inneffective and doesn't help, at least for
GCC 3.3 on linux/freebsd. After all the messing about Boost ends up just
assuming the functions are in the global namespace, and that works.

For GCC 3.4 the first test at the top of the file fails (because
libstdc++ defines __GLIBCXX__ not __GLIBCPP__) so
BOOST_HAS_INV_HYPERBOLIC is defined (this should be fixed by adding
__GLIBCXX__ to the first test, I believe). However, the next test is
true because __GNUC_MINOR__ > 3, so the global namespace is used.

Why is BOOST_HAS_INV_HYPERBOLIC defined if you're using Glibc but not
libstdc++?  libstdc++ doesn't make the functions unavailable, it just
doesn't put them in namespace std.

Why does one test look at the stdlib macro, but the next one looks at
the compiler version? I assume the stdlib check is to account for GCC
with STLPort, but then the next test ignores that possiblity and only
looks at the compiler version. I won't pretend to understand exactly
what that file is trying to do. Comments might help.

jon

(*) test was

    #include <cmath>
    int main()
    {
        using std::acosh;
    }

-- 
"You can have my encryption algorithm, I thought to myself,
 when you pry my cold dead fingers from its private key."
	- Decrypting the Puzzle Palace, John Perry Barlow