negative numbers (invoking undefined behavior)
Summary:
Various paths through hypot(x, y) will multiply x and y by a power of
two, perform the calculation in a range where IEEE-754 provides greater
precision, then undo the multiplication to determine the true result.
Undoing that multiplication is implemented as t1*w, where t1=2**k.
2**k is often computed by taking the high word of 1.0, then adding k<<20
(for doubles or long doubles) or k<<23 (for floats) to it, then
overwriting that high word. But when k is negative this left-shifts a
negative value -- and that's undefined behavior in many editions of C
and C++.
This patch should fix all hypot implementations to compute 2**k without
triggering this particular bit of undefined behavior.
Test Plan: I've only very lightly tested out the hypot(double, double)
change, in SpiderMonkey's JavaScript engine, for consistency with prior
behavior. The other functions' changes have more or less only been
eyeballed. Careful examination appreciated! Do note, however, that an
error in any of these changes would most likely produce a value that is
incorrect by a factor of two, so any mistake would most likely be
glaring if invoked.
Submitted by: Jeff Walden <jwalden@mit.edu>
Obtained from: https://github.com/freebsd/freebsd/pull/414
Reviewed by: dim, lwhsu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22354
Theoretically, this was breaking the size calculation for the symbol.
Noticed when doing a readthrough.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D22525
Summary:
Enable on powerpc64 and in lib/libclang_rt/Makefile change
MACHINE_CPUARCH to MACHINE_ARCH because on powerpc64
MACHINE_ARCH==MACHINE_CPUARCH so the 32-bit library overwrites 64-bit
library during installworld.
This patch doesn't enable any other libclang_rt libraries because they
need to be separately ported.
I have verified that games/julius (which fails on powerpc64 elfv2
without this change because of no libclang_rt profiling library) builds.
Test Plan: Ship it, test on powerpc and powerpcspe
Submitted by: pkubaj
Reviewed by: dim, jhibbits
Differential Revision: https://reviews.freebsd.org/D22425
MFC after: 1 month
X-MFC-With: r353358
Due to ELFv1 specific code in _ctx_start.S and makecontext.c, userspace
context switching was completely broken on ELFv2.
With this change, we now pass the libthr test suite.
Approved by: jhibbits (mentor)
Differential Revision: https://reviews.freebsd.org/D22421
Add ifdefs in the assembler for soft-float compile case.
Submitted by: Hiroki Mori
Reviewed by: ray@
Differential Review: https://reviews.freebsd.org/D22352
__has_attribute(__constructor__) is a better test for clang than
defined(__clang__). Switch to it instead.
While we're already here and touching it, pfg@ nailed down when GCC actually
introduced the priority argument -- 4.3. Use that instead of our
hammer-guess of GCC >= 5 for the sake of correctness.
The preproc logic was added at the last minute to appease GCC 4.2, and
kevans@ did clearly not go back and double-check that the logic worked out
for clang builds to use the new variant.
It turns out that clang defines __GNUC__ == 4. Flip it around and check
__clang__ as well, leaving a note to remove it later.
Reported by: cem
First, this commit is a NOP on GCC <= 4.x; this decidedly doesn't work
cleanly on GCC 4.2, and it will be gone soon anyways so I chose not to dump
time into figuring out if there's a way to make it work. xtoolchain-gcc,
clocking in as GCC6, can cope with it just fine and later versions are also
generally ok with the syntax. I suspect very few users are running GCC4.2
built worlds and also experiencing potential fallout from the status quo.
For dynamically linked applications, this change also means very little.
rtld will run libc ctors before most others, so the situation is
approximately a NOP for these as well.
The real cause for this change is statically linked applications doing
almost questionable things in their constructors. qemu-user-static, for
instance, creates a thread in a global constructor for their async rcu
callbacks. In general, this works in other places-
- On OpenBSD, __stack_chk_guard is stored in an .openbsd.randomdata section
that's initialized by the kernel in the static case, or ld.so in the
dynamic case
- On Linux, __stack_chk_guard is apparently stored in TLS and such a problem
is circumvented there because the value is presumed stable in the new
thread.
On FreeBSD, the rcu thread creation ctor and __guard_setup are both unmarked
priority. qemu-user-static spins up the rcu thread prior to __guard_setup
which starts making function calls- some of these are sprinkled with the
canary. In the middle of one of these functions, __guard_setup is invoked in
the main thread and __stack_chk_guard changes- qemu-user-static is promptly
terminated for an SSP violation that didn't actually happen.
This is not an all-too-common problem. We circumvent it here by giving the
__stack_chk_guard constructor a solid priority. 200 was chosen because that
gives static applications ample range (down to 101) for working around it
if they really need to. I suspect most applications will "just work" as
expected- the default/non-prioritized flavor of __constructor__ functions
run last, and the canary is generally not expected to change as of this
point at the very least.
This took approximately three weeks of spare time debugging to pin down.
PR: 241905
.jcr still needs a 0-entry added in crtend, even on !HAVE_CTORS archs, as
we're still getting .jcr sections added -- presumably due to the reference
in crtbegin. Without this terminal, the .jcr section (without data) overlaps
with the next section and register_classes in crtbegin will be examining the
wrong item.
PR: 241439
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D22132
Alter bsd.compat.mk to set MACHINE and MACHINE_ARCH when included
directly so MD paths in Makefiles work. In the process centralize
setting them in LIBCOMPATWMAKEENV.
Alter .PATH and CFLAGS settings in work when the Makefile is included.
While here only support LIB32 on supported platforms rather than always
enabling it and requiring users of MK_LIB32 to filter based
TARGET/MACHINE_ARCH.
The net effect of this change is to make Makefile.libcompat only build
compatability libraries.
Changes relative to r354449:
Correct detection of the compiler type when bsd.compat.mk is used
outside Makefile.libcompat. Previously it always matched the clang
case.
Set LDFLAGS including the linker emulation for mips where -m32 seems to
be insufficent.
Reviewed by: imp, kib (origional version in r354449)
Obtained from: CheriBSD (conceptually)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22251
- move from "oxtradoc" to RST/Sphinx documentation
- new "csv" encoder, which allows path and leaf lists
- address warnings from PVS-Stdio tool
- add "xolint" detected errors to the documentation
GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or
EHABI or whatever it's called. Export the same ones from LLVM-libunwind's
libgcc_s, on ARM. As part of this, convert libgcc_s from a direct
Version.map to one constructed from component Symbol.map files. This allows
the ARM-specific Symbol.map to be included only on ARM.
Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match
non-ARM definitions and ARM-specific expectations in libcxxrt /
libcompiler_rt.
No functional change intended for non-ARM architectures.
This commit does not actually flip the switch for ARM defaults from libgcc
to llvm-libunwind, but makes it possible (to compile, anyway).
Even though clang comes with a number of internal CUDA wrapper headers,
compiling sample CUDA programs will result in errors similar to:
In file included from <built-in>:1:
In file included from /usr/lib/clang/9.0.0/include/__clang_cuda_runtime_wrapper.h:204:
/usr/home/arr/cuda/var/cuda-repo-10-0-local-10.0.130-410.48/usr/local/cuda-10.0//include/crt/math_functions.hpp:2910:7: error: no matching function for call to '__isnan'
if (__isnan(a)) {
^~~~~~~
/usr/lib/clang/9.0.0/include/__clang_cuda_device_functions.h:460:16: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ int __isnan(double __a) { return __nv_isnand(__a); }
^
CUDA expects __isnan() and __isnanf() declarations to be available,
which are glibc specific extensions, equivalent to the regular isnan()
and isnanf().
To provide these, define __isnan() and __isnanf() as aliases of the
already existing static inline functions __inline_isnan() and
__inline_isnanf() from math.h.
Reported by: arrowd
PR: 241550
MFC after: 1 week
It turns out that a test of backtrace symbol resolution and formatting
requires symbols. Another option mightt be building with -rdynamic instead,
but this works for now.
Re-enabled skipped CI test, as it should now pass.
PR: 241562
Submitted by: lwhsu
Reported by: lwhsu
X-MFC-With: r354126, r354135, r354144
Drop portions that are unlit or redundant with llvm-libunwind: builtin.c,
unwind.h, and unwind_arm_ehabi_stub.c.
This code should now work with -fPIE binaries, should we choose to build any
that way.
When backtrace() array is full, signal an error so the underlying
Itanium-style C++ exception handling library (llvm-libunwind) knows to stop
tracing instead of continuing. (It should stop on its own when it finishes
unwinding, so this is mostly an extra seatbelt against an infinite loop bug
in the unwinder.)
For EFI at least, we can seed the environment
with VE_VERBOSE etc.
Reviewed by: stevek imp
Sponsored by: Juniper Networks
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22135
operation & ~limit where limit is a bool is clearly not what was intended,
given the line prior. Correct it to use the calculated mask for validation.
The cap_sysctl tests should now be functional again.
