[gem5-dev] Re: A few quick thoughts

[Gabe Black via gem5-dev]

Well, I *think* having not extensively surveyed the code, that the vast
majority of the time the bits that are being extracted are constant, so the
templated form would be the default, and you'd just need to use the current
form in the few cases where it's not fixed. As somebody suggested, we could
use a macro to make it look a little more uniform and keep the arguments in
the same order. Perhaps:

#define bits(val, first, last) _bits_template(val)

and call the full flexibility function bitsv (for variable). Most of the
time you'd use the normal version, except when it yells at you and forces
you to use bitsv.

This is not ideal in I think three ways.
1. Macros are not namespaced. MyFavoritClass::bits would be problematic but
is totally fine today.
2. Slightly more complexity than today. The complexity is *mostly*
obscured, which can be a good or bad thing depending on circumstances.
3. If somebody does copy paste coding and doesn't know *why* something is
bitsv vs bits, they're more likely to use the wrong one than if they were
starting from scratch.

Importantly, if somebody *does* use the wrong thing, the only way they
could do that would be to use the variable form unnecessarily. The other
way around would definitely be a compiler error. If they do that, then we
would be no worse off than we are today, we would just lose a little bit of
the error checking which we have none of now.

I don't think this is a slam dunk obvious right thing to do, but I think it
has some merits and is worth considering. If in the future somebody does
either figure out some crazy clever way to do this without the templates,
or the standard evolves to the point where we can use something more
elegant, then it should be relatively easy to move to that instead.

Gabe

On Fri, Sep 18, 2020 at 8:35 AM Jason Lowe-Power 
wrote:

> Sorry for the spam...
>
> One last thing: We have to keep both bits(val, first, last) *and*
> bits(val) because sometimes first and last are *not*
> constexpr. If they were *always* constexpr, this would be much simpler (I
> think).
>
> Cheers,
> Jason
>
> On Fri, Sep 18, 2020 at 8:33 AM Jason Lowe-Power 
> wrote:
>
>> I don't like the following change
>>
>> bits(val, first, last)
>>
>> would now be
>>
>> bits(val).
>>
>> IMO, it's confusing to put function *parameters* as template arguments.
>>
>> This would mean that when you use the bits() function, you'll have to
>> think about "are these constexpr that I'm using, and, if so, should I use
>> bits() or bits<>()?"
>>
>> We can go through and manually change the current code, but for new code,
>> this will be yet another thing that we'd have to catch during code review.
>>
>> Just my two cents. I won't block anything, I just think that readability
>> is more important than a little* performance.
>>
>> *It depends on how much performance difference assert() vs
>> static_assert() is in this case.
>>
>> Cheers,
>> Jason
>>
>> On Fri, Sep 18, 2020 at 8:29 AM Gutierrez, Anthony <
>> anthony.gutier...@amd.com> wrote:
>>
>>> [AMD Public Use]
>>>
>>>
>>>
>>> Hey, Jason perhaps you mentioned this somewhere but what is the reason
>>> for such a strong aversion to the template approach? It seems to solve the
>>> issue nicely with what seems to be a minor change in syntax. gem5 is C++,
>>> so we should allow users to write C++.
>>>
>>>
>>>
>>> Tony
>>>
>>>
>>>
>>> *From:* Jason Lowe-Power via gem5-dev 
>>> *Sent:* Friday, September 18, 2020 8:05 AM
>>> *To:* Gabe Black 
>>> *Cc:* gem5 Developer List ; Jason Lowe-Power <
>>> ja...@lowepower.com>
>>> *Subject:* [gem5-dev] Re: A few quick thoughts
>>>
>>>
>>>
>>> [CAUTION: External Email]
>>>
>>> There is another option to keep the function-like syntax, but get the
>>> constexpr via templates: A preprocessor macro:
>>>
>>>
>>>
>>> #define bits(val, first, last) bits(val)
>>>
>>>
>>>
>>> The major downside is that we can't overload preprocessor macros. We'd
>>> have to have two name bits_const() and bits(), which I also don't like.
>>>
>>>
>>>
>>> Personally, I strongly don't want to lose the function-like syntax for
>>> the bits function. I won't *block* the change, but I'll push back against
>>> the template syntax.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Jason
>>>
>>>
>>>
>>> On Fri, Sep 18, 2020 at 5:02 AM Gabe Black  wrote:
>>>
>>> I spent some more time digging into 2, and while I didn't find anything
>>> that directly stated that you aren't allowed to do that, without explicit
>>> support I think it flies in the face of how C++ templates, types, etc. work
>>> to the point where if you *did* find a way to do it, it would almost
>>> certainly be a bug or an oversight in the standard somewhere. So unless
>>> they do adopt one of those standards I saw proposed and we wait a good
>>> number of years for it to be implemented in all the compilers we support
>>> (one said it targeted C++23) I think templates, while slightly gross, are
>>> really the only way to make it work.
>>>
>>>
>>>
>>> Gabe
>>>
>>>
>>>
>>> On Thu, Sep 17, 

[gem5-dev] Re: Build failed in Jenkins: Compiler-Checks #23

[Bobby Bruce via gem5-dev]

