Now that we're using c++17, the type_traits with a ::value member have
a _v alias which reduces verbosity. Or on other words
std::is_integral<T>::value
can be replaced with
std::is_integral_v<T>
Make this substitution throughout the code base. In places where gem5
introduced it's own similar templates, add a V alias, spelled
differently to match gem5's internal style.
gem5: :IsVarArgs<T>::value => gem5::IsVarArgsV<T>
Change-Id: I1d84ffc4a236ad699471569e7916ec17fe5f109a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/48604
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.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 operators it seems to need are ones which modify the BitUnion being
operated on, vs ones which just use it to produce a new value. The later
kind can be handled by converting the BitUnion into its underlying type
and then applying the built in operators.
Change-Id: I8aa08bf74d8ad88f4dfbb0031610c52ad412d03b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41515
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
GCC 8 adds a number of new warnings to -Wall which generate errors.
- Fix memset to 0 for structs by adding casts.
- Fix cast with const when the const was ignored.
- Fix catch a polymorphic type by value
We now compile with GCC 8!
Change-Id: Iab70ce11190eee67608fc25c0bedff170152b153
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/11949
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The specializations need to be online only and not static, but the
template itself is static and inline.
Originally they were in an anonymous namespace, but that causes
warnings when building on clang or with certain versions of gcc because
the functions may not be used in every .cc.
Change-Id: Iff127337f7bf0c18755de07a49d6e7a9ce6f2f0a
Reviewed-on: https://gem5-review.googlesource.com/9581
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This way printing bitunions with, for instance, DPRINTF actually prints
something useful. More specialized overloads will still allow printing
particular bitunion types in ways that might make more sense for that
particular type.
Change-Id: I92beb0ce07683ba8b318cf25aa73e0057e4a60ef
Reviewed-on: https://gem5-review.googlesource.com/9461
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
<iostream> isn't actually used anywhere in bitunion.hh. The templated
hash struct type is defined in <functional> and should be included
explicitly.
Change-Id: I8691ccb2f9e28a01610ae8bb4d9591b07cb7320b
Reviewed-on: https://gem5-review.googlesource.com/7781
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Maintainer: Gabe Black <gabeblack@google.com>
clang was getting very upset and interpretting a member function
pointer as a call to the actual underlying function, and then
complaining that it was a non-static function call without an instance.
It seems what it was really upset about was that the class who's scope
the member function pointer belonged to (the current class) wasn't done
being defined. This *should* be ok as far as I can tell, but clang was
having none of it.
This change reworks how the type of the setter function arguments are
determined to work around that limitation. The bitunion test was run
with clang++ and g++ and both pass, and I've built gem5.opt for ARM
successfully.
Change-Id: Ib9351784a897af4867fe08045577e0247334ea11
Reviewed-on: https://gem5-review.googlesource.com/7581
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
The ARM types.hh file defined an STL style hash structure to operate
on the ExtMachInst, but it referred to the underlying storage type
using internal typedefs in the BitUnion types. To avoid having to do
that, this change adds a hash structure to bitunion.hh which will work
on any BitUnion, and gets rid of the ARM ExtMachInst version.
Change-Id: I7c1c84d61b59061fec98abaaeab6becd06537dee
Reviewed-on: https://gem5-review.googlesource.com/7204
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
They are now oriented around a class which makes it easy to provide
custom setter/getter functions which let you set or read bits in an
arbitrary way.
Future additions may add the ability to add custom bitfield methods,
and index-able bitfields.
Change-Id: Ibd6d4d9e49107490f6dad30a4379a8c93bda9333
Reviewed-on: https://gem5-review.googlesource.com/7201
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Used cppclean to help identify useless includes and removed them. This
involved erroneously included headers, but also cases where forward
declarations could have been used rather than a full include.
If two bitfields are of the same type, also implying that they have the same
first and last bit positions, the existing implementation would copy the
entire bitfield. That includes the __data member which is shared among all the
bitfields, effectively overwritting the entire bitunion.
This change also adjusts the write only signed bitfield assignment operator to
be like the unsigned version, using "using" instead of implementing it again
and calling down to the underlying implementation.
If a bit field in a bit union specified as Bitfield<LSB, MSB> instead
of Bitfield<MSB, LSB> the code silently fails and the field is read as
zero. This changeset introduces a static assert that tests, at compile
time, that the bit order is correct.
Previously, the bitunion would need to be declared and then assigned to separately.
--HG--
extra : convert_revision : d229bd83bc7baeca2259d4e7b080f359915015f3
