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)

Fri 17 Sep 2021 01:47:56 PM UTC, comment #11: 

I have an alternative suggestion. Can you reproduce the error if you compile octave with default flags?
I.e.

configure CC=clang CXX=clang++

And if that works work it up to you configuration and see what breaks it.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 17 Sep 2021 12:54:19 PM UTC, comment #10: 

Dmitri,
that looks interesting.

Same version as yours, but version
release-6-3-0                  29865:754013c36587

configured as, from the main tree:
mkdir compile; cd compile

env  LD_RUN_PATH=${HOME}/usr/lib CC=clang CXX=clang++ F77=gfortran LD=ld.lld \
AR=llvm-ar NM=llvm-nm STRIP=llvm-strip OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \
PKG_CONFIG_PATH=${HOME}/usr/lib/pkgconfig \
CPPFLAGS=-I${HOME}/usr/include \
CFLAGS="-O2 -flto -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector
-strong -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection" \
CXXFLAGS="-O2 -flto -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protect
or-strong -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection "\
LDFLAGS="-L${HOME}/usr/lib -fuse-ld=lld -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now" \
../configure --prefix=/home/MYUSER/usr/local/OCTAVE/6.3.x-clang  --disable-java --disable-float-truncate --disable-docs

Those options are the standard flags used to compile R

Could you retry with this setup ?

Regards

Pascal

(file #51935)

Pascal Dupuis <cdemills>
Project Member
Fri 17 Sep 2021 12:32:08 PM UTC, comment #9: 

That seems to work for me:

cat /etc/redhat-release
CentOS Stream release 8

rpm -qf /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/complex.h
libstdc++-devel-8.5.0-3.el8.x86_64

octave:1> assert (logspace (-Inf + 1i, Inf + 1i, 3), [0, NaN + NaN * 1i, complex(-Inf, Inf)])
octave:2> logspace (-Inf + 1i, Inf + 1i, 3)
ans =

     0 +   0i   NaN - NaNi  -Inf + Infi

octave:3> __octave_config_info__ ("CC")
ans = clang
octave:4> __octave_config_info__ ("hg_id")
ans = 55eeb7f0850b
octave:5>

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 17 Sep 2021 11:19:04 AM UTC, comment #8: 

This bug manifests itself under clang as

assert (logspace (-Inf + 1i, Inf + 1i, 3), [0, NaN + NaN * 1i, complex(-Inf, Inf)])

/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/complex:692: complex<_Tp> std::polar(const _Tp &, const _Tp &) [_Tp = double]: Assertion '__rho >= 0' failed.

Pascal Dupuis <cdemills>
Project Member
Fri 17 Sep 2021 11:17:02 AM UTC, comment #7: 

commentaire #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:
> https://hg.savannah.gnu.org/hgweb/octave/rev/955832ec3af1
>
> This is just to mark this as a known issue in the test suite. It doesn't make any change to what logspace returns.


Hello,
I compiled octave 6.3.0 with clang on CentOS8-Stream x86_64 machine and got the same behavior.

OTOH ... tried the equivalent in R:

> seq(-Inf, Inf, 3)

Error in seq.default(-Inf, Inf, 3) : 'from' must be a finite number

Does it really make sense to create a sequence spanning special numbers ?

Pascal

Pascal Dupuis <cdemills>
Project Member
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:
https://hg.savannah.gnu.org/hgweb/octave/rev/955832ec3af1

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")
endif

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:

https://github.com/JuliaMath/openlibm

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 ...

Anonymous
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>

int
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>

int
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
(-inf,inf)
mike@galago:~/src$ clang++ -stdlib=libstdc++ -o x x.cc && ./x
(-inf,inf)
mike@galago:~/src$ clang++ -stdlib=libc++ -o x x.cc && ./x
(inf,-nan)

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
fails:

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.
--

Dmitri A. Sergatskov <dasergatskov>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51935:  myconfig-clang added by cdemills (891B - application/octet-stream)
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 cdemills (Posted a comment)
  • -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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-09-17 cdemills Attached File- => Added myconfig-clang, #51935
    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.7