It seems like the compiler tests started running on develop just before I
merged all the fixes from the staging branch. I'm going to kick start the
compiler tests again to ensure these tests pass.
--
Dr. Bobby R. Bruce
Room 2235,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Sep 17, 2020 at 9:35 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/Compiler-Checks/23/display/redirect?page=changes
> >
>
> Changes:
>
> [Jason Lowe-Power] cpu-minor: convert fetch2 to new style stats
>
> [gabeblack] arch: Add a virtual destructor to BaseHTMCheckpoint.
>
> [gabeblack] cpu: Fix style and add overrides to bas_dyn_inst.hh.
>
> [gabeblack] mem: Remove the unused nvm private member from
> NVMInterface::Rank.
>
> [Andreas.Sandberg] sim: Expose the system's byte order as a param
>
> [Jason Lowe-Power] cpu-o3: convert commit to new style stats
>
> [Jason Lowe-Power] cpu-o3: convert decode to new style stats
>
> [Jason Lowe-Power] cpu-o3: convert lsq_unit to new style stats
>
> [Jason Lowe-Power] cpu-o3: convert rob to new style stats
>
> [Jason Lowe-Power] cpu-o3: convert rename to new style stats
>
> [giacomo.travaglini] arch-arm: Fix ArmISA namespace requirement for TME
> instructions
>
> [Bobby R. Bruce] arch-mips: Replaced `BigEndianByteOrder` in MIPS
>
> [gabeblack] fastmodel: Create a fake "Interrupts" object for fast model
> CPUs.
>
> [gabeblack] fastmodel: Add an ISA class which defers to IRIS.
>
> [Andreas.Sandberg] dev: Use the new ByteOrder param type in SimpleUart
>
> [Andreas.Sandberg] dev: Use the new ByteOrder param type in VirtIO devices
>
> [Bobby R. Bruce] arch-arm: Fix build errors with gcc 10.2
>
> [Bobby R. Bruce] arch-arm: just return the fault in twoEqualRegInst{,Fp}
>
> [Bobby R. Bruce] cpu: Fixed unused var error when with fast builds
>
> [Bobby R. Bruce] tests: cross-compiling hello binaries for hello_se tests.
>
> [Jason Lowe-Power] configs,python: Fixes an issue with python3 and the
> config scripts when restoring a checkpoint
>
> [shparekh] misc: Replaced master/slave terminology
>
> [srikant.bharadwaj] mem-garnet: Fix default value of network bridge
>
> [srikant.bharadwaj] mem-garnet: Allow empty vnet list for garnet network
> links
>
> [Bobby R. Bruce] tests: Update x86 system.py for MemCtrl interface
>
> [Bobby R. Bruce] arch-arm: Initialize some cases of destReg
>
> [Bobby R. Bruce] mem-garnet: Upgrade garnet version to 3.0
>
> [Bobby R. Bruce] misc: Update documentation of SimObject related APIs
>
> [giacomo.travaglini] arch-arm: Fix ArmISA namespace requirement for Arm KVM
>
> [Andreas.Sandberg] base, sim, mem, arch: Remove the dummy CPU in NULL
>
> [Andreas.Sandberg] stats: Move global CPU stats to BaseCPU
>
> [Jason Lowe-Power] dev: Fix port name in x86 device
>
> [Jason Lowe-Power] tests: Remove MIPS from Learning gem5 tests
>
> [Jason Lowe-Power] mem-ruby: Update port names in Ruby
>
> [gabeblack] sparc,sim: Remove special handling of SPARC in the clone
> system call.
>
> [gabeblack] mips,cpu: Get rid of the IsCondDelaySlot StaticInst flag.
>
> [gabeblack] cpu: Get rid of the IsThreadSync StaticInst flag.
>
> [gabeblack] mips,cpu: Get rid of the IsERET StaticInst flag.
>
> [gabeblack] mips,cpu: Get rid of the IsIprAccess StaticInst flag.
>
> [shunhsingou] systemc: avoid dynamic_cast in the critical path
>
> [Bobby R. Bruce] cpu,misc: Revert problematic terminology renames in
> BaseCPU
>
> [gabeblack] mips,cpu: Get rid of the IsDpsOp StaticInst flag.
>
> [gabeblack] x86,cpu: Get rid of the unused IsCC StaticInst flag.
>
> [gabeblack] cpu: Get rid of the unused IsMicroBranch StaticInst flag.
>
> [gabeblack] mem: Remove #if THE_ISA in the AbstractMemory class.
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> The recommended git tool is: git
> No credentials specified
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
> Checking out Revision b1c70250c4fc111b78b30266cf290a1d3c5bfb0a
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f b1c70250c4fc111b78b30266cf290a1d3c5bfb0a # timeout=10
> Commit message: "mem: Remove #if THE_ISA in the AbstractMemory class."
>  > git rev-list --no-walk dba46233950817b4c696781bc3c1891a5b499651 #
> timeout=10
> [Compiler-Checks] $ /bin/sh 

[gem5-dev] Re: A few quick thoughts

[Jason Lowe-Power via gem5-dev]

Sorry for the spam...

One last thing: We have to keep both bits(val, first, last) *and*
bits(val) because sometimes first and last are *not*
constexpr. If they were *always* constexpr, this would be much simpler (I
think).

Cheers,
Jason

On Fri, Sep 18, 2020 at 8:33 AM Jason Lowe-Power 
wrote:

