There are two overloaded-virtual issues reported by g++13.
1. Copy assignment and move assignment overload is hidden in the derived
class
[ CXX] src/mem/cache/replacement_policies/weighted_lru_rp.cc -> ALL/mem/cache/replacement_policies/weighted_lru_rp.o
In file included from src/mem/cache/base.hh:61,
from src/mem/cache/base.cc:46:
src/mem/cache/cache_blk.hh:172:5: error: ‘virtual gem5::CacheBlk& gem5::CacheBlk::operator=(gem5::CacheBlk&&)’ was hidden [-Werror=overloaded-virtual=]
172 | operator=(CacheBlk&& other)
| ^~~~~~~~
src/mem/cache/cache_blk.hh:518:19: note: by ‘gem5::TempCacheBlk& gem5::TempCacheBlk::operator=(const gem5::TempCacheBlk&)’
518 | TempCacheBlk& operator=(const TempCacheBlk&) = delete;
| ^~~~~~~~
In this case, we can exiplict using parent operator= to keep the
function overload.
2. Intended overload hidden in SystemC is reported as error.
In file included from src/systemc/ext/tlm_utils/simple_initiator_socket.h:24,
from src/systemc/tlm_bridge/gem5_to_tlm.hh:72,
from build/ALL/python/_m5/param_Gem5ToTlmBridge256.cc:17:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh: In instantiation of ‘class tlm::tlm_base_initiator_socket<256, tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1, sc_core::SC_ONE_OR_MORE_BOUND>’:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:185:7: required from ‘class tlm::tlm_initiator_socket<256, tlm::tlm_base_protocol_types, 1, sc_core::SC_ONE_OR_MORE_BOUND>’
src/systemc/ext/tlm_utils/simple_initiator_socket.h:37:7: required from ‘class tlm_utils::simple_initiator_socket_b<sc_gem5::Gem5ToTlmBridge<256>, 256, tlm::tlm_base_protocol_types, sc_core::SC_ONE_OR_MORE_BOUND>’
src/systemc/ext/tlm_utils/simple_initiator_socket.h:156:7: required from ‘class tlm_utils::simple_initiator_socket<sc_gem5::Gem5ToTlmBridge<256>, 256, tlm::tlm_base_protocol_types>’
src/systemc/tlm_bridge/gem5_to_tlm.hh:147:46: required from ‘class sc_gem5::Gem5ToTlmBridge<256>’
/usr/include/c++/13/type_traits:1411:38: required from ‘struct std::is_base_of<sc_gem5::Gem5ToTlmBridgeBase, sc_gem5::Gem5ToTlmBridge<256> >’
ext/pybind11/include/pybind11/detail/../detail/common.h:880:59: required from ‘struct pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>, sc_gem5::Gem5ToTlmBridgeBase, std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >::is_valid_class_option<sc_gem5::Gem5ToTlmBridgeBase>’
ext/pybind11/include/pybind11/detail/../detail/common.h:719:35: required by substitution of ‘template<class ... Ts> using pybind11::detail::all_of = pybind11::detail::bool_constant<(Ts::value && ...)> [with Ts = {pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>, sc_gem5::Gem5ToTlmBridgeBase, std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >::is_valid_class_option<sc_gem5::Gem5ToTlmBridgeBase>, pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>, sc_gem5::Gem5ToTlmBridgeBase, std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >::is_valid_class_option<std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >}]’
ext/pybind11/include/pybind11/pybind11.h:1506:70: required from ‘class pybind11::class_<sc_gem5::Gem5ToTlmBridge<256>, sc_gem5::Gem5ToTlmBridgeBase, std::unique_ptr<sc_gem5::Gem5ToTlmBridge<256>, pybind11::nodelete> >’
build/ALL/python/_m5/param_Gem5ToTlmBridge256.cc:34:179: required from here
src/systemc/ext/tlm_utils/../core/sc_port.hh:125:18: error: ‘void sc_core::sc_port_b<IF>::bind(sc_core::sc_port_b<IF>&) [with IF = tlm::tlm_fw_transport_if<>]’ was hidden [-Werror=overloaded-virtual=]
125 | virtual void bind(sc_port_b<IF> &p) { sc_port_base::bind(p); }
| ^~~~
In file included from src/systemc/ext/tlm_utils/simple_initiator_socket.h:27:
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:133:18: note: by ‘tlm::tlm_base_initiator_socket<256, tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1, sc_core::SC_ONE_OR_MORE_BOUND>::bind’
133 | virtual void bind(bw_interface_type &ifs) { (get_base_export())(ifs); }
| ^~~~
src/systemc/ext/tlm_utils/../core/sc_port.hh:124:18: error: ‘void sc_core::sc_port_b<IF>::bind(IF&) [with IF = tlm::tlm_fw_transport_if<>]’ was hidden [-Werror=overloaded-virtual=]
124 | virtual void bind(IF &i) { sc_port_base::bind(i); }
| ^~~~
src/systemc/ext/tlm_utils/../tlm_core/2/sockets/initiator_socket.hh:133:18: note: by ‘tlm::tlm_base_initiator_socket<256, tlm::tlm_fw_transport_if<>, tlm::tlm_bw_transport_if<>, 1, sc_core::SC_ONE_OR_MORE_BOUND>::bind’
133 | virtual void bind(bw_interface_type &ifs) { (get_base_export())(ifs); }
| ^~~~
From the code comment, it's intended in SystemC header.
// The overloaded virtual is intended in SystemC, so we'll disable the warning.
// Please check section 9.3 of SystemC 2.3.1 release note for more details.
The issue is we should move the skip to the base class.
Change-Id: I6683919e594ffe1fb3b87ccca1602bffdb788e7d
The systemc headers are supposed to be hermetic, so that they can be
included from generic systemc code without any dependency on the gem5
code base, at least when the systemc components are compiled, outside
of those header files themselves. It should be possible to copy the
"ext" directory out of the tree and make it available to systemc code,
and that code should be compileable.
Change-Id: Iec16a534ac04c7895cd8a30940b0acf64c257dde
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49618
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The current tests included don't require boost header to work. Remove
the dependency. This also gets rid of the warning message generated by
the latest boost headers.
Tested by running systemC tests:
src/systemc/tests/verify.py --update-json \
--filter-file=src/systemc/tests/working.filt -j 56 build/ARM/
Change-Id: I9d3bfe145597335abdf24f2de85ed3c0708aea27
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40315
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Based on the 64-bit ELF ABI for Power systems (ppc64 and
ppc64le), the data types int64_t and uint64_t are typedefs
of long and unsigned long respectively. If the SystemC
data types int64 and uint64 point to these, several errors
are observed while building the simulator on Power systems
due to ambiguity between the types when overloading some
operators and functions.
E.g.
...
build/POWER/systemc/ext/channel/../dt/bit/sc_bit.hh:114:17: error: 'static bool sc_dt::sc_bit::to_value(sc_dt::int64)' cannot be overloaded with 'static bool sc_dt::sc_bit::to_value(long int)'
114 | static bool to_value(tp i) { return to_value((int)i); }
| ^~~~~~~~
...
build/POWER/systemc/ext/channel/../dt/bit/sc_bit.hh:114:17: note: previous declaration 'static bool sc_dt::sc_bit::to_value(long int)'
114 | static bool to_value(tp i) { return to_value((int)i); }
| ^~~~~~~~
...
This adds a minor change to a SystemC datatype header to
ensure that the simulator can be built on Power systems.
Change-Id: Icd8bb38134bf98768cc38f9856d7d11a01ebaf21
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31414
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These bring in some pieces that those headers use but were only
coincidentally included by something else when they were used.
Change-Id: I5f119260d8f25d914d8545a60834f23f65f82d0c
Reviewed-on: https://gem5-review.googlesource.com/c/16948
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Some systemc code bases expect to find a SYSTEMC_HOME environment
variable which points to the installed header files provided by
systemc, all under ${SYSTEMC_HOME}/include. The systemc headers in
gem5 are not supposed to be installed anywhere, but to satisfy those
expectations this change creates a dummy systemc_home directory with
an include/ in it which has headers which just include the actual
headers in src/systemc/ext.
More gem5 aware code bases can still access the headers either by
letting gem5's scons environment -I the ext directory, or can do so
themselves if they're not being built by gem5's scons.
Change-Id: I5f2e6bfcf20dd314d525207c2e13ca53474a33f3
Reviewed-on: https://gem5-review.googlesource.com/c/16263
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The includes in src/systemc/ext are supposed to use relative paths so
that they can be included in other bodies of code which aren't based
in gem5 and don't share it's -I-s, or potentially even have access to
anything outside of src/systemc/ext.
Change-Id: Icde457329c2c4ab4689221015bfcfe2ff8b051f0
Reviewed-on: https://gem5-review.googlesource.com/c/16262
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
g++ complained about comparing an signed int loop counter with the
return value of a size() function. This change changes it to an
unsigned to make g++ happy/quiet.
Change-Id: I28fa79c448465b24d77b5623860f9b991f313561
Reviewed-on: https://gem5-review.googlesource.com/c/16286
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
There are a couple things this CL fixes related to the TLM #includes.
1. Removes #includes of <systemc> and <tlm>. These bring in a header
file from boost which shouldn't be necessary but which some of the
tests (and likely some external code) depends on. We avoid including
those in files built into gem5 itself so that gem5 isn't dependent on
boost.
2. All includes in ext should be relative. That way those headers can
be removed from gem5 and still build, allowing them to be moved over
to or referenced from a foreign codebase which isn't part of gem5.
Change-Id: I76e267385b48cb4fe93aea89ec8319c76465a0a4
Reviewed-on: https://gem5-review.googlesource.com/c/15796
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
The sc_event_finder class in Accellera's implementation has a
non-standard report_error function that it uses internally. The TLM
headers were calling that function in their own event finder subclass.
This change replaces that call with what should be an equivalent bit of
code which is based on the report_error implementation.
Change-Id: Id57d26791df01403a77e70d5f4a00f650dc33599
Reviewed-on: https://gem5-review.googlesource.com/c/15063
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
The former is either the same as the later, or a custom wrapper if
C++11 isn't supported. Since we generally expect C++11 support, we can
skip the indirection.
Change-Id: I9a45e3854bb7cc56d094e3fe2773fe4b5c94403b
Reviewed-on: https://gem5-review.googlesource.com/c/15297
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
This makes those files more consistent with other headers in gem5. The
top level headers (tlm and tlm.h) and the tlm_utils headers were left
alone since the user might reasonably expect those to have a well known
name. The tlm_core headers by comparison are an implementation detail,
and users shouldn't include them directly by name.
Change-Id: Ibc82e8159e47717c79d76f50ed96fdd619294a06
Reviewed-on: https://gem5-review.googlesource.com/c/15067
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
A lot of TLM implementation assumes the string functions (memcpy,
memset, etc) are available, but don't include cstring. Lets do that
for them to avoid having to fix up a lot of places.
Change-Id: I1f26d3a227fe2cefc2613e24cbb0333216e46ee9
Reviewed-on: https://gem5-review.googlesource.com/c/15060
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
We already know those files belong to tlm because of the directory
they're in. Removing the prefix makes the paths of the headers less
enormously long.
Change-Id: I869e58fae904162f353bb31f4c0919fba08dffa6
Reviewed-on: https://gem5-review.googlesource.com/c/15059
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
The TLM event finder class was calling implementation specific
functions from the Accellera version of systemc. This change replaces those
calls with equivalent calls which match the gem5 implementation.
Change-Id: I0ecdb0a4bf09aeb1aad823a01105fbd88edb4601
Reviewed-on: https://gem5-review.googlesource.com/c/15075
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
These headers will need to be cleaned up and have some Accellera
specific quirks ironed out of them, but I'll do that in a later change
to make it clear what those changes are.
Change-Id: Ia4e08633ab552b4c616c66c9b7e2bbd78ebfe7b9
Reviewed-on: https://gem5-review.googlesource.com/c/15055
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
sc_in::bind and sc_core::sc_object::print shadow their respective base
class method. This change adds the necessary declarations to inform
the compiler that this is intentional.
Change-Id: I8c6bc0f05aa568630783db63d52be90f4ea4748c
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/15135
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Boolean sc_buffers (either pure bool or sc_dt::sc_logic) should signal
positive and negative edges and resets even when their value doesn't
change, unlike sc_signals. The spec doesn't actually say that and just
mentions the value changed event, but it may have been implied that the
other types of events also happen, they just made special mention of
the value change event.
This change moves some code around a bit so that when _signalChange()
is called, if the underlying type is a boolean signal, it will
automatically notify the appropriate edge event and signal any reset.
Putting the functionality in _signalChange instead of delegating it to
the sc_buffer lets us have a single template for sc_buffer and makes
the base class template specialization handle whether the edge events
exist, and if so which should be notified.
Change-Id: Ic4ca86afc3fde6a9df5c15a0a7386e24ac89a9e2
Reviewed-on: https://gem5-review.googlesource.com/c/14916
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
ARM architectures were not covered in the endianess #if cases, which
lead the build to fail on an arm host with message:
error The file boost/detail/endian.hpp needs to be set up for your CPU
type.
Change-Id: Id012cf37810da113174a51746e290e25138739cb
Reviewed-on: https://gem5-review.googlesource.com/c/14595
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The sc_in bind function was hiding the one from sc_port by changing
the const-ness of its parameter. This change explicitly exposes the
underlying sc_port version, and keeps it alongside the new sc_in
version.
This seems mildly dangerous and undesirable because now there are two
very similar functions which would both need to be overridden in order
to get new behavior, but I don't think it's any more dangerous and
undesirable than as (perhaps unintentionally) specified in the
standard.
Change-Id: Ib42a1f8e70bc97abeeeb8d614e71c4019b3a2323
Reviewed-on: https://gem5-review.googlesource.com/c/13880
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The previous implementation dereferenced a null pointer to create a
reference which would then have its address taken in the sc_bind_proxy
constructor. clang says that that uses undefined behavior, so this
change adds a default constructor which initializes the two contained
pointers to null explicitly.
We have to hope systemc code doesn't play around with sc_bind_proxy too
much and doesn't accidentally use this constructor unintentionally, but
it seems like the least bad possible solution which makes clang happy.
Change-Id: Ic59603495fe7a406586a18ce44de979f84089bcd
Reviewed-on: https://gem5-review.googlesource.com/c/13879
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These warnings were removed when the functionality they warned about
was implemented, but there were some leftovers like unnecessary
includes and some helper functions which hid gem5 specific headers
from the ext directory.
Change-Id: Ic886ac0f1264687524e3a7b7eaab8836f318a5a2
Reviewed-on: https://gem5-review.googlesource.com/c/13398
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The scheduler is an internal detail and shouldn't be exposed to the
headers in ext. It would transitively include more headers which are
not in ext, making it not self contained.
Change-Id: I8384cde9d19363953ffd0c91e7d8d27f8f79a570
Reviewed-on: https://gem5-review.googlesource.com/c/13336
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
