Re: [gem5-dev] Review Request 3753: ruby: Check MessageBuffer space in garnet NetworkInterface

[Tushar Krishna]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3753/#review9246
---

Ship it!


Ship It!

- Tushar Krishna


On Jan. 10, 2017, 9:42 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3753/
> ---
> 
> (Updated Jan. 10, 2017, 9:42 p.m.)
> 
> 
> Review request for Default and Tushar Krishna.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11792:9ee13c6fa290
> ---
> ruby: Check MessageBuffer space in garnet NetworkInterface
> 
> Garnet's NetworkInterface does not consider the size of MessageBuffers when
> ejecting a Message from the network. Add a size check for the MessageBuffer
> and only enqueue if space is available. If space is not available, the
> message if placed in a queue and the credit is held. A callback from the
> MessageBuffer is implemented to wake the NetworkInterface. If there are
> messages in the stalled queue, they are processed first, in a FIFO manner
> and if succesfully ejected, the credit is finally sent back upstream. The
> maximum size of the stall queue is equal to the number of valid VNETs
> with MessageBuffers attached.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/garnet2.0/flit.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flitBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flit.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
> 
> Diff: http://reviews.gem5.org/r/3753/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3753: ruby: Check MessageBuffer space in garnet NetworkInterface

[Matthew Poremba]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3753/
---

(Updated Jan. 10, 2017, 9:42 p.m.)


Review request for Default and Tushar Krishna.


Repository: gem5


Description (updated)
---

Changeset 11792:9ee13c6fa290
---
ruby: Check MessageBuffer space in garnet NetworkInterface

Garnet's NetworkInterface does not consider the size of MessageBuffers when
ejecting a Message from the network. Add a size check for the MessageBuffer
and only enqueue if space is available. If space is not available, the
message if placed in a queue and the credit is held. A callback from the
MessageBuffer is implemented to wake the NetworkInterface. If there are
messages in the stalled queue, they are processed first, in a FIFO manner
and if succesfully ejected, the credit is finally sent back upstream. The
maximum size of the stall queue is equal to the number of valid VNETs
with MessageBuffers attached.


Diffs (updated)
-

  src/mem/ruby/network/garnet2.0/flit.cc 
c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
  src/mem/ruby/network/garnet2.0/flitBuffer.hh 
c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
  src/mem/ruby/network/garnet2.0/NetworkInterface.cc 
c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
  src/mem/ruby/network/garnet2.0/flit.hh 
c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
  src/mem/ruby/network/MessageBuffer.hh 
c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
  src/mem/ruby/network/MessageBuffer.cc 
c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
  src/mem/ruby/network/garnet2.0/NetworkInterface.hh 
c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 

Diff: http://reviews.gem5.org/r/3753/diff/


Testing
---


Thanks,

Matthew Poremba

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3753: ruby: Check MessageBuffer space in garnet NetworkInterface

[Tushar Krishna]

> On Jan. 10, 2017, 4:43 p.m., Tushar Krishna wrote:
> > src/mem/ruby/network/garnet2.0/NetworkInterface.cc, line 150
> > 
> >
> > Hey Matt,
> > There is a minor change I have been wanting to push in which you can 
> > add as part of this patch:
> > 
> > We count network_delay as dequeue_time - enqueue_time.
> > 
> > A minor issue is that the "enqueue_time" includes an additional cycle 
> > at the source NIC when the packet was created.
> > 
> > For example:
> > Suppose we have a 1-flit packet that we have to send one hop from Node 
> > 0 to Node 1.
> > We create in Cycle 1.
> > 
> > Cycle 1: flit enqueued by NIC 0
> > Cycle 2: flit in link_NIC0-Router0
> > Cycle 3: flit in Router 0
> > Cycle 4: flit in link_Router0-Router1
> > Cycle 5: flit in Router 1
> > Cycle 6: flit in link_Router1-NIC1
> > Cycle 7: flit dequeued by NIC 1.
> > 
> > Network delay will be calculated as 7-1 = 6 cycles.
> > But the actual "network" delay was 5 cycles (cycle 2 to cycle 6).
> > 
> > The additional 1-cycle in NIC0 is going to be part of the 
> > src_queueing_delay so it is being accounted for.
> > 
> > Does this make sense?
> > 
> > If yes, can you update network delay to 
> > dequeue_time - enqueue_time - 1 ?
> > 
> > And then ship it.
> > 
> > Thanks,
> > Tushar
> 
> Matthew Poremba wrote:
> I think I follow. Just to make sure I understand, the additional cycle 
> comes from the source side, correct? Since flitisizeMessage places the flit 
> in a VC output buffer but it is not injected until the next cycle? If that's 
> correct, I'll fold that change into this patch.

Yes that's correct.

Thanks.


- Tushar


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3753/#review9243
---


