A user just added RTEMS support to the GCC port (via newlib), which is
very similar to the existing newlib port but has a different tuple.
This patch allows users to override the tuples to build other targets if
they want to.
We need this to have different polarity for different platforms (Windows
vs RedHat). I don't know how to autodetect this for now, so I'm just
doing it manually.
For some reason, a Newlib multilib build includes a "default" library
in addition to the multilibs ones. This results in confounding error
messages when an invalid multilib is requested on the GCC command line.
Now, it reports a more sensible "cannot find -lc".
Soft-float calling convention is default, but an alternate hard-float
calling convention (with doubles passed as in soft-float, but floats
passed as in hard-float) is supported.
This also adds a submodule pointer to the RISC-V DejaGnu port, which is
required to run the GCC test suite. The DejaGnu port only supports the
GDB simulator. A bunch of tests fail right now, but that's expected.
As we prepare binutils for upstreaming we want to start closely tracking
upstream changes. There's a riscv-binutils-gdb repository that contains
the binutils port, and I want to centralize all the development there.
This commit uses that repository instead of the patches that used to
live here, so we're less likely to lose patches.
In addition to some small changes, here's the bigger ones:
* gen_rtx_SET no longer takes a VOIDmode, apparently that was the only
valid argument in that position so it's been dropped.
* GEN_CALL is now gen_call.
* The #defines in riscv.h need to be defined to 1, not just defined,
since they're now used in "if ()" statements.
* glibc is passed "--disable-werror", since the new GCC throws a bunch
of pointless errors like "misleading indentation". This is all in
upstream glibc code.
This installs the headers to the same place, but for some reason
something on a2 isn't working correctly and is trying to remove the
headers from /usr first.
It's no longer the case that building the toolchain with
"--disable-float" turns off floating-point by default. This passes the
correct arguments to all the various sub-configures in order to ask for
floating-point support to be either enabled or disabled.
There was one change required here: support for "MEMMODEL_SYNC_*". This
very long GCC post <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697>
talks about the formalization of the C++ memory model. It looks like
this is it to allow for some ARM stupidity where they can speculatively
issue some memory operations.
As far as I can tell, the right thing to do here is to just treat the
SYNC versions the same as the non-SYNC versions -- this is the same
thing ia64 and rs600 do. I can't find "MEMMODEL_SYNC" anywhere else
interesting, so there might be some flag to set to avoid doing this, but
I couldn't find it.
This just requires a single extra argument to a function call, which I copied
from aarch64. I've only tested that newlib builds, but I don't see how this
could cause any problems... :)
I was hoping this would help with my attempts to integrate the GDB and binutils
ports into one repo for upstreaming, but it looks like 2.25.1 is still a bit
too old for this.
"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.
Palmer Dabbelt
Johannes Löthberg
Andrew Waterman
Kito Cheng
Andrew Waterman
Andrew Waterman
Alex Suykov
Tim Newsome
Palmer Dabbelt
Colin Schmidt
SeungRyeol Lee
Darius Rad
Scott Beamer