* base: Generalize findLsbSet to std::bitset<N>
* base: Split builtin and fallback implementations of findLsbSet
* base: Add more unit testing for findLsbSet
Change-Id: Id75dfb7d306c9a8228fa893798b1b867137465a9
---------
Co-authored-by: Gabriel Busnot <gabriel.busnot@arteris.com>
This operator can be safely brought in scope when needed with "using
stl_helpers::operator<<".
In order to provide a specialization for operator<< with
stl_helpers-enabled types without loosing the hability to use it with
other types, a dual-dispatch mechanism is used. The only entry point
in the system is through a primary dispatch function that won't
resolve for non-helped types. Then, recursive calls go through the
secondary dispatch interface that sort between helped and non-helped
types. Helped typed will enter the system back through the primary
dispatch interface while other types will look for operator<< through
regular lookup, especially ADL.
Change-Id: I1609dd6e85e25764f393458d736ec228e025da32
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67666
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
These types include std::pair, std::tuple, all iterable types and any
composition of these. Convenience hash factory and computation
functions are also provided.
These functions are in the stl_helpers namespace and must not move to
::std which could cause undefined behaviour. This is because
specialization of std templates for std or native types (or
composition of these) is undefined behaviour. This inconvenience can't
be circumvented for generic code. Users are free to bring these hash
implementations to namespace std after specialization for their own
non-std and non-native types.
Change-Id: Ifd0f0b64e5421d5d44890eb25428cc9c53484eb3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67663
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
This change addresses an error in the compiler tests:
https://jenkins.gem5.org/job/compiler-checks/573/
For clang versions 6 through 10, as well as GCC 7,
in order to use the "filesystem" module, you must
include the experimental namespace. In all newer
versions, you can use the "filesystem" module as is.
Because of this, include guards to handle this. They include
"<experimental/filesystem>" for the older clang versions and
the "<filesystem>" for all other versions.
As opposed to checking by version, we now check if the
filesystem library has been defined before using it.
Change-Id: I8fb8d4eaa33f3edc29b7626f44b82ee66ffe72be
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69778
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Normally this would just generate a warning, but a warning is easy to
miss, and truncating the path to fit would be surprising. Since the max
length isn't likely to change, a path which has to be truncated is
essentially fundementally wrong, and could be defined as something
else which is short enough before being used in the config.
Note that this only applies to either the abstract path which is just
a string, or the file name and not the directory path on a file based
socket.
Change-Id: I8702cf02c03053b5d0b6133f25b0e588de666f15
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69677
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Earl Ou <shunhsingou@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These can either be set to an integer, in which case it's interpreted
as a TCP port, or a string, in which case it's treated as a unix domain
socket. If the unix domain socket is prefixed with a "@", it will be
treated as an abstract socket.
When stored in the ini file, there is always a prefix added to make
parsing the string more systematic and less ambiguous. A port number is
prefixed with "#", an abstract socket with "@", and a socket file with
the prefix "P" for "path".
Change-Id: I1fc7a579074e849b3becd936238c62fb0d9a2087
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69165
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
gem5 officially supports GCC 7+. In GCC 7 the "filesystem" module was
added but only in the "experimental" namespace as
"<experimental/filesystem>". In GCC 8+ the module can be found as
"<filesystem>".
Because of this, include guards to handle this. They include
"<experimental/filesystem>" for the GCC v7 case and the "<filesystem>"
for all other versions.
This bug was partially responsible for this compiler tests failures:
https://jenkins.gem5.org/job/compiler-checks/570
Note: gem5 does not support GCC versions <7. Thus the
"#if __GNUC__ >=8 <GCC 8+ code> #else <GCC 7 code> #endif" logic is
valid.
Change-Id: I31db5488f272f9652edebf24ecefca3722369076
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69598
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Create a version of listen() which handles common logic internally,
including scanning for an available port number, and notifying what
port was chosen.
The port is managed internal to ListenSocket, so that the logic
interacting with it doesn't need to manually manage a port number, and
hence a port number does not need to exist for non AF_INET sockets.
Change-Id: Ie371eccc4d0da5e7b90714508e4cb72fb0091875
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69160
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This option was almost always overridden from false to true anyway,
except in one place (in the ethertap device) which was likely just by
accident.
This will give external users a chance to remove the option without
changing behavior, so that the option can be removed entirely in a
later change.
Change-Id: I77add40b8131b91997b2aecbfff6c7de0ee9ead9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69157
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The DEBUG macro is not part of any compiler standards (differently from
NDEBUG, which elides assertions).
It is only meant to differentiate gem5.debug from .fast and .opt builds.
gem5 developers have used it to insert helper code that is supposed to
aid the debugging process in case anything goes wrong.
This generic name is likely to clash with other libraries linked with
gem5. This is the case of DRAMSim as an example.
Rather than using undef tricks, we just inject a GEM5_DEBUG macro
for gem5.debug builds.
Change-Id: Ie913ca30da615bd0075277a260bbdbc397b7ec87
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69079
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
These all look like valid (but harmless) diagnostics to me and are
all simple to fix. Most of them can be fixed by using ASSERT_* variants
of the GTest checkers to ensure that the remainder of the function is
not executed and the uninitialized result isn't touched.
Change-Id: Ib5fe2ac2ec539c880d670ebc3321ce98940c7e38
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68517
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Extensible is for carrying additional user-defined
information. Each type of the extension will have a unique
extension ID and there is a linked list of extension in every
Extensible object. There will be most one extension with the same type in
the linked list. With the shared_ptr, the extension will be
deleted automatically. That is, the caller should allocate
the extension and add into the packet.
Change-Id: I54729536a305c91c751d5fb059bd2f9a3db05523
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62892
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
In the previous version, the body of several macros was a statement
(do{...} while(0);) and not an expression. In the new version, all
macros are expressions. Expressions can be used everywhere a statement
is expected and in other locations as well.
For instance, expressions can be used with the comma operator. When
doing generic programming, the comma operator helps manipulating
parameter packs. With a statement-based implementation,
(gem5_assert(args > 0), ...) could not be written while perfectly
sound.
Also, (c1 ? a : c2 ? b : (gem5_assert(c3), c)) is a usefull
expression to assert completeness of cascaded conditions that cannot
be easily and efficiently achieved without an expression kind of
assertion.
Change-Id: Ia0efeb15e6deda6b90529a6f0e00ebe2e9b5d2a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67336
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
safe_cast now supports the exact same types as dynamic_cast would. In
particular, it now supports l-value references and rejects r-value
references.
The non-debug version has also been updated to make it build only in
the same cases as the debug version of safe_cast would.
Change-Id: I86692561c169b1ad063000c990a52ea80c6637ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67453
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
