[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #55547] libstdc++ assertion failure when built
From: |
Markus Mützel |
Subject: |
[Octave-bug-tracker] [bug #55547] libstdc++ assertion failure when built with -D_GLIBCXX_ASSERTIONS=1 |
Date: |
Sat, 5 Nov 2022 07:03:38 -0400 (EDT) |
Follow-up Comment #8, bug #55547 (project octave):
Came here from bug #63318.
Shouldn't all of these not throw an error nor abort according to the standard
documentation?
I haven't dug into the standard documentation itself. But if I understand its
summary on cppreference correctly, those are valid calls to `std::pow` (and
should return NaN for IEEE floating point numbers):
https://en.cppreference.com/w/cpp/numeric/complex/pow
> Errors and special cases are handled as if the operation is implemented by
std::exp(y*std::log(x))
Neither `std::exp` nor `std::log` should be aborting for any input iiuc.
The summary for `std::polar` says the following:
https://en.cppreference.com/w/cpp/numeric/complex/polar
> The behavior is undefined if r is negative or NaN, or if theta is infinite.
So, it is conform with the standard if *that* function aborts. But we don't
call that function in our code. And the standard doesn't mention that calling
`std::pow` might inherit the behavior of `std::polar` afaict.
Does defining `_GLIBCXX_ASSERTIONS=1` mean that the implementation no longer
follows the C++ standard? Do we want to support those non-conforming
configurations (if an easy work-around is to not define that constant)?
This sound like a bug in libstdc++ to me. (But I could be wrong.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?55547>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [Octave-bug-tracker] [bug #55547] libstdc++ assertion failure when built with -D_GLIBCXX_ASSERTIONS=1,
Markus Mützel <=