> I don't like the following change
>
> bits(val, first, last)
>
> would now be
>
> bits(val).
>
> IMO, it's confusing to put function *parameters* as template arguments.
>
> This would mean that when you use the bits() function, you'll have to
> think about "are these constexpr that I'm using, and, if so, should I use
> bits() or bits<>()?"
>
> We can go through and manually change the current code, but for new code,
> this will be yet another thing that we'd have to catch during code review.
>
> Just my two cents. I won't block anything, I just think that readability
> is more important than a little* performance.
>
> *It depends on how much performance difference assert() vs static_assert()
> is in this case.
>
> Cheers,
> Jason
>
> On Fri, Sep 18, 2020 at 8:29 AM Gutierrez, Anthony <
> anthony.gutier...@amd.com> wrote:
>
>> [AMD Public Use]
>>
>>
>>
>> Hey, Jason perhaps you mentioned this somewhere but what is the reason
>> for such a strong aversion to the template approach? It seems to solve the
>> issue nicely with what seems to be a minor change in syntax. gem5 is C++,
>> so we should allow users to write C++.
>>
>>
>>
>> Tony
>>
>>
>>
>> *From:* Jason Lowe-Power via gem5-dev 
>> *Sent:* Friday, September 18, 2020 8:05 AM
>> *To:* Gabe Black 
>> *Cc:* gem5 Developer List ; Jason Lowe-Power <
>> ja...@lowepower.com>
>> *Subject:* [gem5-dev] Re: A few quick thoughts
>>
>>
>>
>> [CAUTION: External Email]
>>
>> There is another option to keep the function-like syntax, but get the
>> constexpr via templates: A preprocessor macro:
>>
>>
>>
>> #define bits(val, first, last) bits(val)
>>
>>
>>
>> The major downside is that we can't overload preprocessor macros. We'd
>> have to have two name bits_const() and bits(), which I also don't like.
>>
>>
>>
>> Personally, I strongly don't want to lose the function-like syntax for
>> the bits function. I won't *block* the change, but I'll push back against
>> the template syntax.
>>
>>
>>
>> Cheers,
>>
>> Jason
>>
>>
>>
>> On Fri, Sep 18, 2020 at 5:02 AM Gabe Black  wrote:
>>
>> I spent some more time digging into 2, and while I didn't find anything
>> that directly stated that you aren't allowed to do that, without explicit
>> support I think it flies in the face of how C++ templates, types, etc. work
>> to the point where if you *did* find a way to do it, it would almost
>> certainly be a bug or an oversight in the standard somewhere. So unless
>> they do adopt one of those standards I saw proposed and we wait a good
>> number of years for it to be implemented in all the compilers we support
>> (one said it targeted C++23) I think templates, while slightly gross, are
>> really the only way to make it work.
>>
>>
>>
>> Gabe
>>
>>
>>
>> On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
>> wrote:
>>
>>
>>
>>
>>
>> On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> 1. Sounds good, I'll hopefully have some time to put together a CL in no
>> too long (weekend?).
>>
>>
>>
>> 2. I 5ries to figure out a way to do it without the template that wasn't
>> really gross a somewhat fragile and wasn't able to, but that would
>> definitely be preferable. I'll keep thinking about it, but the internet
>> didn't seem to have any ideas either. Unfortunately using constexpr won't
>> work like that Jason, although I wish it did and found a couple unadopted
>> (as far as I know) standards proposals to that effect.
>>
>>
>>
>> Yeah, that's what I found, too :).
>>
>>
>>
>>
>>
>> 3. Sounds good. Likely this weekend?
>>
>>
>>
>> Gabe
>>
>>
>>
>> On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev 
>> wrote:
>>
>> 1) Seems fine to me.
>>
>>
>>
>> 2) I remember looking into this and I agree with Jason, it involves
>> template magic which I'm not a huge fan of. I feel like in order to add
>> these compile time asserts we'd be sacrificing some
>> readability/ease-of-usability of bitfields.hh. This may just be a "me
>> thing", but something about templates confuse me whenever I need to deal
>> with them.
>>
>>
>>
>> 3) In truth, our minimum supported Clang version is 3.9 in practise (We
>> even state on our website's building documentation that we support Clang
>> 3.9 to 9: http://www.gem5.org/documentation/general_docs/building
>> ).
>> I didn't realize we still have "3.1" hardcoded in the SConscript and would
>> be happy for this to be bumped up to 3.9. 

[gem5-dev] Re: A few quick thoughts

[Jason Lowe-Power via gem5-dev]

I don't like the following change

bits(val, first, last)

would now be

bits(val).

IMO, it's confusing to put function *parameters* as template arguments.

This would mean that when you use the bits() function, you'll have to think
about "are these constexpr that I'm using, and, if so, should I use bits()
or bits<>()?"

We can go through and manually change the current code, but for new code,
this will be yet another thing that we'd have to catch during code review.

Just my two cents. I won't block anything, I just think that readability is
more important than a little* performance.

*It depends on how much performance difference assert() vs static_assert()
is in this case.

Cheers,
Jason

On Fri, Sep 18, 2020 at 8:29 AM Gutierrez, Anthony <
anthony.gutier...@amd.com> wrote:

> [AMD Public Use]
>
>
>
> Hey, Jason perhaps you mentioned this somewhere but what is the reason for
> such a strong aversion to the template approach? It seems to solve the
> issue nicely with what seems to be a minor change in syntax. gem5 is C++,
> so we should allow users to write C++.
>
>
>
> Tony
>
>
>
> *From:* Jason Lowe-Power via gem5-dev 
> *Sent:* Friday, September 18, 2020 8:05 AM
> *To:* Gabe Black 
> *Cc:* gem5 Developer List ; Jason Lowe-Power <
> ja...@lowepower.com>
> *Subject:* [gem5-dev] Re: A few quick thoughts
>
>
>
> [CAUTION: External Email]
>
> There is another option to keep the function-like syntax, but get the
> constexpr via templates: A preprocessor macro:
>
>
>
> #define bits(val, first, last) bits(val)
>
>
>
> The major downside is that we can't overload preprocessor macros. We'd
> have to have two name bits_const() and bits(), which I also don't like.
>
>
>
> Personally, I strongly don't want to lose the function-like syntax for the
> bits function. I won't *block* the change, but I'll push back against the
> template syntax.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Fri, Sep 18, 2020 at 5:02 AM Gabe Black  wrote:
>
> I spent some more time digging into 2, and while I didn't find anything
> that directly stated that you aren't allowed to do that, without explicit
> support I think it flies in the face of how C++ templates, types, etc. work
> to the point where if you *did* find a way to do it, it would almost
> certainly be a bug or an oversight in the standard somewhere. So unless
> they do adopt one of those standards I saw proposed and we wait a good
> number of years for it to be implemented in all the compilers we support
> (one said it targeted C++23) I think templates, while slightly gross, are
> really the only way to make it work.
>
>
>
> Gabe
>
>
>
> On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
> wrote:
>
>
>
>
>
> On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev 
> wrote:
>
> 1. Sounds good, I'll hopefully have some time to put together a CL in no
> too long (weekend?).
>
>
>
> 2. I 5ries to figure out a way to do it without the template that wasn't
> really gross a somewhat fragile and wasn't able to, but that would
> definitely be preferable. I'll keep thinking about it, but the internet
> didn't seem to have any ideas either. Unfortunately using constexpr won't
> work like that Jason, although I wish it did and found a couple unadopted
> (as far as I know) standards proposals to that effect.
>
>
>
> Yeah, that's what I found, too :).
>
>
>
>
>
> 3. Sounds good. Likely this weekend?
>
>
>
> Gabe
>
>
>
> On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev 
> wrote:
>
> 1) Seems fine to me.
>
>
>
> 2) I remember looking into this and I agree with Jason, it involves
> template magic which I'm not a huge fan of. I feel like in order to add
> these compile time asserts we'd be sacrificing some
> readability/ease-of-usability of bitfields.hh. This may just be a "me
> thing", but something about templates confuse me whenever I need to deal
> with them.
>
>
>
> 3) In truth, our minimum supported Clang version is 3.9 in practise (We
> even state on our website's building documentation that we support Clang
> 3.9 to 9: http://www.gem5.org/documentation/general_docs/building
> ).
> I didn't realize we still have "3.1" hardcoded in the SConscript and would
> be happy for this to be bumped up to 3.9. Our compiler tests do not test
> with versions of clang before 3.9, so, at present, we aren't doing much to
> help those using versions older than 3.9. I'd love to bump up to c++14
> also. While I'm sure there are plenty of good reasons, I personally would
> like to use C++14's deprecation attribute for if/when we start deprecating
> gem5 C++ APIs:
> https://en.cppreference.com/w/cpp/language/attributes/deprecated
> 

