The HAVE_DECL_xxx defines are always defined to 0 or 1. The current
defines.h logic assumes every HAVE_xxx symbol is only defined iff it's
defined to 1 which causes this to break. Tweak the sed logic to only
match defines of 1.
Add support for compiling build tools with various -Werror settings.
Since the tools don't compile cleanly with the same set of flags as
the rest of the sim code, we need to maintain & test a separate list.
Only bother when not cross-compiling so we don't have to test all the
flags against the build compiler. This should be good enough for our
actual development flows.
Leave the igen code in place as it's meant to be used with newer
(to-be-written) code ported from the ppc version.
The sh code isn't really necessary as the opcodes enums have been
maintained independently from here, and the lists are out-of-sync
already.
This logic dates back to the original import, and seems to be for
handling systems where `rm -f` (i.e. no files) would error out.
None of that is relevant for us with current automake, so drop it.
Some compilers don't understand the semctl API and think it's an input
argument even when it's used as an output, and then complains that it
is being used uninitialized. Zero it out explicitly to workaround it.
This adds some runtime overhead, but should be fairly minor as it's a
small stack buffer, and shouldn't be that relevant relative to all the
other logic in these functions.
The cgen code uses DI as int64_t and UDI as uint64_t. The DI macros
are used to construct 64-bit values from 32-bit values (for the low
and high parts). The MAKEDI macro casts the high 32-bit value to a
signed 32-bit value before shifting. If this created a negative
value, this would be undefined behavior according to the C standard.
All we care about is shifting the 32-bits as they are to the high
32-bits, not caring about sign extension (since there's nothing left
to shift into), and the low 32-bits being empty. This is what we
get from shifting an unsigned value, so cast it to unsigned 32-bit
to avoid undefined behavior.
While we're here, change the SETLODI macro to truncate the lower
value to 32-bits before we set it. If it was passing in a 64-bit
value, those high bits would get included too, and that's not what
we want.
Similarly, tweak the SETHIDI macro to cast the value to an unsigned
64-bit instead of a signed 64-bit. If the value was only 32-bits,
the behavior would be the same. If it happened to be signed 64-bit,
it would trigger the undefined behavior too.
Rename the temp var to avoid shadowing another one:
.../sim/cris/semcrisv10f-switch.c:11032:22: error: declaration of ‘tmp_tmpb’ shadows a previous local [-Werror=shadow=compatible-local]
11032 | tmp_tmpb = ({ SI tmp_tmpb;
| ^~~~~~~~
.../sim/cris/semcrisv10f-switch.c:11031:24: note: shadowed declaration is here
11031 | tmp_tmpres = ({ SI tmp_tmpb;
| ^~~~~~~~
The condition & swap code decoder only checks known bits and sets
based on that. If the variable is out of range, it ends up returning
uninitialized data. Turn that case into a hard error.
This fixes build warnings like:
sim/cris/semcrisv10f-switch.c:13115:11: error:
variable 'tmp_condres' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
The common igen code was forked from the ppc long ago. The filter
module is still pretty similar in API, so we can unfork them with
a little bit of effort.
The filter.c module is still here because of the unique it_is API.
The common igen code doesn't seem to have an equiv API as this only
operates on two strings and not an actual filter object, and it's
easy enough to leave behind to unfork the rest.
The common igen code was forked from the ppc long ago. The lf module
is still pretty similar in API, so we can unfork them with a little
bit of effort.
Some of the generated ppc code is now slightly different, but that's
because of fixes the common igen code has gained, but not the ppc igen
code (e.g. fixing of #line numbers).
The ppc code retains lf_print__c_code because the common igen code
rewrote the logic to a new table.c API. Let's delay that in the ppc
code to at least unfork all this code.
Add standard multiple inclusion protection, and add a few missing
local includes when one header uses another. This isn't complete,
but fixes some short comings seen when merging the ppc igen.
The common sim-endian is a forked & updated version of the ppc code.
Fortunately, they didn't diverge from the basic APIs, so they are
still compatible, which means we can just delete the ppc version now
that the build env is merged at the top-level.
This is a bit redundant for most ports as they go through sim-basics.h
which always includes sim-types.h before including sim-endian.h, but in
order to unify ppc's sim-endian code, we need this include here. Plus,
it's the directly we generally want to go to get away from one header
that defines all APIs and causes hard to untangle dependencies.
The common/ code has macros with the same name but different behavior:
it's for declaring integer constants as 64-bit, not for casting them.
Rename ppc's local variant since it's only used in this file in order
to avoid conflicts.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. It adds some overhead, so it's not great, but it shouldn't
be a big deal. This will go away once compilation is hoisted up.
Now that the ppc configure script is just namespaced options, we can
move it to ppc/acinclude.m4 and include it directly in the top-level
configure script and kill off the last subdir configure script.
Switch from ad-hoc $silent checks & echo calls to standard
AC_MSG_CHECKING & AC_MSG_RESULT calls. Also delete pointless
variable setting after calling AC_MSG_ERROR.
Now that the ppc script only checks configure options and sets up
variables in the Makefile from those, delete all the compile related
logic to greatly simplify the configure script.
While the sim code doesn't utilize HAVE_LONG_LONG itself, other code
(like libiberty) seem to, so check for it in the top-level for all
ports to leverage.
