PostgreSQL Bugs

Collected from the PG bugs email list.

Bug ID15270
PG Version11beta2
Opened2018-07-09 19:00:31+00
Reported bySteven Winfield

Body of first available message related to this bug follows.

The following bug has been logged on the website:

Bug reference:      15270
Logged by:          Steven Winfield
Email address:      (redacted)
PostgreSQL version: 11beta2
Operating system:   RHEL 7.4


I've been experimenting with getting the whole of PG 11beta2 (not just the
JIT) compiling with the most recent stable version of llvm/clang: 6.0.1.

TL;DR: In src/include/port.h, inside the #else branch of #ifndef HAVE_ISINF,
there probably need to be some glibc version checks within the #ifdef
__clang__ block.

Full version:

I'm running on RHEL 7.4, with gcc 4.8.5 installed. The glibc version is 2.17
(as reported by ldd --version).
I used gcc to bootstrap llvm/clang 6.0.1, and then used that to rebuild
everything (and by "everything" I mean llvm, cfe (clang), clang-tools-extra,
lld, polly, compiler-rt, libcxx, and libcxxabi).

I configured postgres 11beta2 like this:

Environment variables:
CC = "clang"
CFLAGS = "-O3 -flto=thin -I<my clang install>/include/c++/v1"
CXX = "clang"
CXXFLAGS = "-O3 -flto=thin -stdlib=libc++ -I<my clang
LDFLAGS = "-fuse-ld=lld -flto=thin -L<my clang install>/lib"
CPP = "clang -E"
CLANG = "clang"

Configure options:
--with-includes=<my clang install>/include
--with-libraries=<my clang install>/lib

Configure performed the isinf check:

configure:15250: checking for isinf
configure:15269: clang -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv
-Wno-unused-command-line-argument -O3 -flto=thin ...
configure:15269: $? = 0
configure:15277: result: yes

...and set HAVE_ISINF in pg_config.h:

/* Define to 1 if you have isinf(). */
#define HAVE_ISINF 1

However, compilation failed in llvmjit_error.cpp like this:

In file included from llvmjit_error.cpp:24:
In file included from ../../../../src/include/jit/llvmjit.h:18:
In file included from <my clang install>/include/llvm-c/Types.h:17:
In file included from <my clang
In file included from <my clang install>/include/c++/v1/cmath:305:
In file included from <my clang install>/include/c++/v1/math.h:301:
In file included from /usr/include/math.h:70:
/usr/include/bits/mathcalls.h:202:19: error: conflicting types for
__MATHDECL_1 (int,isinf,, (_Mdouble_ __value)) __attribute__
../../../../src/include/port.h:356:15: note: expanded from macro 'isinf'
#define isinf __builtin_isinf
/usr/include/bits/mathcalls.h:202:19: note: '__builtin_isinf' is a builtin
with type 'int (...) noexcept'
../../../../src/include/port.h:356:15: note: expanded from macro 'isinf'
#define isinf __builtin_isinf

Looking in src/include/port.h I found this:

#ifndef HAVE_ISINF
extern int      isinf(double x);
 * Glibc doesn't use the builtin for clang due to a *gcc* bug in a version
 * newer than the gcc compatibility clang claims to have. This would cause
 * *lot* of superfluous function calls, therefore revert when using clang.
#ifdef __clang__
/* needs to be separate to not confuse other compilers */
#if __has_builtin(__builtin_isinf)
#undef isinf
#define isinf __builtin_isinf
#endif                                                  /*
__has_builtin(isinf) */
#endif                                                  /* __clang__ */
#endif                                                  /* !HAVE_ISINF */

I started afresh, and removed the whole of the #else branch above after
running configure, then continued the build. Everything successfully
compiled and I have confirmed the JIT works correctly. 

(In case this is useful...
In some unsuccessful attempts, when playing around with the environment
variables listed above, I ran into runtime errors even after a successful
compilation... I guess because the JIT provider is dynamically loaded. 
The complaint was about a missing symbol in libLLVM, which I undecorated

std::__1::default_delete<llvm::Module> >,
llvm::ArrayRef<llvm::GlobalValue*>, std::__1::function<void
(llvm::GlobalValue&, std::__1::function<void (llvm::GlobalValue&)>)>,

I think this was due to a mixture of c++ standard libraries being in use.)

Best wishes,


2018-07-09 19:00:31+00=?utf-8?q?PG_Bug_reporting_form?=BUG #15270: __builtin_isinf conflict when building using clang
2018-09-01 00:12:00+00Andres FreundRe: BUG #15270: __builtin_isinf conflict when building using clang