On Jan. 6, 2017, 11:59 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3753/
> ---
> 
> (Updated Jan. 6, 2017, 11:59 p.m.)
> 
> 
> Review request for Default and Tushar Krishna.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11792:66b31157514e
> ---
> ruby: Check MessageBuffer space in garnet NetworkInterface
> 
> Garnet's NetworkInterface does not consider the size of MessageBuffers when
> ejecting a Message from the network. Add a size check for the MessageBuffer
> and only enqueue if space is available. If space is not available, the
> message if placed in a queue and the credit is held. A callback from the
> MessageBuffer is implemented to wake the NetworkInterface. If there are
> messages in the stalled queue, they are processed first, in a FIFO manner
> and if succesfully ejected, the credit is finally sent back upstream. The
> maximum size of the stall queue is equal to the number of valid VNETs
> with MessageBuffers attached.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/garnet2.0/flit.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flit.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flitBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
> 
> Diff: http://reviews.gem5.org/r/3753/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3753: ruby: Check MessageBuffer space in garnet NetworkInterface

[Matthew Poremba]

> On Jan. 10, 2017, 4:43 p.m., Tushar Krishna wrote:
> > src/mem/ruby/network/garnet2.0/NetworkInterface.cc, line 150
> > 
> >
> > Hey Matt,
> > There is a minor change I have been wanting to push in which you can 
> > add as part of this patch:
> > 
> > We count network_delay as dequeue_time - enqueue_time.
> > 
> > A minor issue is that the "enqueue_time" includes an additional cycle 
> > at the source NIC when the packet was created.
> > 
> > For example:
> > Suppose we have a 1-flit packet that we have to send one hop from Node 
> > 0 to Node 1.
> > We create in Cycle 1.
> > 
> > Cycle 1: flit enqueued by NIC 0
> > Cycle 2: flit in link_NIC0-Router0
> > Cycle 3: flit in Router 0
> > Cycle 4: flit in link_Router0-Router1
> > Cycle 5: flit in Router 1
> > Cycle 6: flit in link_Router1-NIC1
> > Cycle 7: flit dequeued by NIC 1.
> > 
> > Network delay will be calculated as 7-1 = 6 cycles.
> > But the actual "network" delay was 5 cycles (cycle 2 to cycle 6).
> > 
> > The additional 1-cycle in NIC0 is going to be part of the 
> > src_queueing_delay so it is being accounted for.
> > 
> > Does this make sense?
> > 
> > If yes, can you update network delay to 
> > dequeue_time - enqueue_time - 1 ?
> > 
> > And then ship it.
> > 
> > Thanks,
> > Tushar

I think I follow. Just to make sure I understand, the additional cycle comes 
from the source side, correct? Since flitisizeMessage places the flit in a VC 
output buffer but it is not injected until the next cycle? If that's correct, 
I'll fold that change into this patch.


- Matthew


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3753/#review9243
---


On Jan. 6, 2017, 11:59 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3753/
> ---
> 
> (Updated Jan. 6, 2017, 11:59 p.m.)
> 
> 
> Review request for Default and Tushar Krishna.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11792:66b31157514e
> ---
> ruby: Check MessageBuffer space in garnet NetworkInterface
> 
> Garnet's NetworkInterface does not consider the size of MessageBuffers when
> ejecting a Message from the network. Add a size check for the MessageBuffer
> and only enqueue if space is available. If space is not available, the
> message if placed in a queue and the credit is held. A callback from the
> MessageBuffer is implemented to wake the NetworkInterface. If there are
> messages in the stalled queue, they are processed first, in a FIFO manner
> and if succesfully ejected, the credit is finally sent back upstream. The
> maximum size of the stall queue is equal to the number of valid VNETs
> with MessageBuffers attached.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/garnet2.0/flit.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flit.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flitBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
> 
> Diff: http://reviews.gem5.org/r/3753/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3753: ruby: Check MessageBuffer space in garnet NetworkInterface

[Tushar Krishna]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3753/#review9243
---



src/mem/ruby/network/garnet2.0/NetworkInterface.cc (line 150)


Hey Matt,
There is a minor change I have been wanting to push in which you can add as 
part of this patch:

We count network_delay as dequeue_time - enqueue_time.

A minor issue is that the "enqueue_time" includes an additional cycle at 
the source NIC when the packet was created.

For example:
Suppose we have a 1-flit packet that we have to send one hop from Node 0 to 
Node 1.
We create in Cycle 1.

Cycle 1: flit enqueued by NIC 0
Cycle 2: flit in link_NIC0-Router0
Cycle 3: flit in Router 0
Cycle 4: flit in link_Router0-Router1
Cycle 5: flit in Router 1
Cycle 6: flit in link_Router1-NIC1
Cycle 7: flit dequeued by NIC 1.

