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

 
 

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

Submitter:  Dmitri A. Sergatskov <dasergatskov>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group Member
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>
Group Member
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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-f8d8.
    Corresponding source code