Nothing passes this to dgen, and even if it did, nothing would happen
because the generated spreg.[ch] files don't include any references
back to the original data table. So drop it to simplify.
Since we know we'll return 0 by default, we don't have to output case
statements for readonly or length fields whose values are also zero.
This is the most common case by far and thus generates a much smaller
switch table in the end.
Instead of writing:
case 1:
return 1;
case 2:
return 1;
...etc...
Output a single return so we get:
case 1:
case 2:
case ...
return 1;
This saves ~100 lines of code. Hopefully the compiler was already
smart enough to optimize to the same code, but if not, this probably
helps there too :).
This saves a single line for the same result. By itself, it's not
interesting, but we can further optimize the generated output and
completely omit the switch table in some cases. Which we'll do in
follow up commits.
When merging ppc configure checks into the top-level, these 2 funcs
were accidentally dropped (probably due to incorrect resolution of
conflicts). Restore them since the ppc code utilizes them both.
This controls only one thing: how to call mkdir(). The gnulib code
already has a mkdir module that provides this exact logic for us, so
punt the code entirely.
This macro expansion was missing a set of outer-most parenthesis which
some compilers would complain about depending on how the macro is used.
This is just standard good macro hygiene too.
We've never run these helper programs directly. The igen program
includes the relevant source files directly and runs the code that
way. So stop wasting developer CPU time linking programs that are
never run. We leave the rules in place for people who need to test
and debug the specific bits of code every now & then.
The intention of this code seems to be to indicate that this insn
should not be used and produces undefined behavior, so instead of
setting registers to bogus values, call Unpredictable. This fixes
build warnings due to 32-bit/64-bit type conversions, and outputs
a log message for users at runtime instead of silent corruption.
Bug: https://sourceware.org/PR29276
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 64. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32-vs-64
based on the $target. We can easily merge this with the top-level
configure script to clean things up a bit.
The install code was using $SUBDIRS to track all enabled arches. This
works, but isn't great if we want to add a subdir that isn't an arch
port, or as we merge the subdirs into the top-level. Create a new var
explicitly to track the list of enabled arches instead.
This was needed when the install step was run in subdirs, but now
that we process that entirely in the top-level, we don't need to
pass this down, so drop it.
Automake will run each subdir individually before moving on to the next
one. This means that the linking phase, a single threaded process, will
not run in parallel with anything else. When we have to link ~32 ports,
that's 32 link steps that don't take advantage of parallel systems. On
my really old 4-core system, this cuts a multi-target build from ~60 sec
to ~30 sec. We eventually want to move all compile+link steps to this
common dir anyways, so might as well move linking now for a nice speedup.
We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care
of the install ourselves rather than letting automake process it.
We still have to maintain custom install rules due to how we rename
arch-specific files with an arch prefix in their name, but we can at
least unify the logic in the common dir.
Nothing in the tree checks this option, or has checked for decades.
The pre-cvs-import ChangeLog suggests this was added & removed back
then, but can't be sure as that history doesn't exist in the VCS.
Nothing checks this define anywhere, so drop all the logic. We don't
want this to be a configure option in the first place as all such usage
should be automatic & following proper types.
This has only ever had a single option that's enabled by default.
The objects it adds are pretty small and don't add overhead at
runtime if it isn't used, so just enable it all the time to make
the build code simpler.
These manual settings were necessary when we weren't doing automatic
header dependency tracking. That was changed a while ago, and we use
automake now to do it all for us. As a result, many of these vars
aren't even referenced anymore.
Further, some of the source file generation (e.g. .c files, or igen,
or cgen outputs) were moved to the common automake build, and it takes
care of dependency tracking for us with the object files.
We have configure tests for this in the top-level configure script
to link this when necessary, so we don't need to explicitly list it
for specific ports.
With more C libraries moving functions entirely into the main -lc,
change the AC_CHECK_LIB calls to AC_SEARCH_LIBS so we look in there
first and avoid extra linkage when possible.
COMMON_LIBS is set to $(LIBS), and CONFIG_LIBS is set to that plus
@LIBS@. This leds to the values being used twice. Inline the
CONFIG_LIBS variable without @LIBS@ since it's used only once.
The top-level already sets up a libtool script for the host, so use
that when linking rather than invoking CC directly. This will also
happen when we (someday) move the building to pure automake.
This test uses the test itself as an input to stating regular files.
This gets funky though: when we run check in parallel, the output
object dir is the subdir that matches the .exp file. When we run
with -j1, the output object dir is the sim builddir itself.
The old test would append argv[0] to find the file, while the new
test uses basename on it. Each method works in only one of the
aforementioned build scenarios. Rather than complicate this any
more, switch to a different file that we know will always exist:
the Makefile.
This test assumes that /bin/sh will never be a CRIS ELF by way of
assuming that the current bfd cannot load it (since a basic cris
cross-compiler only understands CRIS ELFs). In a multi-target
build though, bfd understands just about every ELF out there, so
we're able to read the /bin/sh format before failing at a diff
point in the cris code.
Let's switch to using / instead since it'll fail for a similar
reason (at least similar enough for what this test is testing).
This is used to allow for dangling \ in object lists, but these are the
only ports that do it, and it isn't really necessary. Punt it to keep
the various makefiles harmonized.
The erc32 sim does a lot itself, including handling of the CLI. It
used to provide a run-compatible interface in the pre-nrun days, but
it was dropped when the old run interface was punted. Since the old
commit 465fb143c8 ("sim: make nrun the
default run program"), the erc32 run & sis programs have been the
same, and erc32 hasn't provide a real run-compatible interface.
Simplify this by linking the two programs via ln/cp instead of running
the linking phase twice to produce the same result. If/when we fix up
the erc32 port to have a proper run interface, it should be easy to
split these back apart into real programs.
Note: the interf.o reference in here is a bit of a misdirect. Since
that object is placed into libsim.a, it's never been linked into the
programs since the linker ignores objects that aren't referenced, and
only gdb uses those symbols.
The v850 port uses -DDEBUG to control whether to enable internal tracing.
We already have such options via the common trace framework, and those
can be controlled at build time via configure flags (which the v850 code
currently cannot). So switch it over to WITH_TRACE_ANY_P to simplify the
v850 build code even if it doesn't (yet) respect any other trace options.
