X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>, <libstdc++@gcc.gnu.org>, <newlib AT sources DOT redhat DOT com>
Subject: RE: gcc-3.4.4-1: c++: cmath: calling std::isnan results in endless loop
Date: Mon, 27 Feb 2006 16:21:58 -0000
Message-ID: <01d101c63bb9$ef9ead20$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <1141051217.3656.14.camel@playstation2.hb9jnx.ampr.org>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 27 February 2006 14:40, Thomas Sailer wrote:

> When I try to call std::isnan(double) from a program compiled with g++
> 3.4.4, the program gets into an endless loop.
> 
> The problem is that gcc compiles
> __gnu_cxx::isnan<double>(double) as a tail call to
> __gnu_cxx::__capture_isnan<double>(double), and it compiles
> __gnu_cxx::__capture_isnan<double>(double) to
> __gnu_cxx::isnan<double>(double). It looks to me that this wrapping hack
> (that is also in current glibc) only works if isnan is a macro. But on
> cygwin, this isn't the case.

  My first thought was that this was a libstdc++ bug and should be reported to
them as such, that it was perhaps assuming that it would always be built with
glibc and therefore assuming that it can know that isnan would be a macro.
Cygwin OTOH is a newlib-based platform, and in our case isnan is not a macro.
I believe that libstdc++ is meant to be independent of the underlying C
library, and so it should either not make any assumption that may be invalid,
or should detect (using autoconf tests) whether isnan is a macro or function
on the target and adapt its behaviour to the actual circumstances.

  Ah, this is something that appears to describe the mechanism that has gone
wrong here:
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/porting-howto.html#sec-macros

" Glibc 2.0.x and 2.1.x define the <ctype.h>  -functionality as macros
(isspace, isalpha etc.). Libstdc++-v3 "shadows" these macros as described in
the section about c-headers."

  However, even more interesting is that after browsing the spec, I found
something surprising.  The float-type-classification isXXXXX definitions from
math.h aren't like the isXXXXX character-type-classification functions.  The
language spec says that functions like isprint, isspace, etc. may be
implemented as macros.  But the fp-class symbols like isnan and isinf are
defined by the standard as being macros and NOT functions.

  It looks to me like the cygwin/newlib combination is not being compliant if
it implements isnan as a function rather than a macro.  I couldn't see
anything in the standard that says it can be a function, and every reference
to it describes it as a macro, not a function.  It may be the case that
libstdc++ is within its rights to assume that isnan is a macro after all.

  OTOH it may be that libstdc++ was only supposed to be shadowing those ctype
macros that are guaranteed to have underlying function implementations; I
don't know what the shadowing is for, so I can't comment.

  Hence this x-post to libstdc++ and newlib, where those-who-know can set us
straight.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/