Network delay will be calculated as 7-1 = 6 cycles.
But the actual "network" delay was 5 cycles (cycle 2 to cycle 6).

The additional 1-cycle in NIC0 is going to be part of the 
src_queueing_delay so it is being accounted for.

Does this make sense?

If yes, can you update network delay to 
dequeue_time - enqueue_time - 1 ?

And then ship it.

Thanks,
Tushar


- Tushar Krishna


On Jan. 6, 2017, 11:59 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3753/
> ---
> 
> (Updated Jan. 6, 2017, 11:59 p.m.)
> 
> 
> Review request for Default and Tushar Krishna.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11792:66b31157514e
> ---
> ruby: Check MessageBuffer space in garnet NetworkInterface
> 
> Garnet's NetworkInterface does not consider the size of MessageBuffers when
> ejecting a Message from the network. Add a size check for the MessageBuffer
> and only enqueue if space is available. If space is not available, the
> message if placed in a queue and the credit is held. A callback from the
> MessageBuffer is implemented to wake the NetworkInterface. If there are
> messages in the stalled queue, they are processed first, in a FIFO manner
> and if succesfully ejected, the credit is finally sent back upstream. The
> maximum size of the stall queue is equal to the number of valid VNETs
> with MessageBuffers attached.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/garnet2.0/flit.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flit.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flitBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
> 
> Diff: http://reviews.gem5.org/r/3753/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3753: ruby: Check MessageBuffer space in garnet NetworkInterface

[Tushar Krishna]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3753/#review9242
---

Ship it!


Ship It!

- Tushar Krishna


On Jan. 6, 2017, 11:59 p.m., Matthew Poremba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3753/
> ---
> 
> (Updated Jan. 6, 2017, 11:59 p.m.)
> 
> 
> Review request for Default and Tushar Krishna.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11792:66b31157514e
> ---
> ruby: Check MessageBuffer space in garnet NetworkInterface
> 
> Garnet's NetworkInterface does not consider the size of MessageBuffers when
> ejecting a Message from the network. Add a size check for the MessageBuffer
> and only enqueue if space is available. If space is not available, the
> message if placed in a queue and the credit is held. A callback from the
> MessageBuffer is implemented to wake the NetworkInterface. If there are
> messages in the stalled queue, they are processed first, in a FIFO manner
> and if succesfully ejected, the credit is finally sent back upstream. The
> maximum size of the stall queue is equal to the number of valid VNETs
> with MessageBuffers attached.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/network/garnet2.0/flit.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flit.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/flitBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/MessageBuffer.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.hh 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
>   src/mem/ruby/network/garnet2.0/NetworkInterface.cc 
> c10c50cb8ac9d6c8dfbaa6437720a07656a3afcf 
> 
> Diff: http://reviews.gem5.org/r/3753/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Matthew Poremba
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3767: mem: Allow non-invalidating uncacheable snoops

[Nikos Nikoleris]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3767/#review9241
---


Thanks for this patch Eric. Can you elaborate a bit more on the case that fails?

I was under the impression that the current conditions that trigger this panic 
cannot be satisfied by cacheable requests. The panic here 
https://www.mail-archive.com/gem5-users@gem5.org/msg13105.html seems to be due 
to a WriteReq which in the form of a snoop can only be seen as an uncacheable 
request if I am not mistaken.

- Nikos Nikoleris


On Dec. 19, 2016, 7:39 p.m., Eric Clark wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3767/
> ---
> 
> (Updated Dec. 19, 2016, 7:39 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11766:3a8eb6336012
> ---
> mem: Allow non-invalidating uncacheable snoops
> 
> This is a follow up to changeset 11285. Uncacheable snoops do
> not invalidate so this panics if we are responding to an uncacheable
> write snoop.
> 
> This panic happens under ARM Linux 4.3. It affects myself and at
> least one other user:
> 
> https://www.mail-archive.com/gem5-users@gem5.org/msg13105.html
> 
> 
> Diffs
> -
> 
>   src/mem/cache/cache.cc 29d401db3746 
> 
> Diff: http://reviews.gem5.org/r/3767/diff/
> 
> 
> Testing
> ---
> 
> Ran {ARM,X86} debug/quick/se regressions but I don't have the spec binaries. 
> Used with ARM full system simulation to complete my course project.
> 
> 
> Thanks,
> 
> Eric Clark
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] protobuf error

[Nikos Nikoleris]

Hi Kirk,

The problem is that protobuf relies on the fact that undefined
preprocessor symbols are expanded by default to 0. This is causing
problems for gem5 as for sanity we force the compiler to warn for
undefined symbols.

I posted a workaround on the reviewboard
http://reviews.gem5.org/r/3779/ but ultimately that's probably
something that should be taken with the protobuf developers. It would
be good to take this matter with the protobuf developers as well,
maybe defining PROTOBUF_INLINE_NOT_IN_HEADERS would be a safer
approach.

