DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0D06F3953C14
Date: Mon, 19 Apr 2021 13:02:57 +0200
To: cygwin@cygwin.com
Subject: Re: hypotl(LDBL_MAX, 0.0L) = inf
Message-ID: <YH1jYRu043FXUMm/@calimero.vinschen.de>
Mail-Followup-To: cygwin@cygwin.com
References: <vriuo8edqaao.fsf@mail.aol.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <vriuo8edqaao.fsf@mail.aol.com>
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces@cygwin.com
Sender: "Cygwin" <cygwin-bounces@cygwin.com>

On Apr 17 10:02, airplanemath via Cygwin wrote:
> Given that hypot(DBL_MAX, 0.0) = DBL_MAX and hypotf(FLT_MAX, 0.0f) =
> FLT_MAX, I suspect this is a problem in hypotl.  Am I missing something?

No.  This is a bug in newlib's hypotl.  Newlib mainly targest embedded
systems and as such wasn't very much interested in long double arithmetic
for a long time.

In contrast to hypot and hypotf, it's not implemented as exact function,
but just as the outside idea sqrtl (x^2 + y^2).  With LDBL_MAX ^ 2 ==
inf as input, sqrtl returns inf.  So what we get here is an intermediate
overflow, that wouldn't occur if the hypotl function would be implemented
in detail.

The problem is, somebody would have to do it.  That is, implementing
a hypotl which works for all supported CPU types.  There are quite a few
long double variations in the wild, unfortunately...

Having said that, there's an easier way out for Cygwin: We just use
the hypotl function from Mingw-w64 for Cygwin as well.

I pushed this patch and uploaded new developer snapshots to
https://cygwin/snapshots/

Please give it a try.


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