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.
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.
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.
I have no idea why, but the installed "sed" wrapper never terminates
on RHEL. If I don't use the wrappen the the tools build fine, so this
just uses the already set autoconf variables to attempt to determine
if the system sed/awk are gsed/gawk and if they are then this avoids
using the wrappers.
There's a few oddities here:
* I have no idea why the sed wrapper fails, as it seems super safe.
* I haven't run into any awk problems, but I figured I'd treat it the
same as it isn't any harder.
* We shouldn't have to support 10 year old distributions.
Hopefully this doesn't break anyone's builds...
Some systems don't have things like GMP, MPFR, and friends installed.
Rather than requiring them to be installed as root, this uses a bit of
GCC's built-in functionality to download these libraries and build
them along with GCC.
This allows the tools to build on Red Hat, but only if you install
newer host tools (I have GCC, make, and texinfo).
buildbot.dabbelt.com recently failed because it was unable to fetch
the downloaded files fast enough because mirrors.kernel.org was being
slow. This patch allows me to cache the downloaded files somewhere to
avoid these sorts of network problems.
This should also be generally useful for other people who build the
toolchain regularly.
I thought this was a problem with the build, but it turns out that was
actually related to my bad (and now reverted) patch from earlier this
week.
Regardless, this is the canonical way to build a cross compiler so now
that it's done I don't see a reason not to use it.
We used to allow GCC to fail the stage1 build because it's impossible
to build the full GCC without glibc. This builds just the parts we
need ("all-gcc" and "all-target-libgcc") and then install them.
This should make build failures a bit easier to debug, as now nothing
should fail.
Andrew Waterman
Andrew Waterman
Kito Cheng
Palmer Dabbelt
Andrew Waterman
Alex Suykov
Tim Newsome
Palmer Dabbelt
Colin Schmidt
SeungRyeol Lee
Darius Rad
Scott Beamer
Andrew Waterman