---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2963/#review6856
---
Any feedback before pushing this?
- Andreas Hansson
On July 28, 2015
Hi all,
bzip2 accounts for almost 30% of our regression CPU time, and there is no
obvious way of reducing the dataset (like the other benchmarks). I believe Mike
mentioned something at the ISCA workshop, but I cannot remember exactly what it
was. Anyone got an idea? Mike?
Thanks,
Andreas
--
?
If there are no objections I'll push this by the end of the week.
- Andreas Hansson
On July 16, 2015, 3:43 p.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2973
: http://reviews.gem5.org/r/2963/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Hi all,
https://lists.debian.org/debian-sparc/2015/07/msg00012.html
Given the discussion at the user conference, perhaps we should follow suit.
Any objections?
Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are
latency, lookup latency, response
latency. How does Ruby differentiate the latency from request - response,
request - request, snoop request - snoop response, snoop request - snoop
request, and response - response, snoop response - snoop response? Perhaps
something to think more about?
- Andreas
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2753/#review6847
---
Ship it!
Ship It!
- Andreas Hansson
On July 14, 2015, 9:35 a.m
. The SerialLink
needs a tiny bit of work.
- Andreas Hansson
On July 23, 2015, 8:16 a.m., Erfan Azarkhish wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2986
it.
Should we not also add pkt-payloadDelay? Can we start serialising before
the link controller has the entire packet?
- Andreas Hansson
On July 23, 2015, 8:16 a.m., Erfan Azarkhish wrote:
---
This is an automatically generated e-mail
On July 16, 2015, 9:55 p.m., Andreas Hansson wrote:
Could you elaborate on when this is a problem? Why is this only affecting
o3?
Hongil Yoon wrote:
This may affect other CPU models (e.g. minor). I am not familiar with it,
so I need to read codes.
What ever test case you used
Jul 2015, Andreas Hansson wrote:
Hi Nilay,
Can we please revert this changeset and leave the review open? As
already
stated in the review comments, there are some critical issues that lead
us
to believe that this patch does not bring us closer to a solution.
It would be much appreciated
outstanding issues.
- Andreas Hansson
On July 1, 2015, 10:13 p.m., Nilay Vaish wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2828
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2958/#review6779
---
On July 13, 2015, 3:15 p.m., Andreas Hansson wrote
more
data extracted from the stats.
Diffs
-
util/dram_sweep_plot.py 5fe05690d03d
Diff: http://reviews.gem5.org/r/2973/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman
affecting o3?
- Andreas Hansson
On July 16, 2015, 7:07 p.m., Hongil Yoon wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2975
. To reply, visit:
http://reviews.gem5.org/r/2960/#review6768
---
On July 13, 2015, 3:16 p.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit
changeset 5ee72f4b2931 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=5ee72f4b2931
description:
mem: Fix (ab)use of emplace to avoid temporary object creation
diffstat:
src/mem/bridge.cc| 4 ++--
src/mem/cache/mshr.cc| 2 +-
changeset 07811efc0fde in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=07811efc0fde
description:
mem: Updated DRAMSim2 wrapper to new drain API
Somehow this one slipped through without being updated.
diffstat:
src/mem/dramsim2.cc | 2 +-
1 files changed,
/cache_impl.hh 58fbfddff18d
src/mem/packet.hh 58fbfddff18d
Diff: http://reviews.gem5.org/r/2960/diff/
Testing
---
All regressions pass, and the random soak tests have finished 1 iterations
without any issues.
Thanks,
Andreas Hansson
___
gem5
/cache/base.hh 58fbfddff18d
src/mem/cache/cache_impl.hh 58fbfddff18d
src/mem/cache/prefetch/queued.cc 58fbfddff18d
Diff: http://reviews.gem5.org/r/2961/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
10922:14a0870a3a4b
---
mem: Tidy up CacheBlk class
This patch modernises and tidies up the CacheBlk, removing dead code.
Diffs
-
src/mem/cache/blk.hh 58fbfddff18d
Diff: http://reviews.gem5.org/r/2959/diff/
Testing
---
Thanks,
Andreas Hansson
into caches, snoop filters etc.
Diffs
-
src/mem/packet.hh 58fbfddff18d
Diff: http://reviews.gem5.org/r/2958/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
apologize in advance for perhaps elaborating too much!)
On Wed, Jul 8, 2015 at 1:23 PM Andreas Hansson andreas.hans...@arm.com
wrote:
Gents,
I’ll let Gabor expound on the value of the non-synchronised checkpoints.
When it comes to the parallelisation, I think it is pretty clear that:
1
On July 6, 2015, 10:13 p.m., Andreas Hansson wrote:
I'm not too fond of how this is done, since it essentially creates a base
class that only adds baggage to the classic memory system. Is it not
possible to align the two rather? Also, besides the bloat, I am also
worried about
,
then we can evaluate detailed issues based on whether they
move us
toward
or away from those goals.
Thanks,
Steve
On Thu, Jul 2, 2015 at 8:34 AM Andreas Hansson
andreas.hans...@arm.com
wrote:
Hi all,
I think we
it to the RubyTester port to ignore it)
- Andreas Hansson
On July 7, 2015, 3:55 p.m., Tony Gutierrez wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2776
/2776/#comment5825
As far as I can tell the code is identical, with i replaced with 0. i would
be 0 for the first item. Am I missing something? I see no mentioning of any
ports in this block of code.
- Andreas Hansson
On July 7, 2015, 3:55 p.m., Tony Gutierrez wrote
On July 7, 2015, 4:31 p.m., Andreas Hansson wrote:
configs/ruby/MESI_Three_Level.py, line 103
http://reviews.gem5.org/r/2776/diff/4/?file=47827#file47827line103
As far as I can tell the code is identical, with i replaced with 0. i
would be 0 for the first item. Am I missing
a base class
that only adds baggage to the classic memory system. Is it not possible to
align the two rather? Also, besides the bloat, I am also worried about
performance. Have you measured the impact on the overall regression?
- Andreas Hansson
On June 29, 2015, 6:19 a.m., Nilay Vaish wrote
changeset 0e466ba12a99 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=0e466ba12a99
description:
scons: Bump compiler requirement to gcc = 4.7 and clang = 3.1
This patch updates the compiler minimum requirement to gcc 4.7 and
clang 3.1, thus allowing:
changeset fdd4a895f325 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=fdd4a895f325
description:
mem: Split WriteInvalidateReq into write and invalidate
WriteInvalidateReq ensures that a whole-line write does not incur the
cost of first doing a read
changeset 85a001f2193b in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=85a001f2193b
description:
mem: Delay responses in the crossbar before forwarding
This patch changes how the crossbar classes deal with
responses. Instead of forwarding responses
changeset d958fc5f4a00 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d958fc5f4a00
description:
mem: Increase the default buffer sizes for the DDR4 controller
This patch increases the default read/write buffer sizes for the DDR4
controller config to
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-#
-# Authors: Andreas Hansson
-
-import sys
-import re
-import math
-
-# This utility script parses through the debug output looking for
-# lines printed by the DRAMPowerTrace debug flag. For all such lines,
-# it sorts the entries based
changeset 3e84b8b49c77 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=3e84b8b49c77
description:
mem: Convert Request static const flags to enums
This patch fixes an issue which is very wide spread in the codebase,
causing sporadic linking failures.
changeset 3ac92bf1f31f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=3ac92bf1f31f
description:
mem: Add ReadCleanReq and ReadSharedReq packets
This patch adds two new read requests packets:
ReadCleanReq - For a cache to explicitly request clean
changeset bd37e25fb3b7 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=bd37e25fb3b7
description:
stats: Update stats for cache, crossbar and DRAM changes
This update includes the changes to whole-line writes, the refinement
of Read to ReadClean and
changeset c60acdbdd6ad in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=c60acdbdd6ad
description:
mem: Allow read-only caches and check compliance
This patch adds a parameter to the BaseCache to enable a read-only
cache, for example for the instruction
changeset c4c13fced000 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=c4c13fced000
description:
mem: Avoid DRAM write queue iteration for merging and read lookup
This patch adds a simple lookup structure to avoid iterating over the
write queue to
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2746/#review6670
---
On April 24, 2015, 4:32 p.m., Andreas Hansson wrote
of them writes to
this entire block. Would not this assert fail when invalidate is received
by the private cache of the other core?
Though it might be that classic's coherence protocol behaves in
completely different fashion.
Andreas Hansson wrote:
They need the line
On June 28, 2015, 5:31 p.m., Nilay Vaish wrote:
src/mem/cache/cache_impl.hh, line 2145
http://reviews.gem5.org/r/2886/diff/1/?file=46271#file46271line2145
Same question as previous one?
Andreas Hansson wrote:
Arguably, the new check is actually more sensible that what we had
:
http://reviews.gem5.org/r/2885/#review6667
---
On June 29, 2015, 9:38 a.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http
: http://reviews.gem5.org/r/2882/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
in
Curtis's patch. I prefer to first run multi-gem5 before starting to
review
it.
Thank you,
Mohammad
On Wed, Jun 24, 2015 at 7:25 AM, Andreas Hansson
andreas.hans...@arm.com
wrote:
Hi Steve,
Apologies for the confusion. We are on the same page. My point is
that
we
cannot simply
/RubyPort.cc 73d4798871a5
src/mem/cache/cache_impl.hh 73d4798871a5
src/mem/packet.hh 73d4798871a5
src/mem/packet.cc 73d4798871a5
Diff: http://reviews.gem5.org/r/2885/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5
not be mergeable
without a read-modify-write. We ignore these cases and opt for speed.
Diffs (updated)
-
src/mem/dram_ctrl.cc 73d4798871a5
src/mem/dram_ctrl.hh 73d4798871a5
Diff: http://reviews.gem5.org/r/2746/diff/
Testing
---
Thanks,
Andreas Hansson
73d4798871a5
Diff: http://reviews.gem5.org/r/2884/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
On July 1, 2015, 3:07 p.m., Andreas Hansson wrote:
src/mem/DRAMCtrl.py, line 460
http://reviews.gem5.org/r/2932/diff/1/?file=47349#file47349line460
Really? I was under the impression that the vault controllers were
simple closed page. See for example
http://ieeexplore.ieee.org
Hi Steve,
Shared-memory MultiIface would be synchronising the gem5 instances on a
coarse granularity, corresponding to a link delay (it is a number of
non-coherent machine instances). The multi-threaded event-queue
implementation has to synchronise all event queues on every single memory
access
of the respective patches
src/mem/SConscript (line 73)
http://reviews.gem5.org/r/2936/#comment5764
Same as above
src/mem/SConscript (line 98)
http://reviews.gem5.org/r/2936/#comment5765
Same as above
- Andreas Hansson
On July 1, 2015, 10:34 a.m., Erfan Azarkhish wrote
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2917/#review6661
---
Going once...going twice...
- Andreas Hansson
On June 25, 2015, 7:30
.
- Andreas Hansson
On July 1, 2015, 10:31 a.m., Erfan Azarkhish wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2934
/#comment5751
I am somewhat surprised that we need values this high. With a 32 vault cube
this would amount to an astonishing number of queued transactions (and there is
probably no system out there that would even get close to even using 2048
outstanding transactions).
- Andreas Hansson
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2884/#review6660
---
Any comments?
- Andreas Hansson
On June 10, 2015, 7:59 a.m., Andreas
Hi Erfan,
Thanks! What a great addition to gem5. I am really happy to see how much
the gem5 modularity helps. No need for any complex HMCSim.
I have commented on some of the patches. I think the SerialLink is mostly
fine as is, even though there is some room for improvement. The one thing
I am
205)
http://reviews.gem5.org/r/2935/#comment5758
Comments please :-)
- Andreas Hansson
On July 1, 2015, 10:32 a.m., Erfan Azarkhish wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2908/#review6662
---
Ship it!
Thanks for getting this in shape Tim! Much nicer.
- Andreas
Hi all,
Am I right in assuming I can go ahead with the patches below?
Thanks,
Andreas
From: Andreas Hansson andreas.hans...@arm.commailto:andreas.hans...@arm.com
Date: Thursday, 25 June 2015 01:50
To: gem5-dev@gem5.orgmailto:gem5-dev@gem5.org
gem5-dev@gem5.orgmailto:gem5-dev@gem5.org
Subject
/base.cc 73d4798871a5
configs/common/CacheConfig.py 73d4798871a5
configs/common/Caches.py 73d4798871a5
Diff: http://reviews.gem5.org/r/2883/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org
)
-
1;2c# HG changeset patch
Repository: gem5
Description (updated)
---
Changeset 10884:a49fc0709fb1
---
1;2c# HG changeset patch
# Parent eaf39f841ee86bd48a5d0fd8a87f2601947a77a0
# User Andreas Hansson andreas.hans...@arm.com
mem: Allow read-only
-mail. To reply, visit:
http://reviews.gem5.org/r/2886/#review6649
---
On June 29, 2015, 9:43 a.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit
---
On June 25, 2015, 7:29 a.m., Andreas Hansson wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2882
/O3_ARM_v7a.py 73d4798871a5
Diff: http://reviews.gem5.org/r/2883/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
/cache_impl.hh 73d4798871a5
src/mem/packet.hh 73d4798871a5
src/mem/packet.cc 73d4798871a5
src/mem/ruby/system/RubyPort.cc 73d4798871a5
Diff: http://reviews.gem5.org/r/2885/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5
73d4798871a5
Diff: http://reviews.gem5.org/r/2886/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2886/#review6636
---
On June 10, 2015, 7:59 a.m., Andreas Hansson wrote
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2883/#review6646
---
On June 29, 2015, 9:30 a.m., Andreas Hansson wrote:
---
This is an automatically
of Andreas Hansson
[andreas.hans...@arm.com]
Sent: Friday, June 26, 2015 4:30 PM
To: gem5-dev@gem5.org
Subject: [gem5-dev] Solution to sporadic undefined references
Hi all,
Occasionally we have an email on the list where someone building the
gem5.debug binary has sporadic linking errors due
Hi Mike,
https://registry.hub.docker.com/u/gem5/gem5/
Let us know if you need any pointers.
Andreas
On 26/06/2015 03:38, gem5-dev on behalf of mike upton
gem5-dev-boun...@gem5.org on behalf of michaelup...@gmail.com wrote:
At the workshop, someone mentioned that they build and publish a
Hi Jason,
I will definitely have a look next week. If you’re fine with holding off for a
few more days that’d be great.
Thanks,
Andreas
From: gem5-users
gem5-users-boun...@gem5.orgmailto:gem5-users-boun...@gem5.org on behalf of
Jason Power power...@gmail.commailto:power...@gmail.com
. By doing this the ClusterXBar
should only see 16 ports and the total system could still accommodate 16 * 16
cores or more.
- Andreas Hansson
On June 25, 2015, 3:05 a.m., Chang Hyun Park wrote:
---
This is an automatically generated e
IDs into C++11 typed enums.
Diffs
-
src/mem/request.hh 73d4798871a5
Diff: http://reviews.gem5.org/r/2925/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Hi all,
Occasionally we have an email on the list where someone building the gem5.debug
binary has sporadic linking errors due to undefined references. I did some
additional digging after running in to this, and it turns out we have tons of
places in the code base that are actually not
Hi Jason,
Have a look at tests/SConscript. At the end there is a list of configs
created, and then a call to glob to actually find the regression targets.
You need to add your new test here as well.
I usually end up removing the build/ARM/tests directory to force a re-run.
If the binary is up to
bank prep delay.
Diffs
-
src/mem/dram_ctrl.hh e4f63f1d502d
src/mem/dram_ctrl.cc e4f63f1d502d
Diff: http://reviews.gem5.org/r/2917/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org
done it quickly. But I need time to understand stuff.
--
Nilay
On Thu, 25 Jun 2015, Andreas Hansson wrote:
Hi all,
The following patches are ready to go, and I am keen to know if there
is any additional feedback (given their large impact on the classic
memory system).
# Adding clean
/packet.hh e4f63f1d502d
src/mem/packet.cc e4f63f1d502d
src/mem/snoop_filter.cc e4f63f1d502d
Diff: http://reviews.gem5.org/r/2882/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman
though, so please
ensure that the patches already on RB get pushed first.
- Andreas Hansson
On June 25, 2015, 8:15 a.m., Nilay Vaish wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2918
Hi all,
The following patches are ready to go, and I am keen to know if there is any
additional feedback (given their large impact on the classic memory system).
# Adding clean evictions for snoop-filter tracking
http://reviews.gem5.org/r/2882/
# Cache refinements for more representative
/2911/#comment5682
A port is not allowed to send a new request until it gets a retry, so the
assert is appropriate in this case.
- Andreas Hansson
On June 23, 2015, 9:52 p.m., Jason Power wrote:
---
This is an automatically generated
Hi all,
Great work. However, I fundamentally do not believe in the approach of
‘letting reviewers pick the best features’. There is no way we would ever
get something working out if it. We need to get _one_ working solution
here, and figure out how to best get there. I would propose to do it
/#comment5683
I am not a fan. This should be solved by the draining logic. Once the
object claims to be drained, the order of serialisation should not matter.
I do not think this is the way to go. There is already an established
methodology to solve the issue.
- Andreas Hansson
On June 24
support; that seems like a good
start.
Steve
On Wed, Jun 24, 2015 at 12:26 AM Andreas Hansson andreas.hans...@arm.com
wrote:
Hi all,
Great work. However, I fundamentally do not believe in the approach of
‘letting reviewers pick the best features’. There is no way we would
ever
get something
On June 24, 2015, 7:30 a.m., Andreas Hansson wrote:
src/mem/ruby/system/RubyPort.hh, line 191
http://reviews.gem5.org/r/2911/diff/1/?file=46843#file46843line191
A port is not allowed to send a new request until it gets a retry, so
the assert is appropriate in this case.
Jason
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2911/#review6587
---
Ship it!
Ship It!
- Andreas Hansson
On June 23, 2015, 9:52 p.m
/#comment5670
the include order seems off
- Andreas Hansson
On June 22, 2015, 7:19 p.m., Brandon Potter wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2902
: http://reviews.gem5.org/r/2882/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
for exclusivity
- Andreas
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2882/#review6544
---
On June 10, 2015, 7:59 a.m., Andreas Hansson wrote
,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
3. Template aliases
4. Delegating constructors
This patch also enables a transition from --std=c++0x to --std=c++11.
Diffs
-
SConstruct ebb3d0737aa7
src/SConscript ebb3d0737aa7
Diff: http://reviews.gem5.org/r/2894/diff/
Testing
---
Thanks,
Andreas Hansson
Hi Mike,
I think the main challenge is device state. You will need the same
devices, and a coherent view of their state.
The CPU’s should be easy in comparison. There it’s just a matter of
someone sitting down and doing the work.
Andreas
On 17/06/2015 09:31, mike upton michaelup...@gmail.com
Hi Nilay,
Good points. clang 3.1 would match gcc 4.7 (and then some).
Andreas
On 15/06/2015 17:07, Nilay Vaish ni...@cs.wisc.edu wrote:
On Tue, 16 Jun 2015, Andreas Hansson wrote:
Hi all,
We are really keen to adopt gcc 4.7 as a minimum requirement, thus
enabling the following c++11
/noncoherent_xbar.hh ebb3d0737aa7
src/mem/noncoherent_xbar.cc ebb3d0737aa7
src/mem/snoop_filter.hh ebb3d0737aa7
src/mem/xbar.hh ebb3d0737aa7
Diff: http://reviews.gem5.org/r/2887/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
: http://reviews.gem5.org/r/2885/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Hi all,
We are really keen to adopt gcc 4.7 as a minimum requirement, thus enabling the
following c++11 features:
1. Explicit virtual overrides
2. Non-static data member initializers
3. Template aliases
4. Delegating constructors
Switching to gcc 4.7 would also allow us to finally transition
/diff/
Testing
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
---
Thanks,
Andreas Hansson
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
701 - 800 of 3340 matches
Mail list logo
