The bsearch is called early during process initialization on Intel
platform, before TCB has been set up; and if compiler does not
enable __extern_inline it might call the symbol which might use an
invalid thread-pointer.
Expand the bsearch implementation from stdlib-bsearch.h with a
different name.
Checked on x86_64-linux-gnu with Intel chip.
GCC enables it by default, clang in the other hand sets -fno-trapping-math.
This is required to fix some math and stdlib tests that explicit raises
floating point exceptions (i.e. stdlib/tst-strtod-round on aarch64).
clangs warns of the implicit cast of RAND_MAX to float:
error: implicit conversion from 'int' to 'float' changes value from
2147483647 to 2147483648 [-Werror,-Wimplicit-const-int-float-conversion]
So make it explicit.
The multiplication is only required if the branch is taken, and the
compiler might not optimize it away.
Checked on aarch64-linux-gnu with gcc and clang.
clang defaults to -fsemantic-interposition, which in turn trigger some
optimizations (like inline) that makes some tests that rely on ELF
symbol interposition to fail. For this case, explicit set the symbol as
weak to avoid it.
clang with --target i668 might not produce supported relocations
that ld.bfd can use for -static-pie without -fPIC, which are used
on some tests. Disable them for now.
clang does not allow non integral constant expression in
_Static_assert. Replace with a macro that uses name bit-field
where an invalid constant expression sets its size to 0, resulting
in a error.
clang warns that converting from TIME_T_MAX to double (upper_bound)
loses precision (from 9223372036854775807 to 9223372036854775808):
tst-timespec.c:290:19: error: implicit conversion from 'time_t' (aka
'long') to 'double' changes value from 9223372036854775807 to
9223372036854775808 [-Werror,-Wimplicit-const-int-float-conversion]
.upper_bound = TIME_T_MAX, .lower_bound = 1, .result = 1,
^~~~~~~~~~
tst-timespec.c:48:20: note: expanded from macro 'TIME_T_MAX'
#define TIME_T_MAX TYPE_MAXIMUM (time_t)
^~~~~~~~~~~~~~~~~~~~~
../include/intprops.h:57:4: note: expanded from macro 'TYPE_MAXIMUM'
((t) (! TYPE_SIGNED (t)
\
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It does not matter for the test.
Checked on x86_64-linux-gnu.
clang fails building test-tgmath3-atan2.c:
error: '_Complex __int128' is invalid
_Complex __int128 var__Complex___int128 __attribute__ ((unused));
since it does not support _Complex with __int128. So disable
the test in such case.
clang issues:
../sysdeps/x86_64/fpu/test-double-vlen4.h:20:2: error: #include_next in
file found relative to primary source file or found by absolute path;
will search from start of include path
[-Werror,-Winclude-next-absolute-path]
Instead of suppress the warning, it is simpler to just include the
absolute path instead.
The type generic fabs expansion issues the floating point absolute with
the wrong argument type (for instance cabs with floating point or fabs
with a complex type) and clang warns that implicit conversion might
incur in unexpected behavior.
clang warns that the alias will be always resolve to
__GI___feupdateenv even if weak definition of __GI_feupdateenv
is overridden, which is really the intention.
The .cfi_label is a gas extension not supported by clang. From a
ziglang discussion [1], it seems that it is not really required.
[1] https://github.com/ziglang/zig/issues/3340
clang binds autogenerated memcpy/memset/memchr calls to the hidden
internal symbols, different than gcc that binds without hidden
attribute. And this triggers an linker issue with bfd:
ld: BFD (GNU Binutils for Ubuntu) 2.38 assertion fail
../../bfd/elf32-arm.c:4286
Similar to other architectures, bind internal memcpy and memcpy
symbols to the generic interface instead.
clang by default rejects the input casts with:
error: invalid use of a cast in a inline asm context requiring an
lvalue: remove the cast or build with -fheinous-gnu-extensions
And even with -fheinous-gnu-extensions clang still throws an warning
and also states that this option might be removed in the future.
For gcc the cast are still useful [1] as type-checking.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581722.html
Adhemerval Zanella
Fangrui Song