[gem5-dev] Re: A few quick thoughts

[Gutierrez, Anthony via gem5-dev]

[AMD Public Use]

Hey, Jason perhaps you mentioned this somewhere but what is the reason for such 
a strong aversion to the template approach? It seems to solve the issue nicely 
with what seems to be a minor change in syntax. gem5 is C++, so we should allow 
users to write C++.

Tony

From: Jason Lowe-Power via gem5-dev 
Sent: Friday, September 18, 2020 8:05 AM
To: Gabe Black 
Cc: gem5 Developer List ; Jason Lowe-Power 

Subject: [gem5-dev] Re: A few quick thoughts

[CAUTION: External Email]
There is another option to keep the function-like syntax, but get the constexpr 
via templates: A preprocessor macro:

#define bits(val, first, last) bits(val)

The major downside is that we can't overload preprocessor macros. We'd have to 
have two name bits_const() and bits(), which I also don't like.

Personally, I strongly don't want to lose the function-like syntax for the bits 
function. I won't *block* the change, but I'll push back against the template 
syntax.

Cheers,
Jason

On Fri, Sep 18, 2020 at 5:02 AM Gabe Black 
mailto:gabebl...@google.com>> wrote:
I spent some more time digging into 2, and while I didn't find anything that 
directly stated that you aren't allowed to do that, without explicit support I 
think it flies in the face of how C++ templates, types, etc. work to the point 
where if you *did* find a way to do it, it would almost certainly be a bug or 
an oversight in the standard somewhere. So unless they do adopt one of those 
standards I saw proposed and we wait a good number of years for it to be 
implemented in all the compilers we support (one said it targeted C++23) I 
think templates, while slightly gross, are really the only way to make it work.

Gabe

On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
mailto:ja...@lowepower.com>> wrote:


On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
1. Sounds good, I'll hopefully have some time to put together a CL in no too 
long (weekend?).

2. I 5ries to figure out a way to do it without the template that wasn't really 
gross a somewhat fragile and wasn't able to, but that would definitely be 
preferable. I'll keep thinking about it, but the internet didn't seem to have 
any ideas either. Unfortunately using constexpr won't work like that Jason, 
although I wish it did and found a couple unadopted (as far as I know) 
standards proposals to that effect.

Yeah, that's what I found, too :).


3. Sounds good. Likely this weekend?

Gabe

On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:
1) Seems fine to me.

2) I remember looking into this and I agree with Jason, it involves template 
magic which I'm not a huge fan of. I feel like in order to add these compile 
time asserts we'd be sacrificing some readability/ease-of-usability of 
bitfields.hh. This may just be a "me thing", but something about templates 
confuse me whenever I need to deal with them.

