[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
scons: *** [build/POWER_SE/kern/linux/linux.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/branch.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/mem.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/integer.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/floating.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/condition.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/static_inst.fo] Error 1 scons: *** [build/POWER_SE/arch/power/pagetable.fo] Error 1 scons: *** [build/POWER_SE/arch/power/tlb.fo] Error 1 scons: *** [build/POWER_SE/arch/power/utility.fo] Error 1 scons: *** [build/POWER_SE/arch/power/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/linux/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/decoder.fo] Error 1 scons: *** [build/POWER_SE/arch/power/atomic_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/o3_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/timing_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/sim/faults.fo] Error 1 scons: *** [build/POWER_SE/sim/stat_control.fo] Error 1 scons: *** [build/POWER_SE/sim/pseudo_inst.fo] Error 1 scons: *** [build/POWER_SE/sim/system.fo] Error 1 scons: *** [build/POWER_SE/sim/tlb.fo] Error 1 scons: *** [build/POWER_SE/sim/syscall_emul.fo] Error 1 scons: *** [build/POWER_SE/sim/process.fo] Error 1 scons: *** [build/POWER_SE/mem/physical.fo] Error 1 scons: *** [build/POWER_SE/mem/page_table.fo] Error 1 scons: *** [build/POWER_SE/mem/translating_port.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/base.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/prefetch/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/exetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/inteltrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/nativetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/pc_event.fo] Error 1 scons: *** [build/POWER_SE/cpu/quiesce_event.fo] Error 1 scons: *** [build/POWER_SE/cpu/static_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple_thread.fo] Error 1 scons: *** [build/POWER_SE/cpu/thread_context.fo] Error 1 scons: *** [build/POWER_SE/cpu/thread_state.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/atomic.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/timing.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/bpred_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/commit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/base_dyn_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/cpu.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/cpu_builder.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/decode.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/fetch.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/free_list.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/dyn_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/iew.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/inst_queue.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/lsq.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/lsq_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/mem_dep_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rename.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rename_map.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/scoreboard.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rob.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/thread_context.fo] Error 1 scons: *** [build/POWER_SE/cpu/pred/ras.fo] Error 1 scons: *** [build/POWER_SE/cpu/pred/btb.fo] Error 1 scons: *** [build/POWER_SE/base/remote_gdb.fo] Error 1 * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
[m5-dev] Running Ruby w/32 Cores
Hi All, I'm still having a bit of trouble running Ruby with 32+ cores. I am experimenting w/configs varying the l2-caches. The runs seems to generate various errors in the SLICC. Has anybody seen these or have any insight to how to start solving these type of issues (posted below)? = The command line and errors are as follows: (1) 32 Cores and 32 L2s build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num-l2caches=32 ... info: Entering event queue @ 0. Starting simulation... Runtime Error at MOESI_CMP_directory-dir.sm:155, Ruby Time: 38279: assert failure, PID: 5990 press return to continue. Program aborted at cycle 19139500 Aborted (2) 32 Cores and 1 L2 build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num-l2caches=32 ... fatal: Invalid transition system.l1_cntrl0 time: 349075 addr: [0x16180, line 0x16180] event: Ack state: MM @ cycle 174537500 [doTransitionWorker:build/ALPHA_FS_MOESI_CMP_directory/mem/protocol/L1Cache_Transitions.cc, line 477] Memory Usage: 2316756 KBytes For more information see: http://www.m5sim.org/fatal/23f196b2 Please let me know if you do...Thanks! -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
Hi Korey, I believe both of these issues should be easy to solve once we have a protocol trace leading up to the error. If you could create such a trace and send it to the list, that would be great. Just zero in on the offending address. Thanks, Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Korey Sewell Sent: Tuesday, March 29, 2011 8:11 AM To: M5 Developer List Subject: [m5-dev] Running Ruby w/32 Cores Hi All, I'm still having a bit of trouble running Ruby with 32+ cores. I am experimenting w/configs varying the l2-caches. The runs seems to generate various errors in the SLICC. Has anybody seen these or have any insight to how to start solving these type of issues (posted below)? = The command line and errors are as follows: (1) 32 Cores and 32 L2s build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- l2caches=32 ... info: Entering event queue @ 0. Starting simulation... Runtime Error at MOESI_CMP_directory-dir.sm:155, Ruby Time: 38279: assert failure, PID: 5990 press return to continue. Program aborted at cycle 19139500 Aborted (2) 32 Cores and 1 L2 build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- l2caches=32 ... fatal: Invalid transition system.l1_cntrl0 time: 349075 addr: [0x16180, line 0x16180] event: Ack state: MM @ cycle 174537500 [doTransitionWorker:build/ALPHA_FS_MOESI_CMP_directory/mem/protoc ol/L1Cache_Transitions.cc, line 477] Memory Usage: 2316756 KBytes For more information see: http://www.m5sim.org/fatal/23f196b2 Please let me know if you do...Thanks! -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Add the user settable seperator string for arrayed stats, default is standard ::
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/610/#review1025 --- Why do you need this functionality? Why isn't :: sufficient? If it's because some other piece of software is expecting something else, I'd say either write a script that munges these stats into a more acceptable format, or adjust the other software. I'm not an expert on our stats stuff by any stretch, but I'd hate to see extra otherwise unnecessary functionality be added to deal with a point issue that only affects a few people. src/base/statistics.hh http://reviews.m5sim.org/r/610/#comment1393 The bracket should be on the next line for functions, and should have a space before it if it were to go on that line. src/base/statistics.hh http://reviews.m5sim.org/r/610/#comment1394 This line is too long. You should spread it out like a normal function. - Gabe On 2011-03-29 07:13:30, brad danofsky wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/610/ --- (Updated 2011-03-29 07:13:30) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Add the user settable seperator string for arrayed stats, default is standard :: I followed the flow for setting the description, name, etc. adding the ability to set the seperator string used between the array element and the name for vectors, vector2d, etc. One difference, that might be objectionable, is I made the stored string static. Diffs - src/base/statistics.hh d8587c913ccf src/base/statistics.cc d8587c913ccf src/base/stats/info.hh d8587c913ccf src/base/stats/text.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/610/diff Testing --- standard full regression Thanks, brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Add the user settable separator string for arrayed stats, default is standard ::
On 2011-03-29 09:05:00, Gabe Black wrote: src/base/statistics.hh, line 265 http://reviews.m5sim.org/r/610/diff/1/?file=11256#file11256line265 The bracket should be on the next line for functions, and should have a space before it if it were to go on that line. brad danofsky wrote: do you have an emacs mode hook for setting up your general style forms? I use vim so I don't use one myself, but util/emacs/m5-c-style.el looks like what you want. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/610/#review1025 --- On 2011-03-29 09:06:43, brad danofsky wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/610/ --- (Updated 2011-03-29 09:06:43) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Add the user settable separator string for arrayed stats, default is standard :: I followed the flow for setting the description, name, etc. adding the ability to set the seperator string used between the array element and the name for vectors, vector2d, etc. One difference, that might be objectionable, is I made the stored string static. Diffs - src/base/statistics.hh d8587c913ccf src/base/statistics.cc d8587c913ccf src/base/stats/info.hh d8587c913ccf src/base/stats/text.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/610/diff Testing --- standard full regression Thanks, brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: cpu: split o3-specific parts out of BaseDynInst
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/529/#review1029 --- I agree with the sentiment of this change, but I think you moved too much into the O3 class. There's functionality (pointed out below) that you'll need to support in InOrder to be compliant with the interface instructions expect from CPUs, specifically delayed translation and oddly shaped/sized, memory accesses with readBytes/writeBytes. You'll have to support those to run all the ISAs, as would any other CPU using a dyninst in the future. The implementations in the base dyninst are pretty generic, although feel free to point out why they might not work with InOrder. src/cpu/base_dyn_inst.hh http://reviews.m5sim.org/r/529/#comment1397 You're going to need to support readBytes and writeBytes style loads and stores to run all the ISAs and to conform to the interfaces the CPU is supposed to provide. These implementations seem pretty generic to me and should work with InOrder, although I don't actually know that much about InOrder. src/cpu/base_dyn_inst.hh http://reviews.m5sim.org/r/529/#comment1398 You're also going to need to support delayed translation for X86 or ARM. It's important we don't have CPUs diverge in what functionality they provide. src/cpu/base_dyn_inst.hh http://reviews.m5sim.org/r/529/#comment1399 This stuff looks old and I'm guessing should be deleted one way or the other. src/cpu/base_dyn_inst.hh http://reviews.m5sim.org/r/529/#comment1400 This seems pretty generic and necessary for delayed translations. I think you probably need to update InOrder to support it rather than isolating it to O3. src/cpu/base_dyn_inst.hh http://reviews.m5sim.org/r/529/#comment1401 Ditto src/cpu/o3/dyn_inst.hh http://reviews.m5sim.org/r/529/#comment1402 As mentioned above, this result stuff may just be old cruft. You should check to see if it's used at all, and if not just let it go away. - Gabe On 2011-03-01 13:49:24, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/529/ --- (Updated 2011-03-01 13:49:24) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- cpu: split o3-specific parts out of BaseDynInst The bigger picture goal is that I want to get the InorderDynInst class derived from the BaseDynInst, since there is no need to replicate a lot of useful code already defined in BaseDynInst (e.g. microcode identification, etc.) and Inorder can take advantage of common code that handles microcode and other features that other ISAs need. But to do this, there are a lot of o3-specific things that are in BaseDynInst, that I pushed to O3DynInst in this patch. Book-keeping variables that handle the IQ,LSQ,ROB are unnecessary in the base class but generic variables that will work across CPUs (IsSquashed, IsCompleted, etc.) are kept in the base class. The upside is more consistency across the simple models (branch prediction and instruction identification are all in one common place). I really wanted to define pure virtual functions for read/write(to memory) and the setInt/FloatRegOperand, but virtual functions in a templated class is a no-no and I couldn't get around that (suggestions?). Also, I'd rather not use the this- pointer all over the place to access member variables of the templated Base class, but it had to be done. Other than those quirks, simulator functionality should stay the same as the O3 Model always references the O3DynInst pointer and the InOrder model doesnt currently make use of the base dyn inst. class. (but it will be easier to derive from now...) Diffs - src/cpu/base_dyn_inst.hh cf1afc88070f src/cpu/base_dyn_inst_impl.hh cf1afc88070f src/cpu/o3/dyn_inst.hh cf1afc88070f src/cpu/o3/dyn_inst_impl.hh cf1afc88070f Diff: http://reviews.m5sim.org/r/529/diff Testing --- Thanks, Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Power: Fix compilation.
changeset 6ae58f06a41c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6ae58f06a41c
description:
Power: Fix compilation.
diffstat:
src/arch/power/types.hh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diffs (11 lines):
diff -r a8d64545cda6 -r 6ae58f06a41c src/arch/power/types.hh
--- a/src/arch/power/types.hh Mon Mar 28 10:49:45 2011 -0500
+++ b/src/arch/power/types.hh Tue Mar 29 13:04:19 2011 -0400
@@ -87,6 +87,7 @@
// typedef int RegContextParam;
// typedef int RegContextVal;
+} // PowerISA namespace
namespace __hash_namespace {
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Compilation of POWER was broken by this change when the closing bracket for a namespace was removed: changeset: 8181:f789b9aac5f4 user:Korey Sewell ksew...@umich.edu date:Sat Mar 26 09:23:52 2011 -0400 summary: mips: cleanup ISA-specific code Compilation was unavoidably broken, and that means this code was not compiled before being checked in. According to the logs, three of the last four commits were to fix outdated regression output, broken configuration scripts, and broken compilation, all of which could have been detected before hand. We all have to be more careful. When was the last time someone could download the dev repository and actually run everything successfully? How many people downloaded a broken version of M5 in that time? As the number of committers increases, it becomes more and more important to push clean changes. If 100 people each break the simulator 1% of the time, the simulator will be broken most of the time. It's also important to keep an eye on the regression output after you push something and investigate any failures you see. I don't want to be the regression police. Gabe On 03/29/11 03:50, Cron Daemon wrote: scons: *** [build/POWER_SE/kern/linux/linux.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/branch.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/mem.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/integer.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/floating.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/condition.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/static_inst.fo] Error 1 scons: *** [build/POWER_SE/arch/power/pagetable.fo] Error 1 scons: *** [build/POWER_SE/arch/power/tlb.fo] Error 1 scons: *** [build/POWER_SE/arch/power/utility.fo] Error 1 scons: *** [build/POWER_SE/arch/power/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/linux/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/decoder.fo] Error 1 scons: *** [build/POWER_SE/arch/power/atomic_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/o3_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/timing_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/sim/faults.fo] Error 1 scons: *** [build/POWER_SE/sim/stat_control.fo] Error 1 scons: *** [build/POWER_SE/sim/pseudo_inst.fo] Error 1 scons: *** [build/POWER_SE/sim/system.fo] Error 1 scons: *** [build/POWER_SE/sim/tlb.fo] Error 1 scons: *** [build/POWER_SE/sim/syscall_emul.fo] Error 1 scons: *** [build/POWER_SE/sim/process.fo] Error 1 scons: *** [build/POWER_SE/mem/physical.fo] Error 1 scons: *** [build/POWER_SE/mem/page_table.fo] Error 1 scons: *** [build/POWER_SE/mem/translating_port.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/base.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/prefetch/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/exetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/inteltrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/nativetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/pc_event.fo] Error 1 scons: *** [build/POWER_SE/cpu/quiesce_event.fo] Error 1 scons: *** [build/POWER_SE/cpu/static_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple_thread.fo] Error 1 scons: *** [build/POWER_SE/cpu/thread_context.fo] Error 1 scons: *** [build/POWER_SE/cpu/thread_state.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/atomic.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/timing.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/bpred_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/commit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/base_dyn_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/cpu.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/cpu_builder.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/decode.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/fetch.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/free_list.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/dyn_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/iew.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/inst_queue.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/lsq.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/lsq_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/mem_dep_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rename.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rename_map.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/scoreboard.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rob.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/thread_context.fo] Error 1 scons: *** [build/POWER_SE/cpu/pred/ras.fo] Error 1 scons: *** [build/POWER_SE/cpu/pred/btb.fo] Error 1 scons: *** [build/POWER_SE/base/remote_gdb.fo] Error 1 * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. *
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Good point about regression carefulness Gabe. Although I'm pretty sure I compiled MIPS before I committed this, I had forgot I touched other ISAs and obviously broke one of them. That's just an error on my part. This brings up a few issues: - Should the regressions be more resilient? In other words, if POWER doesnt compile shouldnt the regressions still *try* for whatever CPU model and ISA combinations it does compile for? (i'll add that to the regression wants page) - It would be nice to somehow be able to localize the regression tests you need to run after making changes. There's about 5 ISAs (?), 4 CPU models , FS/SE mode, so if you make a particular change, sometimes its unwieldy (albeit still necessary) to run every single test. Is there an easy way to test just what matters? - Lastly, An overkill thing would be to have a buffer-repo sitting between users' local repo and m5-dev. Then, nightly before the regressions, you could conceivably test to make sure that builds (or whatever other sanity check) and *then* check-in changesets to the dev-repo after the initial 1st pass. This would ensure that any pulls from m5-dev would always be compilable at the very least. On Tue, Mar 29, 2011 at 1:21 PM, Gabe Black gbl...@eecs.umich.edu wrote: Compilation of POWER was broken by this change when the closing bracket for a namespace was removed: changeset: 8181:f789b9aac5f4 user: Korey Sewell ksew...@umich.edu date: Sat Mar 26 09:23:52 2011 -0400 summary: mips: cleanup ISA-specific code Compilation was unavoidably broken, and that means this code was not compiled before being checked in. According to the logs, three of the last four commits were to fix outdated regression output, broken configuration scripts, and broken compilation, all of which could have been detected before hand. We all have to be more careful. When was the last time someone could download the dev repository and actually run everything successfully? How many people downloaded a broken version of M5 in that time? As the number of committers increases, it becomes more and more important to push clean changes. If 100 people each break the simulator 1% of the time, the simulator will be broken most of the time. It's also important to keep an eye on the regression output after you push something and investigate any failures you see. I don't want to be the regression police. Gabe On 03/29/11 03:50, Cron Daemon wrote: scons: *** [build/POWER_SE/kern/linux/linux.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/branch.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/mem.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/integer.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/floating.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/condition.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/static_inst.fo] Error 1 scons: *** [build/POWER_SE/arch/power/pagetable.fo] Error 1 scons: *** [build/POWER_SE/arch/power/tlb.fo] Error 1 scons: *** [build/POWER_SE/arch/power/utility.fo] Error 1 scons: *** [build/POWER_SE/arch/power/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/linux/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/decoder.fo] Error 1 scons: *** [build/POWER_SE/arch/power/atomic_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/o3_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/timing_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/sim/faults.fo] Error 1 scons: *** [build/POWER_SE/sim/stat_control.fo] Error 1 scons: *** [build/POWER_SE/sim/pseudo_inst.fo] Error 1 scons: *** [build/POWER_SE/sim/system.fo] Error 1 scons: *** [build/POWER_SE/sim/tlb.fo] Error 1 scons: *** [build/POWER_SE/sim/syscall_emul.fo] Error 1 scons: *** [build/POWER_SE/sim/process.fo] Error 1 scons: *** [build/POWER_SE/mem/physical.fo] Error 1 scons: *** [build/POWER_SE/mem/page_table.fo] Error 1 scons: *** [build/POWER_SE/mem/translating_port.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/base.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/prefetch/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/exetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/inteltrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/nativetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/pc_event.fo] Error 1 scons: *** [build/POWER_SE/cpu/quiesce_event.fo] Error 1 scons: *** [build/POWER_SE/cpu/static_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple_thread.fo] Error 1 scons: *** [build/POWER_SE/cpu/thread_context.fo] Error 1 scons: *** [build/POWER_SE/cpu/thread_state.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/atomic.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/timing.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/bpred_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/commit.fo] Error 1 scons: ***
Re: [m5-dev] Running Ruby w/32 Cores
Thanks for the response Brad. The 1st trace has 1 L2 and the 2nd has 1 L2 (i had a typo in the original email). For each trace, I attach the stdout/stderr (*.out) and then the protocol trace (*.prottrace). Also, in the 1st trace, the offending address is clear and I isolate that in the protocol trace file provided. However, in the 2nd trace, it's unclear (currently) which access caused it to fail so I took the whole protocol trace file and gzip'd it. My current lack of expertise in SLICC limits me a bit, but I'd like to be more helpful in debugging so if there is anything that I can look into (or run) on my end to expedite the process, please advise. In the interim, I'll try to locate the exact address that's breaking trace 2 and then hopefully repost that. Thanks! -Korey On Tue, Mar 29, 2011 at 12:02 PM, Beckmann, Brad brad.beckm...@amd.com wrote: Hi Korey, I believe both of these issues should be easy to solve once we have a protocol trace leading up to the error. If you could create such a trace and send it to the list, that would be great. Just zero in on the offending address. Thanks, Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Korey Sewell Sent: Tuesday, March 29, 2011 8:11 AM To: M5 Developer List Subject: [m5-dev] Running Ruby w/32 Cores Hi All, I'm still having a bit of trouble running Ruby with 32+ cores. I am experimenting w/configs varying the l2-caches. The runs seems to generate various errors in the SLICC. Has anybody seen these or have any insight to how to start solving these type of issues (posted below)? = The command line and errors are as follows: (1) 32 Cores and 32 L2s build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- l2caches=32 ... info: Entering event queue @ 0. Starting simulation... Runtime Error at MOESI_CMP_directory-dir.sm:155, Ruby Time: 38279: assert failure, PID: 5990 press return to continue. Program aborted at cycle 19139500 Aborted (2) 32 Cores and 1 L2 build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- l2caches=32 ... fatal: Invalid transition system.l1_cntrl0 time: 349075 addr: [0x16180, line 0x16180] event: Ack state: MM @ cycle 174537500 [doTransitionWorker:build/ALPHA_FS_MOESI_CMP_directory/mem/protoc ol/L1Cache_Transitions.cc, line 477] Memory Usage: 2316756 KBytes For more information see: http://www.m5sim.org/fatal/23f196b2 Please let me know if you do...Thanks! -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
On Tue, Mar 29, 2011 at 10:34 AM, Korey Sewell ksew...@umich.edu wrote: Good point about regression carefulness Gabe. Although I'm pretty sure I compiled MIPS before I committed this, I had forgot I touched other ISAs and obviously broke one of them. That's just an error on my part. This brings up a few issues: - Should the regressions be more resilient? In other words, if POWER doesnt compile shouldnt the regressions still *try* for whatever CPU model and ISA combinations it does compile for? (i'll add that to the regression wants page) They already do... note that everything else passed. - It would be nice to somehow be able to localize the regression tests you need to run after making changes. There's about 5 ISAs (?), 4 CPU models , FS/SE mode, so if you make a particular change, sometimes its unwieldy (albeit still necessary) to run every single test. Is there an easy way to test just what matters? There isn't (and it's already on the wish list), but it seems that's actually part of the problem here: some things broke that you didn't think you had affected. OTOH, if you're talking about having the system automatically detect what needs to be run, it already does that (to some extent) by being built into scons... it will only compile the binaries and run the tests that depend on files that have changed, modulo scons bugs. - Lastly, An overkill thing would be to have a buffer-repo sitting between users' local repo and m5-dev. Then, nightly before the regressions, you could conceivably test to make sure that builds (or whatever other sanity check) and *then* check-in changesets to the dev-repo after the initial 1st pass. This would ensure that any pulls from m5-dev would always be compilable at the very least. That's why we have m5-stable, basically. Steve On Tue, Mar 29, 2011 at 1:21 PM, Gabe Black gbl...@eecs.umich.edu wrote: Compilation of POWER was broken by this change when the closing bracket for a namespace was removed: changeset: 8181:f789b9aac5f4 user: Korey Sewell ksew...@umich.edu date: Sat Mar 26 09:23:52 2011 -0400 summary: mips: cleanup ISA-specific code Compilation was unavoidably broken, and that means this code was not compiled before being checked in. According to the logs, three of the last four commits were to fix outdated regression output, broken configuration scripts, and broken compilation, all of which could have been detected before hand. We all have to be more careful. When was the last time someone could download the dev repository and actually run everything successfully? How many people downloaded a broken version of M5 in that time? As the number of committers increases, it becomes more and more important to push clean changes. If 100 people each break the simulator 1% of the time, the simulator will be broken most of the time. It's also important to keep an eye on the regression output after you push something and investigate any failures you see. I don't want to be the regression police. Gabe On 03/29/11 03:50, Cron Daemon wrote: scons: *** [build/POWER_SE/kern/linux/linux.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/branch.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/mem.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/integer.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/floating.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/condition.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/static_inst.fo] Error 1 scons: *** [build/POWER_SE/arch/power/pagetable.fo] Error 1 scons: *** [build/POWER_SE/arch/power/tlb.fo] Error 1 scons: *** [build/POWER_SE/arch/power/utility.fo] Error 1 scons: *** [build/POWER_SE/arch/power/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/linux/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/decoder.fo] Error 1 scons: *** [build/POWER_SE/arch/power/atomic_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/o3_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/timing_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/sim/faults.fo] Error 1 scons: *** [build/POWER_SE/sim/stat_control.fo] Error 1 scons: *** [build/POWER_SE/sim/pseudo_inst.fo] Error 1 scons: *** [build/POWER_SE/sim/system.fo] Error 1 scons: *** [build/POWER_SE/sim/tlb.fo] Error 1 scons: *** [build/POWER_SE/sim/syscall_emul.fo] Error 1 scons: *** [build/POWER_SE/sim/process.fo] Error 1 scons: *** [build/POWER_SE/mem/physical.fo] Error 1 scons: *** [build/POWER_SE/mem/page_table.fo] Error 1 scons: *** [build/POWER_SE/mem/translating_port.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/base.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/prefetch/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/exetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/inteltrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/nativetrace.fo] Error 1
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
On 03/29/11 13:34, Korey Sewell wrote: Good point about regression carefulness Gabe. Although I'm pretty sure I compiled MIPS before I committed this, I had forgot I touched other ISAs and obviously broke one of them. That's just an error on my part. Yeah, I didn't want to pick on you, Korey, you're change was just the most recent. I've done it too once in a while. We -all- need to be careful. This brings up a few issues: - Should the regressions be more resilient? In other words, if POWER doesnt compile shouldnt the regressions still *try* for whatever CPU model and ISA combinations it does compile for? (i'll add that to the regression wants page) POWER_SE was totally broken because a central file (types.hh) would break anything that included it, so it probably wouldn't be possible to run them at all. Other ISAs are separate builds so those did run. Trying to find valid CPUs would likely be overkill since we should keep things building in the first place. - It would be nice to somehow be able to localize the regression tests you need to run after making changes. There's about 5 ISAs (?), 4 CPU models , FS/SE mode, so if you make a particular change, sometimes its unwieldy (albeit still necessary) to run every single test. Is there an easy way to test just what matters? I run the quick regressions for any mode/ISA combination I touched or think I might have affected. Sometimes I guess wrong, but that's done pretty well for me. Then there are the things that aren't in the regressions at all, but we're working to fix that I think. - Lastly, An overkill thing would be to have a buffer-repo sitting between users' local repo and m5-dev. Then, nightly before the regressions, you could conceivably test to make sure that builds (or whatever other sanity check) and *then* check-in changesets to the dev-repo after the initial 1st pass. This would ensure that any pulls from m5-dev would always be compilable at the very least. That makes sense and was what I was hoping we could use m5-stable for, but we didn't end up doing that because we wanted m5-stable to be even more stable than that (although it tends to just be old, not necessarily stable). Maybe we need something in the middle that works like you're suggesting. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
On Tue, Mar 29, 2011 at 10:54 AM, Gabe Black gbl...@eecs.umich.edu wrote: That makes sense and was what I was hoping we could use m5-stable for, but we didn't end up doing that because we wanted m5-stable to be even more stable than that (although it tends to just be old, not necessarily stable). Maybe we need something in the middle that works like you're suggesting. I'd prefer to see us just start updating m5-stable more regularly so it can fulfill its original purpose. We keep discussing this but never actually follow through. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs - configs/ruby/MESI_CMP_directory.py 6ae58f06a41c configs/ruby/Ruby.py 6ae58f06a41c src/mem/ruby/network/Network.cc 6ae58f06a41c src/mem/ruby/network/Network.py 6ae58f06a41c src/mem/ruby/profiler/Profiler.cc 6ae58f06a41c src/mem/ruby/profiler/Profiler.py 6ae58f06a41c src/mem/ruby/recorder/Tracer.cc 6ae58f06a41c src/mem/ruby/recorder/Tracer.py 6ae58f06a41c src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py 6ae58f06a41c src/mem/ruby/system/CacheMemory.hh 6ae58f06a41c src/mem/ruby/system/CacheMemory.cc 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.hh 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.cc 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.py 6ae58f06a41c src/mem/ruby/system/RubyPort.hh 6ae58f06a41c src/mem/ruby/system/RubyPort.cc 6ae58f06a41c src/mem/ruby/system/RubySystem.py 6ae58f06a41c src/mem/ruby/system/SConscript 6ae58f06a41c src/mem/ruby/system/Sequencer.py 6ae58f06a41c src/mem/ruby/system/System.hh 6ae58f06a41c src/mem/ruby/system/System.cc 6ae58f06a41c Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
Brad, I have posted on the review board my current implementation for supporting functional accesses in Ruby. This is untested and is mainly meant for furthering the discussions. I have some questions for you -- 1. How do we inform the other end of RubyPort's M5 Port about whether or not functional access was successful? 2. What's the role of directory memory in functional accesses? 3. If none of the caches have the block pertaining to the address of the access, then read accesses should be satisfied from the physical memory. Write accesses should always go to physical memory as well. How can physical memory be accessed from RubyPort? -- Nilay On Tue, 29 Mar 2011, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Add the user settable separator string for arrayed stats, default is standard ::
On 2011-03-29 09:05:00, Gabe Black wrote: Why do you need this functionality? Why isn't :: sufficient? If it's because some other piece of software is expecting something else, I'd say either write a script that munges these stats into a more acceptable format, or adjust the other software. I'm not an expert on our stats stuff by any stretch, but I'd hate to see extra otherwise unnecessary functionality be added to deal with a point issue that only affects a few people. brad danofsky wrote: You are correct that this may just be my problem. I have a whole lot of scripts that expect a different character (one used in a previous version of m5 I think). If it is objectionable that there be support for this then so be it. These are scripts that date back to when we used a different separator (for SimpleScalar compatibility I believe), so arguably it's just fixing something we broke in m5 a long time ago. I discussed this with Brad, and we decided that in the long run the ideal thing would be to leverage the any-day-now stats-in-python functionality to have m5 spit out stats directly in the format that these scripts currently generate, making the scripts obsolete. But in the meantime it's a much smaller change to tweak m5 than to edit this pile of scripts, and I don't think it's hurting anyone to put this in there. - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/610/#review1025 --- On 2011-03-29 09:43:16, brad danofsky wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/610/ --- (Updated 2011-03-29 09:43:16) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Add the user settable separator string for arrayed stats, default is standard :: I updated the diff to fix Gabes issues and I learned how to spell. Diffs - src/base/statistics.hh d8587c913ccf src/base/statistics.cc d8587c913ccf src/base/stats/info.hh d8587c913ccf src/base/stats/text.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/610/diff Testing --- standard full regression Thanks, brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Add the user settable separator string for arrayed stats, default is standard ::
On 2011-03-29 09:05:00, Gabe Black wrote: Why do you need this functionality? Why isn't :: sufficient? If it's because some other piece of software is expecting something else, I'd say either write a script that munges these stats into a more acceptable format, or adjust the other software. I'm not an expert on our stats stuff by any stretch, but I'd hate to see extra otherwise unnecessary functionality be added to deal with a point issue that only affects a few people. brad danofsky wrote: You are correct that this may just be my problem. I have a whole lot of scripts that expect a different character (one used in a previous version of m5 I think). If it is objectionable that there be support for this then so be it. Steve Reinhardt wrote: These are scripts that date back to when we used a different separator (for SimpleScalar compatibility I believe), so arguably it's just fixing something we broke in m5 a long time ago. I discussed this with Brad, and we decided that in the long run the ideal thing would be to leverage the any-day-now stats-in-python functionality to have m5 spit out stats directly in the format that these scripts currently generate, making the scripts obsolete. But in the meantime it's a much smaller change to tweak m5 than to edit this pile of scripts, and I don't think it's hurting anyone to put this in there. It is a smaller change, but it's a smaller change that impacts -everybody- (at least theoretically) and only benefits a few people. But it's not a very big change and it sounds like it's temporary anyway (or at least that's the plan) so it's probably ok. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/610/#review1025 --- On 2011-03-29 09:43:16, brad danofsky wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/610/ --- (Updated 2011-03-29 09:43:16) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Add the user settable separator string for arrayed stats, default is standard :: I updated the diff to fix Gabes issues and I learned how to spell. Diffs - src/base/statistics.hh d8587c913ccf src/base/statistics.cc d8587c913ccf src/base/stats/info.hh d8587c913ccf src/base/stats/text.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/610/diff Testing --- standard full regression Thanks, brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I'd prefer to see us just start updating m5-stable more regularly so it can fulfill its original purpose. We keep discussing this but never actually follow through. Is this any harder than just setting up a cronjob to push whatever is in m5-dev to m5-stable once per month (?) - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: sim: typecast Tick to UTick for eventQ assert
changeset d54b7775a6b0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d54b7775a6b0
description:
sim: typecast Tick to UTick for eventQ assert
diffstat:
src/sim/eventq.hh | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diffs (23 lines):
diff -r 6ae58f06a41c -r d54b7775a6b0 src/sim/eventq.hh
--- a/src/sim/eventq.hh Tue Mar 29 13:04:19 2011 -0400
+++ b/src/sim/eventq.hh Tue Mar 29 19:36:36 2011 -0400
@@ -486,6 +486,8 @@
inline void
EventQueue::schedule(Event *event, Tick when)
{
+// Typecasting Tick-Utick here since gcc
+// complains about signed overflow
assert((UTick)when = (UTick)curTick());
assert(!event-scheduled());
assert(event-initialized());
@@ -523,7 +525,9 @@
inline void
EventQueue::reschedule(Event *event, Tick when, bool always)
{
-assert(when = curTick());
+// Typecasting Tick-Utick here since gcc
+// complains about signed overflow
+assert((UTick)when = (UTick)curTick());
assert(always || event-scheduled());
assert(event-initialized());
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
You could do that, but there is no guarentee you'd pick a non-broken version to push. We wouldn't want to push anything from the last week with all the compilation issues. Ali On Mar 29, 2011, at 6:19 PM, Korey Sewell wrote: I'd prefer to see us just start updating m5-stable more regularly so it can fulfill its original purpose. We keep discussing this but never actually follow through. Is this any harder than just setting up a cronjob to push whatever is in m5-dev to m5-stable once per month (?) - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
