octave-bug-tracker
[Top][All Lists]
Advanced

[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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]