This is in the Accellera version of systemc, used when gem5 is built
into systemc as a black box. std::gets was depdecated in c++11, and
removed entirely in c++14. Since gem5 has moved to c++14, this can't be
brought in with "using" in that header. More recent versions of systemc
from Accellera may have this fixed, and it's pretty bad practice to have
a universal header file squash unrelated namespaces like that in the
first place.
Rather tha update all of this copy of systemc, this change just makes
the smallest adjustment possible to get things to work again.
Change-Id: I8a95665d4b5d49ffc014097714cf2e602bf9b937
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42583
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Starting with version 3, scons imposes using the print function instead
of the print statement in code it processes. To get things building
again, this change moves all python code within gem5 to use the
function version. Another change by another author separately made this
same change to the site_tools and site_init.py files.
Change-Id: I2de7dc3b1be756baad6f60574c47c8b7e80ea3b0
Reviewed-on: https://gem5-review.googlesource.com/8761
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
The existing scripts were including pthread code and QT code at the same
time, and also insisting on an having a set of architecture specific
source files for whatever the current architecture is.
This change selects using either QT or pthreads based on the host
architecture, distributes accumulating source files, list source files
explicitly (to avoid including redundant coroutine libraries) and makes
scons insist on an architecture specific QT implementation only if QT is
being used. It also defines a preprocessor symbol which tells some headers
whether or not pthreads are being used, and also clones the scons
environment to avoid leaking flags into the main environment used to
compile gem5 itself.
If the host architecture isn't supported by systemc, a warning will be
printed, and the various build products and SConscript files will be
skipped over.
Change-Id: I1a40123a11e49e02922a054f093246cf197087bf
Reviewed-on: https://gem5-review.googlesource.com/3461
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Reviewed-by: Christian Menard <christian.menard@tu-dresden.de>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
In the past it happened several times that some changes in gem5 broke the
SystemC coupling. Recently Accelera has changed the licence for SystemC
from their own licence to Apache2.0, which is compatible with gem5.
However, SystemC usually relies on the Boost library, but I was able to
exchange the boost calls by c++11 alternatives. The recent SystemC version
is placed into /ext and is integrated into gem5's build system. The goal is
to integrate some SystemC tests for the CI in some following patches.
Change-Id: I4b66ec806b5e3cffc1d7c85d3735ff4fa5b31fd0
Reviewed-on: https://gem5-review.googlesource.com/2240
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