Nikos

On 9 January 2017 at 08:47, Andreas Hansson  wrote:
> Hi Kritik,
>
> Thanks for all the diligence. To me this sounds like an issue in the
> protobuf headers, do you not think so?
>
> Andreas
>
>
> On 06/01/2017, 17:09, "gem5-dev on behalf of kritik bhimani"
>  wrote:
>
>>I got the following as error after doing a fresh clone and fresh build in
>>the following case for RISCV . The error also persist while building for
>>X86 and ARM
>>scons build/RISCV/gem5.opt -j4
>>
>>In file included from build/RISCV/mem/probes/mem_trace.cc:46:0:
>>build/RISCV/proto/packet.pb.h:324:6: error:
>>"PROTOBUF_INLINE_NOT_IN_HEADERS" is not defined [-Werror=undef]
>> #if !PROTOBUF_INLINE_NOT_IN_HEADERS
>>  ^~
>>cc1plus: all warnings being treated as errors
>>scons: *** [build/RISCV/mem/probes/mem_trace.o] Error 1
>>scons: building terminated because of errors.
>>
>>The above error can be rectified by making the following changes in
>>SConstruct file in the root of repo
>>
>>@@ -652,7 +652,7 @@
>> # Enable -Wall and -Wextra and then disable the few warnings that
>> # we consistently violate
>> main.Append(CCFLAGS=['-Wall', '-Wundef', '-Wextra',
>>- '-Wno-sign-compare', '-Wno-unused-parameter'])
>>+ '-Wno-sign-compare',
>>'-Wno-unused-parameter','-DPROTOBUF_INLINE_NOT_IN_HEADERS=0'])
>> # We always compile using C++11
>> main.Append(CXXFLAGS=['-std=c++11'])
>>
>>For more context on the above error
>>http://stackoverflow.com/questions/34474091/protobuf-inline-not-in-headers
>>/34485004#34485004
>>
>>https://github.com/Open-Transactions/opentxs/issues/647
>>
>>I request to please verify the above changes by compiling it on Ubuntu
>>16.10 and make the appropriate changes to SConscript since it might save
>>some time for new non MAC users.
>>
>>I also checked that version of libprotobuf-dev and other associated
>>packages installed on my system is the latest from
>>https://launchpad.net/ubuntu/+source/protobuf
>>___
>>gem5-dev mailing list
>>gem5-dev@gem5.org
>>http://m5sim.org/mailman/listinfo/gem5-dev
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3779: proto: Fix warnings for protoc v3

[Nikos Nikoleris]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3779/
---

Review request for Default.


Repository: gem5


Description
---

Changeset 11793:9e7dc6807c35
---
proto: Fix warnings for protoc v3

protoc v3 introduces a new syntax for proto files and warns when the
syntax is not explicitly stated.

protoc relies on the fact that undefined preprocessor symbols are
explanded to 0 but since we use -Wundef they end up generating
warnings.

Change-Id: If07abeb54e932469c8f2c4d38634a97fdae40f77
Reviewed-by: Andreas Hansson 
Reviewed-by: Andreas Sandberg 


Diffs
-

  src/proto/SConscript 494ab5474716 
  src/proto/inst.proto 494ab5474716 
  src/proto/inst_dep_record.proto 494ab5474716 
  src/proto/packet.proto 494ab5474716 

Diff: http://reviews.gem5.org/r/3779/diff/


Testing
---


Thanks,

Nikos Nikoleris

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

[Cron Daemon]

* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: 
CHANGED!*** diff[simerr]: SKIPPED
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: CHANGED!
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
CHANGED!
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: CHANGED!
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: CHANGED!
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: CHANGED!
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 CHANGED!
* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing-checker: 
CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/o3-timing: CHANGED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/o3-timing: CHANGED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/minor-timing: CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/minor-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64d/minor-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/minor-timing: 
CHANGED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/o3-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/minor-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/simple-timing-ruby:
 CHANGED!* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/simple-timing: 
CHANGED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/minor-timing: 
CHANGED!*** stat_diff: FAILURE: Statistics mismatch
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/o3-timing: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic: 
passed.* 
build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 passed.* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: 
passed.* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: 
passed.* 
build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
passed.* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter: passed.
* build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: passed.
* build/NULL/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem: passed.
* 
build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer:
 passed.
* 
build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level:
 passed.
* 
build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory:
 passed.
* 
build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token:
 passed.
--- quick/se/00.hello/power/linux/o3-timing ---* 
build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby: 
passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic: 
passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: passed.
* build/SPARC/tests/opt/quick/se/10.mcf/sparc/linux/simple-atomic: passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp:
 passed.