3) In truth, our minimum supported Clang version is 3.9 in practise (We even 
state on our website's building documentation that we support Clang 3.9 to 9: 
http://www.gem5.org/documentation/general_docs/building).
 I didn't realize we still have "3.1" hardcoded in the SConscript and would be 
happy for this to be bumped up to 3.9. Our compiler tests do not test with 
versions of clang before 3.9, so, at present, we aren't doing much to help 
those using versions older than 3.9. I'd love to bump up to c++14 also. While 
I'm sure there are plenty of good reasons, I personally would like to use 
C++14's deprecation attribute for if/when we start deprecating gem5 C++ APIs: 
https://en.cppreference.com/w/cpp/language/attributes/deprecated

We already do use the deprecated attribute (see 
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#55).

We should be able to get rid of this: 

[gem5-dev] Re: A few quick thoughts

[Jason Lowe-Power via gem5-dev]

There is another option to keep the function-like syntax, but get the
constexpr via templates: A preprocessor macro:

#define bits(val, first, last) bits(val)

The major downside is that we can't overload preprocessor macros. We'd have
to have two name bits_const() and bits(), which I also don't like.

Personally, I strongly don't want to lose the function-like syntax for the
bits function. I won't *block* the change, but I'll push back against the
template syntax.

Cheers,
Jason

On Fri, Sep 18, 2020 at 5:02 AM Gabe Black  wrote:

> I spent some more time digging into 2, and while I didn't find anything
> that directly stated that you aren't allowed to do that, without explicit
> support I think it flies in the face of how C++ templates, types, etc. work
> to the point where if you *did* find a way to do it, it would almost
> certainly be a bug or an oversight in the standard somewhere. So unless
> they do adopt one of those standards I saw proposed and we wait a good
> number of years for it to be implemented in all the compilers we support
> (one said it targeted C++23) I think templates, while slightly gross, are
> really the only way to make it work.
>
> Gabe
>
> On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
> wrote:
>
>>
>>
>> On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> 1. Sounds good, I'll hopefully have some time to put together a CL in no
>>> too long (weekend?).
>>>
>>> 2. I 5ries to figure out a way to do it without the template that wasn't
>>> really gross a somewhat fragile and wasn't able to, but that would
>>> definitely be preferable. I'll keep thinking about it, but the internet
>>> didn't seem to have any ideas either. Unfortunately using constexpr won't
>>> work like that Jason, although I wish it did and found a couple unadopted
>>> (as far as I know) standards proposals to that effect.
>>>
>>
>> Yeah, that's what I found, too :).
>>
>>
>>>
>>> 3. Sounds good. Likely this weekend?
>>>
>>> Gabe
>>>
>>> On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 1) Seems fine to me.

 2) I remember looking into this and I agree with Jason, it involves
 template magic which I'm not a huge fan of. I feel like in order to add
 these compile time asserts we'd be sacrificing some
 readability/ease-of-usability of bitfields.hh. This may just be a "me
 thing", but something about templates confuse me whenever I need to deal
 with them.

 3) In truth, our minimum supported Clang version is 3.9 in practise (We
 even state on our website's building documentation that we support Clang
 3.9 to 9: http://www.gem5.org/documentation/general_docs/building). I
 didn't realize we still have "3.1" hardcoded in the SConscript and would be
 happy for this to be bumped up to 3.9. Our compiler tests do not test with
 versions of clang before 3.9, so, at present, we aren't doing much to help
 those using versions older than 3.9. I'd love to bump up to c++14 also.
 While I'm sure there are plenty of good reasons, I personally would like to
 use C++14's deprecation attribute for if/when we start deprecating gem5 C++
 APIs: https://en.cppreference.com/w/cpp/language/attributes/deprecated

>>>
>> We already do use the deprecated attribute (see
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#55
>> ).
>>
>> We should be able to get rid of this:
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#93
>> And maybe this:
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#69
>>
>>
>>>
 --
 Dr. Bobby R. Bruce
 Room 2235,
 Kemper Hall, UC Davis
 Davis,
 CA, 95616

 web: https://www.bobbybruce.net


 On Thu, Sep 17, 2020 at 8:25 AM Jason Lowe-Power via gem5-dev <
 gem5-dev@gem5.org> wrote:

> Hey Gabe,
>
> On Thu, Sep 17, 2020 at 4:46 AM Gabe Black via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> 1. Use __builtin_expect() for panic, fatal, etc. Preexisting library
>> functions like assert probably already have this, but our versions don't
>> and have similar behavior patterns. This should improve performance.
>>
>
> Seems like a good idea. It shouldn't hurt anything.
>
>
>>
>> 2. Create template versions of the bits, etc functions in
>> bitfields.hh which use static_assert to verify that the bounds are in the
>> right order. Unless the bounds change at runtime (probably very uncommon 
>> in
>> practice)
>>
>
> I like the idea of static asserts, but don't like the change in the
> syntax away from a simple function call.
>
> Would it be possible to instead use a constexpr function parameter?
>
> What we would really like is
>
> template 
> inline
> T
> bits(T val, *constexpr *int 

[gem5-dev] Change in gem5/gem5[develop]: gpu: Stop using TheISA in the GPU TLB.

[Gabe Black (Gerrit) via gem5-dev]

Gabe Black has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34173 )


Change subject: gpu: Stop using TheISA in the GPU TLB.
..

gpu: Stop using TheISA in the GPU TLB.

This class is defined inside the X86ISA namespace, so there's no point
in pretending it's generic. Remove TheISA and let the code access what
it needs from X86ISA naturally since it's there already.

Change-Id: I21b5d2d2b9af6aa0c10ddbb5b3ddca1692188dcc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34173
Tested-by: kokoro 
Reviewed-by: Matthew Poremba 
Reviewed-by: Matt Sinclair 
Maintainer: Matt Sinclair 
---
M src/gpu-compute/gpu_tlb.cc
1 file changed, 4 insertions(+), 4 deletions(-)

Approvals:
  Matthew Poremba: Looks good to me, approved
  Matt Sinclair: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/gpu-compute/gpu_tlb.cc b/src/gpu-compute/gpu_tlb.cc
index 4c35396..54c3729 100644
--- a/src/gpu-compute/gpu_tlb.cc
+++ b/src/gpu-compute/gpu_tlb.cc
@@ -164,7 +164,7 @@
  * vpn holds the virtual page address
  * The least significant bits are simply masked
  */
-int set = (vpn >> TheISA::PageShift) & setMask;
+int set = (vpn >> PageShift) & setMask;

 if (!freeList[set].empty()) {
 newEntry = freeList[set].front();
@@ -184,7 +184,7 @@
 GpuTLB::EntryList::iterator
 GpuTLB::lookupIt(Addr va, bool update_lru)
 {
-int set = (va >> TheISA::PageShift) & setMask;
+int set = (va >> PageShift) & setMask;

 if (FA) {
 assert(!set);
@@ -214,7 +214,7 @@
 TlbEntry*
 GpuTLB::lookup(Addr va, bool update_lru)
 {
-int set = (va >> TheISA::PageShift) & setMask;
+int set = (va >> PageShift) & setMask;

 auto entry = lookupIt(va, update_lru);

@@ -266,7 +266,7 @@
 GpuTLB::demapPage(Addr va, uint64_t asn)
 {

-int set = (va >> TheISA::PageShift) & setMask;
+int set = (va >> PageShift) & setMask;
 auto entry = lookupIt(va, false);

 if (entry != entryList[set].end()) {

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34173
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I21b5d2d2b9af6aa0c10ddbb5b3ddca1692188dcc
Gerrit-Change-Number: 34173
Gerrit-PatchSet: 3
Gerrit-Owner: Gabe Black 
Gerrit-Reviewer: Anthony Gutierrez 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Matt Sinclair 
Gerrit-Reviewer: Matthew Poremba 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: A few quick thoughts

[Gabe Black via gem5-dev]

I spent some more time digging into 2, and while I didn't find anything
that directly stated that you aren't allowed to do that, without explicit
support I think it flies in the face of how C++ templates, types, etc. work
to the point where if you *did* find a way to do it, it would almost
certainly be a bug or an oversight in the standard somewhere. So unless
they do adopt one of those standards I saw proposed and we wait a good
number of years for it to be implemented in all the compilers we support
(one said it targeted C++23) I think templates, while slightly gross, are
really the only way to make it work.

Gabe

On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
wrote:

>
>
> On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev 
> wrote:
>
>> 1. Sounds good, I'll hopefully have some time to put together a CL in no
>> too long (weekend?).
>>
>> 2. I 5ries to figure out a way to do it without the template that wasn't
>> really gross a somewhat fragile and wasn't able to, but that would
>> definitely be preferable. I'll keep thinking about it, but the internet
>> didn't seem to have any ideas either. Unfortunately using constexpr won't
>> work like that Jason, although I wish it did and found a couple unadopted
>> (as far as I know) standards proposals to that effect.
>>
>
> Yeah, that's what I found, too :).
>
>
>>
>> 3. Sounds good. Likely this weekend?
>>
>> Gabe
>>
>> On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev 
>> wrote:
>>
>>> 1) Seems fine to me.
>>>
>>> 2) I remember looking into this and I agree with Jason, it involves
>>> template magic which I'm not a huge fan of. I feel like in order to add
>>> these compile time asserts we'd be sacrificing some
>>> readability/ease-of-usability of bitfields.hh. This may just be a "me
>>> thing", but something about templates confuse me whenever I need to deal
>>> with them.
>>>
>>> 3) In truth, our minimum supported Clang version is 3.9 in practise (We
>>> even state on our website's building documentation that we support Clang
>>> 3.9 to 9: http://www.gem5.org/documentation/general_docs/building). I
>>> didn't realize we still have "3.1" hardcoded in the SConscript and would be
>>> happy for this to be bumped up to 3.9. Our compiler tests do not test with
>>> versions of clang before 3.9, so, at present, we aren't doing much to help
>>> those using versions older than 3.9. I'd love to bump up to c++14 also.
>>> While I'm sure there are plenty of good reasons, I personally would like to
>>> use C++14's deprecation attribute for if/when we start deprecating gem5 C++
>>> APIs: https://en.cppreference.com/w/cpp/language/attributes/deprecated
>>>
>>
> We already do use the deprecated attribute (see
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#55
> ).
>
> We should be able to get rid of this:
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#93
> And maybe this:
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#69
>
>
>>
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 2235,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Thu, Sep 17, 2020 at 8:25 AM Jason Lowe-Power via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 Hey Gabe,

 On Thu, Sep 17, 2020 at 4:46 AM Gabe Black via gem5-dev <
 gem5-dev@gem5.org> wrote:

> 1. Use __builtin_expect() for panic, fatal, etc. Preexisting library
> functions like assert probably already have this, but our versions don't
> and have similar behavior patterns. This should improve performance.
>

 Seems like a good idea. It shouldn't hurt anything.


>
> 2. Create template versions of the bits, etc functions in bitfields.hh
> which use static_assert to verify that the bounds are in the right order.
> Unless the bounds change at runtime (probably very uncommon in practice)
>

 I like the idea of static asserts, but don't like the change in the
 syntax away from a simple function call.

 Would it be possible to instead use a constexpr function parameter?

 What we would really like is

 template 
 inline
 T
 bits(T val, *constexpr *int first, *constexpr *int last)
 {
 int nbits = first - last + 1;
 *static*_assert((first - last) >= 0);
 return (val >> last) & mask(nbits);
 }

 However, after spending 15-30 minutes researching it doesn't seem like
 this is easy to do today. Gabe... you seem to know much more template
 magic. Maybe there's a way?


> bits(foo, 2, 1) => bits<2, 1>(foo)
>
> Then we get the free compile time checking of bounds most of the time
> without big overhead otherwise. Something like this:
>
> template 
> constexpr T
> bits(T val)
> {
> static_assert(first > last);
> return bits(val, first, last);
> }
>
> 

[gem5-dev] Change in gem5/gem5[develop]: arch-arm: TLBI ALLE2IS should broadcast to the IS domain

[Giacomo Travaglini (Gerrit) via gem5-dev]

Hello Nikos Nikoleris,

I'd like you to do a code review. Please visit

https://gem5-review.googlesource.com/c/public/gem5/+/34795

to review the following change.


Change subject: arch-arm: TLBI ALLE2IS should broadcast to the IS domain
..

arch-arm: TLBI ALLE2IS should broadcast to the IS domain

This was implemented as a normal ALLE2 hence affecting the
current PE only

Change-Id: Ib369dd5a4b738daf96a01b5535d7481a97bb3730
Signed-off-by: Giacomo Travaglini 
Reviewed-by: Nikos Nikoleris 
---
M src/arch/arm/isa.cc
1 file changed, 11 insertions(+), 2 deletions(-)



diff --git a/src/arch/arm/isa.cc b/src/arch/arm/isa.cc
index 9ace236..cfef0ab 100644
--- a/src/arch/arm/isa.cc
+++ b/src/arch/arm/isa.cc
@@ -1711,9 +1711,8 @@
 tlbiOp.broadcast(tc);
 return;
 }
-  // AArch64 TLB Invalidate All, EL2, Inner Shareable
+  // AArch64 TLB Invalidate All, EL2
   case MISCREG_TLBI_ALLE2:
-  case MISCREG_TLBI_ALLE2IS:
 {
 assert64();
 scr = readMiscReg(MISCREG_SCR);
@@ -1722,6 +1721,16 @@
 tlbiOp(tc);
 return;
 }
+  // AArch64 TLB Invalidate All, EL2, Inner Shareable
+  case MISCREG_TLBI_ALLE2IS:
+{
+assert64();
+scr = readMiscReg(MISCREG_SCR);
+
+TLBIALL tlbiOp(EL2, haveSecurity && !scr.ns);
+tlbiOp.broadcast(tc);
+return;
+}
   // AArch64 TLB Invalidate All, EL1
   case MISCREG_TLBI_ALLE1:
   case MISCREG_TLBI_VMALLS12E1:

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34795
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Ib369dd5a4b738daf96a01b5535d7481a97bb3730
Gerrit-Change-Number: 34795
Gerrit-PatchSet: 1
Gerrit-Owner: Giacomo Travaglini 
Gerrit-Reviewer: Nikos Nikoleris 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: util: add pkg-config to ubuntu-20.04_all-dependencies/Dockerfile

[Ciro Santilli (Gerrit) via gem5-dev]

Ciro Santilli has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34777 )



Change subject: util: add pkg-config to  
ubuntu-20.04_all-dependencies/Dockerfile

..

util: add pkg-config to ubuntu-20.04_all-dependencies/Dockerfile

Without this, HDF5 is not built, e.g. a run such as
http://jenkins.gem5.org/job/Nightly/68/console contains:

Checking for hdf5-serial using pkg-config... pkg-config not found
Checking for hdf5 using pkg-config... pkg-config not found
Checking for H5Fcreate("", 0, 0, 0) in C library hdf5... (cached) no
Warning: Couldn't find any HDF5 C++ libraries. Disabling
 HDF5 support.

This is done to increase coverage a bit, and serve as dependency
documentation to users.

Change-Id: Ibf820a3aa76c291201646924ee181615a162
---
M util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile
1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile  
b/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile

index 283d356..3facf7e 100644
--- a/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile
+++ b/util/dockerfiles/ubuntu-20.04_all-dependencies/Dockerfile
@@ -32,4 +32,4 @@
 RUN apt -y install build-essential git m4 scons zlib1g zlib1g-dev \
 libprotobuf-dev protobuf-compiler libprotoc-dev  
libgoogle-perftools-dev \

 python3-dev python3-six python-is-python3 doxygen libboost-all-dev \
-libhdf5-serial-dev python3-pydot libpng-dev libelf-dev
+libhdf5-serial-dev python3-pydot libpng-dev libelf-dev pkg-config

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34777
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Ibf820a3aa76c291201646924ee181615a162
Gerrit-Change-Number: 34777
Gerrit-PatchSet: 1
Gerrit-Owner: Ciro Santilli 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: mem: Fix some reference use in range loops

[Nikos Nikoleris (Gerrit) via gem5-dev]

Nikos Nikoleris has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34776 )



Change subject: mem: Fix some reference use in range loops
..

mem: Fix some reference use in range loops

This change fixes two cases of range loops, one where we can't use
lvalue reference, and one more where we have to use an lvalue
reference as we can't create a copy. In both cases clang would warn.

Change-Id: I760aa094af66be32a150bad37acc21d6fd512a65
Signed-off-by: Nikos Nikoleris 
---
M src/mem/ruby/slicc_interface/RubySlicc_Util.hh
M src/mem/ruby/system/Sequencer.cc
2 files changed, 3 insertions(+), 3 deletions(-)



diff --git a/src/mem/ruby/slicc_interface/RubySlicc_Util.hh  
b/src/mem/ruby/slicc_interface/RubySlicc_Util.hh

index 8ff8884..317bded 100644
--- a/src/mem/ruby/slicc_interface/RubySlicc_Util.hh
+++ b/src/mem/ruby/slicc_interface/RubySlicc_Util.hh
@@ -256,8 +256,8 @@
 countBoolVec(BoolVec bVec)
 {
 int count = 0;
-for (const auto : bVec) {
-if (it) {
+for (const auto &: bVec) {
+if (e) {
 count++;
 }
 }
diff --git a/src/mem/ruby/system/Sequencer.cc  
b/src/mem/ruby/system/Sequencer.cc

index 75c58d6..dbc85c4 100644
--- a/src/mem/ruby/system/Sequencer.cc
+++ b/src/mem/ruby/system/Sequencer.cc
@@ -167,7 +167,7 @@
 int total_outstanding = 0;

 for (const auto _entry : m_RequestTable) {
-for (const auto seq_req : table_entry.second) {
+for (const auto _req : table_entry.second) {
 if (current_time - seq_req.issue_time < m_deadlock_threshold)
 continue;


--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34776
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I760aa094af66be32a150bad37acc21d6fd512a65
Gerrit-Change-Number: 34776
Gerrit-PatchSet: 1
Gerrit-Owner: Nikos Nikoleris 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Change in gem5/gem5[develop]: tests: cleanup all SE tests previously moved to gem5-resources

[Ciro Santilli (Gerrit) via gem5-dev]

Ciro Santilli has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34476 )


Change subject: tests: cleanup all SE tests previously moved to  
gem5-resources

..

tests: cleanup all SE tests previously moved to gem5-resources

The move was done at:
https://gem5-review.googlesource.com/c/public/gem5-resources/+/32074

All files keep exact same name, or are obvious renames like underscore to
-. threads/ is the only non obvious and remaps to src/simple/std_thread.cpp

Only m5-exit is left because it does squashfs generation which wasn't yet
moved.

Change-Id: I72ad104c9311c2f81af49458bdd44e24a6bafc0a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34476
Reviewed-by: Bobby R. Bruce 
Maintainer: Bobby R. Bruce 
Tested-by: kokoro 
---
D tests/test-progs/chdir-print/Makefile
D tests/test-progs/chdir-print/README.txt
D tests/test-progs/chdir-print/chdir-print.c
D tests/test-progs/mwait/Makefile
D tests/test-progs/mwait/mwait.c
D tests/test-progs/page-access-wrap/Makefile
D tests/test-progs/page-access-wrap/page-access-wrap.cpp
D tests/test-progs/stack-print/bin/x86/linux/stack-print
D tests/test-progs/stack-print/src/stack-print.c
9 files changed, 0 insertions(+), 507 deletions(-)

Approvals:
  Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
  kokoro: Regressions pass



diff --git a/tests/test-progs/chdir-print/Makefile  
b/tests/test-progs/chdir-print/Makefile

deleted file mode 100644
index 6a357d5..000
--- a/tests/test-progs/chdir-print/Makefile
+++ /dev/null
@@ -1,20 +0,0 @@
-
-CPP := g++
-
-TEST_OBJS := chdir-print.o
-TEST_PROGS := $(TEST_OBJS:.o=)
-
-#  Rules  
==

-
-.PHONY: default clean
-
-default: $(TEST_PROGS)
-
-clean:
-   $(RM)  $(TEST_OBJS) $(TEST_PROGS)
-
-$(TEST_PROGS): $(TEST_OBJS)
-   $(CPP)  -static -o $@  $@.o
-
-%.o: %.c Makefile
-   $(CPP) -c -o $@ $*.c -msse3
diff --git a/tests/test-progs/chdir-print/README.txt  
b/tests/test-progs/chdir-print/README.txt

deleted file mode 100644
index b1e9213..000
--- a/tests/test-progs/chdir-print/README.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-# example test compile and run parameters
-# Note: the absolute path to the chdir-print binary should be specified
-# in the run command even if running from the same folder. This is needed
-# because chdir is executed before triggering a clone for the file read,
-# and the cloned process won't be able to find the executable if a relative
-# path is provided.
-
-# compile examples
-scons --default=X86 ./build/X86/gem5.opt PROTOCOL=MOESI_hammer
-scons --default=X86 ./build/X86/gem5.opt PROTOCOL=MESI_Three_Level
-
-# run parameters
-/build/X86/gem5.opt /configs/example/se.py -c  
/tests/test-progs/chdir-print/chdir-print -n2 --ruby

-
-
-# example successful output for MESI_Three_Level:
-
-<...>
-
- REAL SIMULATION 
-info: Entering event queue @ 0.  Starting simulation...
-warn: Replacement policy updates recently became the responsibility of  
SLICC state machines. Make sure to setMRU() near callbacks in .sm files!
-cwd:  
/proj/research_simu/users/jalsop/gem5-mem_dif_debug/tests/test-progs/chdir-print/

-cwd: /proc
-
-<...>
-
-processor   : 0
-vendor_id   : Generic
-cpu family  : 0
-model   : 0
-model name  : Generic
-stepping: 0
-cpu MHz : 2000
-cache size: : 2048K
-physical id : 0
-siblings: 2
-core id : 0
-cpu cores   : 2
-fpu : yes
-fpu exception   : yes
-cpuid level : 1
-wp  : yes
-flags   : fpu
-cache alignment : 64
-
-processor   : 1
-vendor_id   : Generic
-cpu family  : 0
-model   : 0
-model name  : Generic
-stepping: 0
-cpu MHz : 2000
-cache size: : 2048K
-physical id : 0
-siblings: 2
-core id : 1
-cpu cores   : 2
-fpu : yes
-fpu exception   : yes
-cpuid level : 1
-wp  : yes
-flags   : fpu
-cache alignment : 64
-
-SUCCESS
-Exiting @ tick 2694923000 because exiting with last active thread context
diff --git a/tests/test-progs/chdir-print/chdir-print.c  
b/tests/test-progs/chdir-print/chdir-print.c

deleted file mode 100644
index 71747b6..000
--- a/tests/test-progs/chdir-print/chdir-print.c
+++ /dev/null
@@ -1,77 +0,0 @@
-/*
- * Copyright (c) 2011-2015 Advanced Micro Devices, Inc.
- * All rights reserved.
- *
- * For use for simulation and test purposes only
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are  
met:

- *
- * 1. Redistributions of source code must retain the above copyright  
notice,

- * this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright  
notice,
- * this list of conditions and 

[gem5-dev] Change in gem5/gem5[develop]: systemc: Add a missing override.

[Gabe Black (Gerrit) via gem5-dev]

Gabe Black has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/34756 )


Change subject: systemc: Add a missing override.
..

systemc: Add a missing override.

A recent change accidentally left off the override, upsetting gcc.

Change-Id: I78cf1969aa6ac462539a2793a8a91dea32002f3a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34756
Maintainer: Gabe Black 
Reviewed-by: Giacomo Travaglini 
Tested-by: kokoro 
---
M src/systemc/core/scheduler.hh
1 file changed, 1 insertion(+), 1 deletion(-)

Approvals:
  Giacomo Travaglini: Looks good to me, approved
  Gabe Black: Looks good to me, approved
  kokoro: Regressions pass



diff --git a/src/systemc/core/scheduler.hh b/src/systemc/core/scheduler.hh
index 273faf7..742f916 100644
--- a/src/systemc/core/scheduler.hh
+++ b/src/systemc/core/scheduler.hh
@@ -160,7 +160,7 @@
 Tick targeted_when;
 Scheduler* parent_scheduler;
 ScEvents events;
-void process();
+void process() override;

   protected:
 void

--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/34756
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I78cf1969aa6ac462539a2793a8a91dea32002f3a
Gerrit-Change-Number: 34756
Gerrit-PatchSet: 2
Gerrit-Owner: Gabe Black 
Gerrit-Reviewer: Bobby R. Bruce 
Gerrit-Reviewer: Earl Ou 
Gerrit-Reviewer: Gabe Black 
Gerrit-Reviewer: Giacomo Travaglini 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s