bugGNU Octave - Bugs: bug #55538, logspace BIST tests fail when...


bug #55538: logspace BIST tests fail when Octave built with LLVM libc++

Submitted by:  Dmitri A. Sergatskov <dasergatskov>
Submitted on:  Mon 21 Jan 2019 04:11:40 PM UTC  
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sat 08 May 2021 02:02:06 PM UTC, comment #6: 

No feedback to the patch in comment #3 in a week. So people don't seem to care much one way or the other.
Thus, I pushed the patch here:

This is just to mark this as a known issue in the test suite. It doesn't make any change to what logspace returns.

Markus Mützel <mmuetzel>
Project Member
Sun 02 May 2021 08:20:23 AM UTC, comment #5: 

Re comment #4: That might be worth adding support for.
Maybe also as a replacement of the math library on Windows in MXE Octave?
But looking at that code snippet in their Makefile, I'm wondering if that target is even supported:

ARCH ?= $(shell $(CC) -dumpmachine | sed "s/\([^-]*\).*$$/\1/")

ifeq ($(ARCH),mingw32)
$(error "the mingw32 compiler you are using fails the openblas testsuite. please see the Julia README.windows.md document for a replacement")

I can't find the README.windows.md document. So, it's not clear to me what that means.
Do you have any hints on that?

Markus Mützel <mmuetzel>
Project Member
Sat 01 May 2021 01:42:07 PM UTC, comment #4: 

It may be worth noting that
to make similar tests work
predictably across different
sistems Julia developers
started the project below:


I don't necessarily mean we should
switch to openlibm, just that it is
very hard to make sure tests like this one
are portable ...

Sat 01 May 2021 01:27:43 PM UTC, comment #3: 

The attached patch duplicates the affected tests and marks them as a known error on macOS.
Is this the coding pattern that we would like to use for tests that are known to fail on some platforms?

Some caveats with this patch:

IIUC, it isn't clear if libstdc++ or libc++ returns the expected values here.
FWIW, the results with Matlab R2021a on Windows:

>> logspace (Inf + 1i, Inf + 1i, 3)

ans =

     -Inf +    Infi     -Inf +    Infi     -Inf +    Infi

>> logspace (-Inf + 1i, Inf + 1i, 3)

ans =

   0.0000 + 0.0000i      NaN +    NaNi     -Inf +    Infi

For all I know, their results could be different on macOS as well.

The real condition should be whether Octave was linked with libc++. Since this is the default on macOS, and most other platforms are probably linking with libstdc++, conditioning the tests on `ismac ()` will probably cover most cases correctly.

(file #51349)

Markus Mützel <mmuetzel>
Project Member
Mon 21 Jan 2019 10:25:38 PM UTC, comment #2: 

Here is a revised test program:

#include <complex>
#include <limits>
#include <iostream>

main (int argc, char *argv[])
  double x = 10.0;
  std::complex<double> y {std::numeric_limits<double>::infinity (), 1.0};

  std::complex<double> z1 = std::pow (x, y);
  std::complex<double> z2 = std::pow (std::complex<double> (x), y);
  std::complex<double> z3 = std::exp (y * std::log (x));
  std::complex<double> z4 = std::exp (y * std::log (std::complex<double> (x)));

  std::cout << z1 << ", "
            << z2 << ", "
            << z3 << ", "
            << z4 << std::endl;

And the output:

$ g++ -o x x.cc && ./x
(-inf,inf), (inf,-nan), (-inf,inf), (inf,-nan)
$ clang++ -stdlib=libstdc++ -o x x.cc && ./x
(-inf,inf), (inf,-nan), (-inf,inf), (inf,-nan)
$ clang++ -stdlib=libc++ -o x x.cc && ./x
(inf,-nan), (inf,-nan), (-inf,inf), (inf,-nan)

The difference seems to be that LLVM promotes a non-complex argument to its complex equivalent and uses 'exp(y*log(x))' on those two values. GCC computes the result as a special case for a non-complex base and a complex exponent. Both runtimes agree on the underlying return values, they just disagree about whether 'pow(double, complex<double>)' should be computed as a special case or not.

So basically the same as this difference in Octave when built with GCC:

>> power (10, complex (inf, 1))
ans = -Inf + Infi
>> power (complex (10, 0), complex (inf, 1))
ans =  Inf - NaNi

If built with LLVM these will return the same thing.

I can't tell from cppreference whether this is an ambiguity in the spec or whether either one is definitively correct.

Mike Miller <mtmiller>
Project Administrator
Mon 21 Jan 2019 05:50:04 PM UTC, comment #1: 

I can confirm that this bug is entirely within the LLVM libc++ standard library.

The following C++ program reflects a relevant piece of what Octave is doing in the failing test:

#include <complex>
#include <limits>
#include <iostream>

main (int argc, char *argv[])
  std::complex<double> x {std::numeric_limits<double>::infinity (), 1.0};
  std::complex<double> y = std::pow (10.0, x);
  std::cout << y << std::endl;

This program prints '(-inf,inf)' as expected, except when compiled with the LLVM C++ library:

mike@galago:~/src$ g++ -o x x.cc && ./x
mike@galago:~/src$ clang++ -stdlib=libstdc++ -o x x.cc && ./x
mike@galago:~/src$ clang++ -stdlib=libc++ -o x x.cc && ./x

Does anyone know if this result is dictated by the C++ standard? If so, is there already an open LLVM bug report that we can link to?

Mike Miller <mtmiller>
Project Administrator
Mon 21 Jan 2019 04:11:40 PM UTC, original submission:  

When octave compiled with clang and llvm's libc++ library
(which is usually the case on macOS), the test general/logspace.m

octave:1> test  general/logspace.m
***** assert (logspace (Inf + 1i, Inf + 1i, 3), repmat (complex (-Inf,Inf), [1, 3]))
!!!!! test failed
ASSERT errors for:  assert (logspace (Inf + 1i, Inf + 1i, 3),repmat (complex (-Inf, Inf), [1, 3]))

  Location  |  Observed  |  Expected  |  Reason
    (1)        Inf+NaNi    -Inf+Infi     'NaN' mismatch
    (2)        Inf+NaNi    -Inf+Infi     'NaN' mismatch
    (3)        Inf+NaNi    -Inf+Infi     'NaN' mismatch

This particular case is on Fedora 29, clang 7.0.1 libc++ 7.0.0.
hg id ada14ef3067f (stable)

The test passes when octave compiled with clang and libstdc++.


Dmitri A. Sergatskov <dasergatskov>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #51349:  bug55538_logspace_macOS.patch added by mmuetzel (1KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by dasergatskov (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-01 mmuetzel Attached File- => Added bug55538_logspace_macOS.patch, #51349
    2019-01-21 mtmiller Severity3 - Normal => 2 - Minor
        StatusNone => Confirmed
        Releaseother => dev
        Summarytest logscape fails on clang/libc++ compile => logspace BIST tests fail when Octave built with LLVM libc++

    Back to the top

    Powered by Savane 3.6