"cp -a" preserves everything about the copied files, the most
important of which for us is the modification times. It appears all
the GNU stuff has sufficiently broken toolchains such that randomizing
the order of the modification times of the distributed sources is
sufficient to break the build. I'm hoping this fixes an intermittent
failure in my builds.
Due to a few missing double long complex functions, newlib fail's configure's c99 tests. With _GLIBCXX_USE_C99 unset, a variety of C++11 functions are lost, including to_string and snprintf. This modifies configure to not depend on the results of the complex test. This change is safe since code that attempts to use these missing complex functions will still fail to compile.
To use our old definition, which is smaller and more performant, we needed
to link sysdep.c into a few more libraries for glibc 2.22 than 2.21.
This effectively reverts commit 7cd185cf83.
I was getting undefined references to __syscall_error when using the
old one. aarch64's version doesn't calal into __syscall_error but
instead uses the defined macros to inline the functionality of
__syscall_error, which certainly feels like it's in the spirit of
INLINE_SYSCALL.
I'm not sure why the old one stopped working, but the MIPS version of
this file has always been using __BYTE_ORDER__, and that is defined.
I also had to use __ORDER_LITTLE_ENDIAN__ instead of LITTLE_ENDIAN, as
that has gone away as well.
This removes a difference between RISC-V's hardfloat and softfloat
implementations. Since there's no actual code here (just a shim to
GCC's builtins), I don't think there's any reason to have this be
hardfloat specific.
I moved this because it's not in Tilera's FPU directory, and that's
where this file came from.
As per but #73, this was causing some compile failures related to
nothrow when using C++ and pedantic. The actual fix is to wrap this
with "__NTH", but Tilera's version looks simpler because it just calls
a GCC builtin rather than providing a second implementation.
I tried removing this file, but then I don't get inlined versions of
these calls.
I commited this too quickly last time and it's been breaking a whole
bunch of stuff. Until I managed to get multilib working in a sane
way, I'm just going to go ahead and turn it off by default. You can
still pass "--with-arch", but doing so while also passing things like
"--enable-multilib" or "--disable-atomics" might have unexpected
results.
We sometimes use t0 as a link register, e.g. for the compressed prologues
and epilogues, and so we want microarchitectures to push the RAS when
rd=t0 and pop the RAS when rs1=t0. Thus, we want to avoid using t0 for
indirect calls to avoid errant RAS operations.
If a call crosses an alignment directive, the PC-relative offset could
actually increase post-relaxation. Account for this by assuming the
offset could increase by up to a page size when the caller and callee
lie in different output sections.
Doing so prevents -m32/-m64 from having any effect. This patch is just
a workaround; we should fix the runtime handling of --with-arch so that
specifying -m32/-m64 on the command line takes priority.
This simply stops GCC's parse whenever it sees an 'X' in an ISA
string. This is the best I can do until some clarafications are made
to the RISC-V user spec that allows ISA extensions to be parsed.
Some glibc floating point routines use inline assembly. This changes
them to use regular C code to do this when compiled without hardware
floatint-point support. The change just uses regular C to perform
these operations when compiled on ABIs without hardware floating
point.
Andrew Waterman
Andrew Waterman
Palmer Dabbelt
Palmer Dabbelt
Scott Beamer
Mike Frysinger
Prashanth Mundkur
Arun Thomas