Are there compilerflags that enable the old behavior again? - The correctest behavior is utterly bullshit (sorry for the Torvaldism) if it breaks our packages.
I'm not even sure, if this is a gcc or a glibc problem.
Perhaps it's just a missing detail in how we compile gcc, but then it worked fine before glibc-2.26.
The gcc patch for glibc-2.26 changes nothing c++11 related but just the necessary bits.
This is why I highly doubt there could be compiler flags for _old behaviour_ - there is no such thing.
> I think #include <cmath> should be enough for these functions.
For llvm I tried to `#include <cmath>` both after and before `#include <cstdint>` in `include/llbm/Support/NativeFormatting.h`.
Now there are some more errors besides the known ones :-P
```
/builddir/llvm-4.0.1.src/projects/compiler-rt/lib/builtins/atomic.c: In function 'unlock':
/builddir/llvm-4.0.1.src/projects/compiler-rt/lib/builtins/atomic.c:93:3: warning: implicit declaration of function '__c11_atomic_store' [-Wimplicit-function-declaration]
__c11_atomic_store(l, 0, __ATOMIC_RELEASE);
^~~~~~~~~~~~~~~~~~
/builddir/llvm-4.0.1.src/projects/compiler-rt/lib/builtins/atomic.c: In function 'lock':
/builddir/llvm-4.0.1.src/projects/compiler-rt/lib/builtins/atomic.c:99:11: warning: implicit declaration of function '__c11_atomic_compare_exchange_weak' [-Wimplicit-function-declaration]
while (!__c11_atomic_compare_exchange_weak(l, &old, 1, __ATOMIC_ACQUIRE,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
So no, including cmath does not seem to solve the problem.
Looking at `/usr/include/c++/6.3/cmath` I see many of the seemingly missing definitions being wrapped in one or more of
```
#ifndef __CORRECT_ISO_CPP_MATH_H_PROTO
```
```
#ifndef __CORRECT_ISO_CPP_MATH_H_PROTO_FP
```
```
#ifndef __CORRECT_ISO_CPP_MATH_H_PROTO_INT
```
and I see no definition of this macro in e.g. `/usr/include/c++/6.3/x86_64-unknown-linux-gnu/bits/c++config.h` or anywhere else below `/usr/include`. This doesn't help me to understand where the real problem arises from...