Defining a isclang() function?

I compiled Octave with clang on a CentOS 8 Stream machine. ‘make test’ fails in logspace.m, on test defined by !ismac(). The real cause is clang. I commented on bug #55538

Could a function isclang() be defined ? Return value is 1 if CC = clang and CXX=clang++, 0 otherwise.



IIUC, bug #55538 is due to using libc++ instead of libstdc++.

Would it be possible to compile with clang but still link with libstdc++? (I’d guess it is.) In that case, there is no need to expect an error in that test.
And the other way round: Are there compilers other than clang that can link with libc++? In that case, I’d still expect that test to fail.

I guess what I’m trying to say is that having a function isclang wouldn’t really help in that particular case. Instead, we would somehow need to know with which C++ standard library Octave was linked. I don’t know how that would be done reliably. (But I haven’t checked either.)

As I commented on this bug report it works fine on my machine:
cat /etc/redhat-release
CentOS Stream release 8

rpm -qf /usr/lib/gcc/x86_64-redhat-linux/8/…/…/…/…/include/c++/8/complex.h


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

@dasergatskov: Thanks. That basically confirms that Octave can be compiled with clang and linked with libstdc++. In that case, the test passes (like expected).

@mmuetzel : clang has a few features that differ from gcc. In my case I compiled Octave-6.3.0 with

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 \

I wanted to use LTO, enhance security features, use ld.lld as linker, … Basically all those switches are borrowed from R on CentOS Stream 8



Mine compiled with

octave_config_info (“CFLAGS”)
ans = -O2 -march=native -mavx -mavx2 -flto=8

I noticed that going with higher optimization (and with AVX) breaks some numerical precision tests.