Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
I am looking in to why the tests failed. -- Nilay On Thu, 23 Dec 2010, Cron Daemon wrote: scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_changePermission.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalOwnerValid.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_recordLocalSharerInDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalSharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharersExceptRequestor.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyDirToCache.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharers.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getStateStr.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getDirectoryEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeSharerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getL2CacheEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeOwnerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyCacheStateToDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeAllLocalSharersFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isOnlySharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/MachineType.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_mandatory_request_type_to_event.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isCacheTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getLocalSharers.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getLocalOwner.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_changePermission.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isCacheTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isDirTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_recordNewLocalExclusiveInDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_getCacheEntry.fo] Error 1 scons: ***
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
Don't forget to compile m5.fast. Things are compiled differently in m5.debug/m5.opt and m5.fast Nate On Thu, Dec 23, 2010 at 6:52 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I am looking in to why the tests failed. -- Nilay On Thu, 23 Dec 2010, Cron Daemon wrote: scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_changePermission.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalOwnerValid.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_recordLocalSharerInDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalSharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharersExceptRequestor.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyDirToCache.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharers.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getStateStr.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getDirectoryEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeSharerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getL2CacheEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeOwnerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyCacheStateToDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeAllLocalSharersFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isOnlySharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/MachineType.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_mandatory_request_type_to_event.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isCacheTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getLocalSharers.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getLocalOwner.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_changePermission.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isCacheTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isDirTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_recordNewLocalExclusiveInDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_getState.fo] Error 1 scons: ***
Re: [m5-dev] Review Request: trace: reimplement the DTRACE function so it doesn't use a vector
On 2010-12-21 22:44:19, Steve Reinhardt wrote: The name trace flags doesn't bother me, but debug flags is OK too. I wouldn't want to be more generic than that though. Nathan Binkert wrote: I was thinking of adding a command line option for --debug-flags, but leaving the --trace-flags one there as well. Sound reasonable? Steve Reinhardt wrote: Is there a real need for backward compatibility? Maybe we could have --trace-flags print a polite error message letting people know that the option has been renamed, so people's brains have time to retrain themselves, but if we really want to start using the new name then hanging on to the old option is only going to prolong the confusion IMO. Others may differ... I guess not. I thought you (and others) might complain. I'll add an error message for --trace-flags, but I'll convert everything to debug flags. - Nathan --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/352/#review564 --- On 2010-12-21 08:36:19, Nathan Binkert wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/352/ --- (Updated 2010-12-21 08:36:19) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- trace: reimplement the DTRACE function so it doesn't use a vector One question I have about this stuff is if I should call everything trace, or debug? This diff is somewhat confused about that (some things are trace and some things are debug) and I expect to fix it. We always called this stuff trace flags in the past, but we I would like to start using these flags for other things. For example, turning on and off debugging breakpoints of different kinds. Execution tracing is a totally different mechanism but does use trace flags. My personal inclination is that trace flag is probably a bad name, but perhaps debug is a bad name too. Just call it flags? Or SimFlags? Diffs - src/SConscript 4a3bddd74f36 src/arch/alpha/interrupts.hh 4a3bddd74f36 src/arch/alpha/kernel_stats.cc 4a3bddd74f36 src/arch/alpha/linux/process.cc 4a3bddd74f36 src/arch/alpha/linux/system.cc 4a3bddd74f36 src/arch/alpha/process.cc 4a3bddd74f36 src/arch/alpha/remote_gdb.cc 4a3bddd74f36 src/arch/alpha/stacktrace.hh 4a3bddd74f36 src/arch/alpha/system.cc 4a3bddd74f36 src/arch/alpha/tlb.cc 4a3bddd74f36 src/arch/alpha/vtophys.cc 4a3bddd74f36 src/arch/arm/faults.cc 4a3bddd74f36 src/arch/arm/isa.hh 4a3bddd74f36 src/arch/arm/isa.cc 4a3bddd74f36 src/arch/arm/isa/includes.isa 4a3bddd74f36 src/arch/arm/nativetrace.cc 4a3bddd74f36 src/arch/arm/predecoder.cc 4a3bddd74f36 src/arch/arm/process.cc 4a3bddd74f36 src/arch/arm/remote_gdb.cc 4a3bddd74f36 src/arch/arm/stacktrace.hh 4a3bddd74f36 src/arch/arm/tlb.cc 4a3bddd74f36 src/arch/mips/faults.cc 4a3bddd74f36 src/arch/mips/isa.cc 4a3bddd74f36 src/arch/mips/isa/includes.isa 4a3bddd74f36 src/arch/mips/linux/process.cc 4a3bddd74f36 src/arch/mips/locked_mem.hh 4a3bddd74f36 src/arch/mips/process.cc 4a3bddd74f36 src/arch/mips/stacktrace.hh 4a3bddd74f36 src/arch/mips/tlb.cc 4a3bddd74f36 src/arch/power/process.cc 4a3bddd74f36 src/arch/power/stacktrace.hh 4a3bddd74f36 src/arch/power/tlb.cc 4a3bddd74f36 src/arch/sparc/interrupts.hh 4a3bddd74f36 src/arch/sparc/isa.cc 4a3bddd74f36 src/arch/sparc/isa/includes.isa 4a3bddd74f36 src/arch/sparc/process.cc 4a3bddd74f36 src/arch/sparc/remote_gdb.cc 4a3bddd74f36 src/arch/sparc/stacktrace.hh 4a3bddd74f36 src/arch/sparc/tlb.cc 4a3bddd74f36 src/arch/sparc/ua2005.cc 4a3bddd74f36 src/arch/sparc/vtophys.cc 4a3bddd74f36 src/arch/x86/faults.cc 4a3bddd74f36 src/arch/x86/insts/microregop.cc 4a3bddd74f36 src/arch/x86/insts/static_inst.hh 4a3bddd74f36 src/arch/x86/interrupts.cc 4a3bddd74f36 src/arch/x86/isa/includes.isa 4a3bddd74f36 src/arch/x86/nativetrace.cc 4a3bddd74f36 src/arch/x86/pagetable_walker.cc 4a3bddd74f36 src/arch/x86/predecoder.hh 4a3bddd74f36 src/arch/x86/predecoder.cc 4a3bddd74f36 src/arch/x86/process.cc 4a3bddd74f36 src/arch/x86/stacktrace.hh 4a3bddd74f36 src/arch/x86/tlb.cc 4a3bddd74f36 src/base/debug.hh 4a3bddd74f36 src/base/debug.cc 4a3bddd74f36 src/base/loader/aout_object.cc 4a3bddd74f36 src/base/loader/ecoff_object.cc 4a3bddd74f36 src/base/loader/elf_object.cc 4a3bddd74f36 src/base/loader/raw_object.cc 4a3bddd74f36 src/base/mysql.cc 4a3bddd74f36 src/base/remote_gdb.cc 4a3bddd74f36 src/base/trace.hh 4a3bddd74f36 src/base/trace.cc 4a3bddd74f36
Re: [m5-dev] Review Request: Make commenting on close namespace brackets consistent.
On 2010-12-22 18:23:20, Nathan Binkert wrote: I only looked at a few. I hope that you don't expect anyone to read them all. Anyway, did you have any worthwhile regexes to put in the commit message? You only need to read them all if you want to retain your right to complain about the result... - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/#review574 --- On 2010-12-22 17:39:40, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/ --- (Updated 2010-12-22 17:39:40) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Make commenting on close namespace brackets consistent. Diffs - src/dev/sinic.hh 42f343470ee3 src/dev/sinic.cc 42f343470ee3 src/dev/sinicreg.hh 42f343470ee3 src/dev/x86/cmos.hh 42f343470ee3 src/dev/x86/i8042.hh 42f343470ee3 src/dev/x86/i82094aa.hh 42f343470ee3 src/dev/x86/i8237.hh 42f343470ee3 src/dev/x86/i8254.hh 42f343470ee3 src/dev/x86/i8259.hh 42f343470ee3 src/dev/x86/intdev.hh 42f343470ee3 src/dev/x86/speaker.hh 42f343470ee3 src/kern/kernel_stats.hh 42f343470ee3 src/kern/kernel_stats.cc 42f343470ee3 src/mem/ruby/common/Address.hh 42f343470ee3 src/sim/core.hh 42f343470ee3 src/sim/core.cc 42f343470ee3 src/sim/insttracer.hh 42f343470ee3 src/sim/pseudo_inst.hh 42f343470ee3 src/sim/pseudo_inst.cc 42f343470ee3 src/sim/stat_control.hh 42f343470ee3 src/sim/stat_control.cc 42f343470ee3 src/base/trace.hh 42f343470ee3 src/base/trace.cc 42f343470ee3 src/base/varargs.hh 42f343470ee3 src/cpu/exetrace.hh 42f343470ee3 src/cpu/exetrace.cc 42f343470ee3 src/cpu/inorder/inorder_trace.hh 42f343470ee3 src/cpu/inorder/inorder_trace.cc 42f343470ee3 src/cpu/inteltrace.hh 42f343470ee3 src/cpu/inteltrace.cc 42f343470ee3 src/cpu/legiontrace.hh 42f343470ee3 src/cpu/legiontrace.cc 42f343470ee3 src/cpu/nativetrace.hh 42f343470ee3 src/cpu/nativetrace.cc 42f343470ee3 src/dev/copy_engine_defs.hh 42f343470ee3 src/dev/i8254xGBe_defs.hh 42f343470ee3 src/arch/power/insts/integer.hh 42f343470ee3 src/arch/power/insts/mem.hh 42f343470ee3 src/arch/power/insts/misc.hh 42f343470ee3 src/arch/power/insts/static_inst.hh 42f343470ee3 src/arch/power/isa.hh 42f343470ee3 src/arch/power/isa_traits.hh 42f343470ee3 src/arch/power/locked_mem.hh 42f343470ee3 src/arch/power/microcode_rom.hh 42f343470ee3 src/arch/power/miscregs.hh 42f343470ee3 src/arch/power/mmaped_ipr.hh 42f343470ee3 src/arch/power/pagetable.hh 42f343470ee3 src/arch/power/pagetable.cc 42f343470ee3 src/arch/power/predecoder.hh 42f343470ee3 src/arch/power/registers.hh 42f343470ee3 src/arch/power/remote_gdb.hh 42f343470ee3 src/arch/power/stacktrace.hh 42f343470ee3 src/arch/power/tlb.hh 42f343470ee3 src/arch/power/types.hh 42f343470ee3 src/arch/power/utility.hh 42f343470ee3 src/arch/power/utility.cc 42f343470ee3 src/arch/power/vtophys.hh 42f343470ee3 src/arch/sparc/faults.hh 42f343470ee3 src/arch/sparc/kernel_stats.hh 42f343470ee3 src/arch/sparc/nativetrace.hh 42f343470ee3 src/arch/sparc/nativetrace.cc 42f343470ee3 src/arch/sparc/tlb.cc 42f343470ee3 src/arch/sparc/vtophys.cc 42f343470ee3 src/arch/x86/cpuid.cc 42f343470ee3 src/arch/x86/nativetrace.hh 42f343470ee3 src/arch/x86/nativetrace.cc 42f343470ee3 src/arch/x86/registers.hh 42f343470ee3 src/arch/x86/tlb.cc 42f343470ee3 src/arch/x86/utility.cc 42f343470ee3 src/base/cprintf.hh 42f343470ee3 src/base/cprintf.cc 42f343470ee3 src/base/hashmap.hh 42f343470ee3 src/base/inet.hh 42f343470ee3 src/base/inet.cc 42f343470ee3 src/base/mysql.hh 42f343470ee3 src/base/mysql.cc 42f343470ee3 src/base/statistics.hh 42f343470ee3 src/base/statistics.cc 42f343470ee3 src/base/stats/info.hh 42f343470ee3 src/base/stats/mysql.hh 42f343470ee3 src/base/stats/mysql.cc 42f343470ee3 src/base/stats/mysql_run.hh 42f343470ee3 src/base/stats/output.hh 42f343470ee3 src/base/stats/output.cc 42f343470ee3 src/base/stats/text.hh 42f343470ee3 src/base/stats/text.cc 42f343470ee3 src/base/stats/types.hh 42f343470ee3 src/base/stats/visit.hh 42f343470ee3 src/base/stats/visit.cc 42f343470ee3 src/base/stl_helpers.hh 42f343470ee3 src/arch/arm/nativetrace.cc 42f343470ee3 src/arch/arm/tlb.hh 42f343470ee3 src/arch/mips/dsp.hh 42f343470ee3 src/arch/mips/faults.hh 42f343470ee3 src/arch/mips/isa_traits.hh 42f343470ee3 src/arch/mips/kernel_stats.hh 42f343470ee3
Re: [m5-dev] Review Request: Make commenting on close namespace brackets consistent.
On 2010-12-22 18:23:20, Nathan Binkert wrote: I only looked at a few. I hope that you don't expect anyone to read them all. Anyway, did you have any worthwhile regexes to put in the commit message? Steve Reinhardt wrote: You only need to read them all if you want to retain your right to complain about the result... I just realized that you didn't do anything in SCons files, .py files, .sm files, or .i files. There's a lot of generated code out there :) - Nathan --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/#review574 --- On 2010-12-22 17:39:40, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/ --- (Updated 2010-12-22 17:39:40) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Make commenting on close namespace brackets consistent. Diffs - src/dev/sinic.hh 42f343470ee3 src/dev/sinic.cc 42f343470ee3 src/dev/sinicreg.hh 42f343470ee3 src/dev/x86/cmos.hh 42f343470ee3 src/dev/x86/i8042.hh 42f343470ee3 src/dev/x86/i82094aa.hh 42f343470ee3 src/dev/x86/i8237.hh 42f343470ee3 src/dev/x86/i8254.hh 42f343470ee3 src/dev/x86/i8259.hh 42f343470ee3 src/dev/x86/intdev.hh 42f343470ee3 src/dev/x86/speaker.hh 42f343470ee3 src/kern/kernel_stats.hh 42f343470ee3 src/kern/kernel_stats.cc 42f343470ee3 src/mem/ruby/common/Address.hh 42f343470ee3 src/sim/core.hh 42f343470ee3 src/sim/core.cc 42f343470ee3 src/sim/insttracer.hh 42f343470ee3 src/sim/pseudo_inst.hh 42f343470ee3 src/sim/pseudo_inst.cc 42f343470ee3 src/sim/stat_control.hh 42f343470ee3 src/sim/stat_control.cc 42f343470ee3 src/base/trace.hh 42f343470ee3 src/base/trace.cc 42f343470ee3 src/base/varargs.hh 42f343470ee3 src/cpu/exetrace.hh 42f343470ee3 src/cpu/exetrace.cc 42f343470ee3 src/cpu/inorder/inorder_trace.hh 42f343470ee3 src/cpu/inorder/inorder_trace.cc 42f343470ee3 src/cpu/inteltrace.hh 42f343470ee3 src/cpu/inteltrace.cc 42f343470ee3 src/cpu/legiontrace.hh 42f343470ee3 src/cpu/legiontrace.cc 42f343470ee3 src/cpu/nativetrace.hh 42f343470ee3 src/cpu/nativetrace.cc 42f343470ee3 src/dev/copy_engine_defs.hh 42f343470ee3 src/dev/i8254xGBe_defs.hh 42f343470ee3 src/arch/power/insts/integer.hh 42f343470ee3 src/arch/power/insts/mem.hh 42f343470ee3 src/arch/power/insts/misc.hh 42f343470ee3 src/arch/power/insts/static_inst.hh 42f343470ee3 src/arch/power/isa.hh 42f343470ee3 src/arch/power/isa_traits.hh 42f343470ee3 src/arch/power/locked_mem.hh 42f343470ee3 src/arch/power/microcode_rom.hh 42f343470ee3 src/arch/power/miscregs.hh 42f343470ee3 src/arch/power/mmaped_ipr.hh 42f343470ee3 src/arch/power/pagetable.hh 42f343470ee3 src/arch/power/pagetable.cc 42f343470ee3 src/arch/power/predecoder.hh 42f343470ee3 src/arch/power/registers.hh 42f343470ee3 src/arch/power/remote_gdb.hh 42f343470ee3 src/arch/power/stacktrace.hh 42f343470ee3 src/arch/power/tlb.hh 42f343470ee3 src/arch/power/types.hh 42f343470ee3 src/arch/power/utility.hh 42f343470ee3 src/arch/power/utility.cc 42f343470ee3 src/arch/power/vtophys.hh 42f343470ee3 src/arch/sparc/faults.hh 42f343470ee3 src/arch/sparc/kernel_stats.hh 42f343470ee3 src/arch/sparc/nativetrace.hh 42f343470ee3 src/arch/sparc/nativetrace.cc 42f343470ee3 src/arch/sparc/tlb.cc 42f343470ee3 src/arch/sparc/vtophys.cc 42f343470ee3 src/arch/x86/cpuid.cc 42f343470ee3 src/arch/x86/nativetrace.hh 42f343470ee3 src/arch/x86/nativetrace.cc 42f343470ee3 src/arch/x86/registers.hh 42f343470ee3 src/arch/x86/tlb.cc 42f343470ee3 src/arch/x86/utility.cc 42f343470ee3 src/base/cprintf.hh 42f343470ee3 src/base/cprintf.cc 42f343470ee3 src/base/hashmap.hh 42f343470ee3 src/base/inet.hh 42f343470ee3 src/base/inet.cc 42f343470ee3 src/base/mysql.hh 42f343470ee3 src/base/mysql.cc 42f343470ee3 src/base/statistics.hh 42f343470ee3 src/base/statistics.cc 42f343470ee3 src/base/stats/info.hh 42f343470ee3 src/base/stats/mysql.hh 42f343470ee3 src/base/stats/mysql.cc 42f343470ee3 src/base/stats/mysql_run.hh 42f343470ee3 src/base/stats/output.hh 42f343470ee3 src/base/stats/output.cc 42f343470ee3 src/base/stats/text.hh 42f343470ee3 src/base/stats/text.cc 42f343470ee3 src/base/stats/types.hh 42f343470ee3 src/base/stats/visit.hh 42f343470ee3 src/base/stats/visit.cc 42f343470ee3 src/base/stl_helpers.hh 42f343470ee3 src/arch/arm/nativetrace.cc 42f343470ee3 src/arch/arm/tlb.hh
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
I ran the regression tests on a fresh m5 clone for the two MOESI protocols and they pass. Can some one explain to me what the error messages mean? Can I have look at the file - /z/m5/regression/regress-2010-12-23-03:00:01? -- Nilay On Thu, 23 Dec 2010, nathan binkert wrote: Don't forget to compile m5.fast. Things are compiled differently in m5.debug/m5.opt and m5.fast Nate On Thu, Dec 23, 2010 at 6:52 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I am looking in to why the tests failed. -- Nilay On Thu, 23 Dec 2010, Cron Daemon wrote: scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_changePermission.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalOwnerValid.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_recordLocalSharerInDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalSharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharersExceptRequestor.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyDirToCache.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharers.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getStateStr.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getDirectoryEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeSharerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getL2CacheEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeOwnerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyCacheStateToDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeAllLocalSharersFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isOnlySharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/MachineType.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_mandatory_request_type_to_event.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isCacheTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getLocalSharers.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getLocalOwner.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_changePermission.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isCacheTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isDirTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_recordNewLocalExclusiveInDir.fo] Error 1 scons: ***
Re: [m5-dev] Review Request: trace: reimplement the DTRACE function so it doesn't use a vector
On Thu, Dec 23, 2010 at 7:05 AM, Nathan Binkert n...@binkert.org wrote: On December 22nd, 2010, 4:23 p.m., *Steve Reinhardt* wrote: Is there a real need for backward compatibility? Maybe we could have --trace-flags print a polite error message letting people know that the option has been renamed, so people's brains have time to retrain themselves, but if we really want to start using the new name then hanging on to the old option is only going to prolong the confusion IMO. Others may differ... I guess not. I thought you (and others) might complain. I'll add an error message for --trace-flags, but I'll convert everything to debug flags. (switching to regular email... these nested conversations via reviewboard get awkward IMO) I didn't say I won't complain ;-). However, if we're going to switch, let's be serious about it and not go halfway. It didn't occur to me before that there are several other arguments that get affected: --trace-help, --trace-start, --trace-file, and --trace-ignore. Are you planning on just doing s/trace/debug/ on all of these? I guess that's OK; the only one I worry about is --debug-help, which seems like it's asking for a lot more than just listing flags. I don't think we need error messages on all of them (since none of them make sense w/o --trace-flags anyway). The other interesting thing is that --debug-break now fits in with this group, for better or for worse. I like that it's not so lonely anymore, but it's the only one that's not related to flags. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: trace: reimplement the DTRACE function so it doesn't use a vector
(switching to regular email... these nested conversations via reviewboard get awkward IMO) I didn't say I won't complain ;-). However, if we're going to switch, let's be serious about it and not go halfway. Sounds reasonable. It didn't occur to me before that there are several other arguments that get affected: --trace-help, --trace-start, --trace-file, and --trace-ignore. Are you planning on just doing s/trace/debug/ on all of these? I guess that's OK; the only one I worry about is --debug-help, which seems like it's asking for a lot more than just listing flags. I don't think we need error messages on all of them (since none of them make sense w/o --trace-flags anyway). I agree. I'd only put the error message on --trace-flags. Instead of --debug-help, we could just do --debug-flags-help The other interesting thing is that --debug-break now fits in with this group, for better or for worse. I like that it's not so lonely anymore, but it's the only one that's not related to flags. I was actually thinking that it was nice. Debug::breakpoint() was something that I wanted to enable/disable with flags. For example, it'd be nice to have intelligently placed breakpoints for things like startup(), module initialization (if using m5 as a python lib), instantiation, etc. The one that I want the most is startup() so that the simulator stops and you can do things like call functions. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
I ran the regression tests on a fresh m5 clone for the two MOESI protocols and they pass. Can some one explain to me what the error messages mean? Can I have look at the file - /z/m5/regression/regress-2010-12-23-03:00:01? I've just made regressions available at: http://zizzer.eecs.umich.edu/regress It uses our standard user/pw for access. I'll send this to Nilay directly. Nate ___ 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
Did you try with debug, opt, and fast? I see these errors a lot in the regressions: /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:127: warning: no return statement in function returning non-void /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:170: warning: no return statement in function returning non-void cc1plus: warnings being treated as errors If you're not seeing that with any of the builds, maybe you're using a different gcc version... zizzer has 4.2.4. Or maybe something's just messed up on zizzer... let me know if you think those errors are bogus. Steve On Thu, Dec 23, 2010 at 7:36 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I ran the regression tests on a fresh m5 clone for the two MOESI protocols and they pass. Can some one explain to me what the error messages mean? Can I have look at the file - /z/m5/regression/regress-2010-12-23-03:00:01? -- Nilay On Thu, 23 Dec 2010, nathan binkert wrote: Don't forget to compile m5.fast. Things are compiled differently in m5.debug/m5.opt and m5.fast Nate On Thu, Dec 23, 2010 at 6:52 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I am looking in to why the tests failed. -- Nilay On Thu, 23 Dec 2010, Cron Daemon wrote: scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_changePermission.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalOwnerValid.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_recordLocalSharerInDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalSharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharersExceptRequestor.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyDirToCache.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharers.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getStateStr.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getDirectoryEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeSharerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getL2CacheEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeOwnerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyCacheStateToDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeAllLocalSharersFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isOnlySharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/MachineType.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_mandatory_request_type_to_event.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isCacheTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Wakeup.fo] Error 1 scons: ***
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I am using GCC 4.4, I never see any of these warnings. Let me try with 4.2.4. Nilay On Thu, 23 Dec 2010, Steve Reinhardt wrote: Did you try with debug, opt, and fast? I see these errors a lot in the regressions: /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:127: warning: no return statement in function returning non-void /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:170: warning: no return statement in function returning non-void cc1plus: warnings being treated as errors If you're not seeing that with any of the builds, maybe you're using a different gcc version... zizzer has 4.2.4. Or maybe something's just messed up on zizzer... let me know if you think those errors are bogus. Steve On Thu, Dec 23, 2010 at 7:36 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I ran the regression tests on a fresh m5 clone for the two MOESI protocols and they pass. Can some one explain to me what the error messages mean? Can I have look at the file - /z/m5/regression/regress-2010-12-23-03:00:01? -- Nilay On Thu, 23 Dec 2010, nathan binkert wrote: Don't forget to compile m5.fast. Things are compiled differently in m5.debug/m5.opt and m5.fast Nate On Thu, Dec 23, 2010 at 6:52 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I am looking in to why the tests failed. -- Nilay On Thu, 23 Dec 2010, Cron Daemon wrote: scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_changePermission.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalOwnerValid.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_recordLocalSharerInDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isLocalSharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharersExceptRequestor.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyDirToCache.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_countLocalSharers.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getStateStr.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getDirectoryEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeSharerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_getL2CacheEntry.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Controller.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/DMA_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeOwnerFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_copyCacheStateToDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_removeAllLocalSharersFromDir.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_isOnlySharer.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/Directory_getState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockShared.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/MachineType.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_mandatory_request_type_to_event.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Wakeup.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isCacheTagPresent.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_isBlockExclusive.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_setState.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L1Cache_Transitions.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Wakeup.fo] Error 1 scons: ***
Re: [m5-dev] Review Request: Make commenting on close namespace brackets consistent.
On 2010-12-22 18:23:20, Nathan Binkert wrote: I only looked at a few. I hope that you don't expect anyone to read them all. Anyway, did you have any worthwhile regexes to put in the commit message? Steve Reinhardt wrote: You only need to read them all if you want to retain your right to complain about the result... Nathan Binkert wrote: I just realized that you didn't do anything in SCons files, .py files, .sm files, or .i files. There's a lot of generated code out there :) Good point, just took care of it. Just a handful of spots that needed to be fixed up. - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/#review574 --- On 2010-12-22 17:39:40, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/ --- (Updated 2010-12-22 17:39:40) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Make commenting on close namespace brackets consistent. Diffs - src/dev/sinic.hh 42f343470ee3 src/dev/sinic.cc 42f343470ee3 src/dev/sinicreg.hh 42f343470ee3 src/dev/x86/cmos.hh 42f343470ee3 src/dev/x86/i8042.hh 42f343470ee3 src/dev/x86/i82094aa.hh 42f343470ee3 src/dev/x86/i8237.hh 42f343470ee3 src/dev/x86/i8254.hh 42f343470ee3 src/dev/x86/i8259.hh 42f343470ee3 src/dev/x86/intdev.hh 42f343470ee3 src/dev/x86/speaker.hh 42f343470ee3 src/kern/kernel_stats.hh 42f343470ee3 src/kern/kernel_stats.cc 42f343470ee3 src/mem/ruby/common/Address.hh 42f343470ee3 src/sim/core.hh 42f343470ee3 src/sim/core.cc 42f343470ee3 src/sim/insttracer.hh 42f343470ee3 src/sim/pseudo_inst.hh 42f343470ee3 src/sim/pseudo_inst.cc 42f343470ee3 src/sim/stat_control.hh 42f343470ee3 src/sim/stat_control.cc 42f343470ee3 src/base/trace.hh 42f343470ee3 src/base/trace.cc 42f343470ee3 src/base/varargs.hh 42f343470ee3 src/cpu/exetrace.hh 42f343470ee3 src/cpu/exetrace.cc 42f343470ee3 src/cpu/inorder/inorder_trace.hh 42f343470ee3 src/cpu/inorder/inorder_trace.cc 42f343470ee3 src/cpu/inteltrace.hh 42f343470ee3 src/cpu/inteltrace.cc 42f343470ee3 src/cpu/legiontrace.hh 42f343470ee3 src/cpu/legiontrace.cc 42f343470ee3 src/cpu/nativetrace.hh 42f343470ee3 src/cpu/nativetrace.cc 42f343470ee3 src/dev/copy_engine_defs.hh 42f343470ee3 src/dev/i8254xGBe_defs.hh 42f343470ee3 src/arch/power/insts/integer.hh 42f343470ee3 src/arch/power/insts/mem.hh 42f343470ee3 src/arch/power/insts/misc.hh 42f343470ee3 src/arch/power/insts/static_inst.hh 42f343470ee3 src/arch/power/isa.hh 42f343470ee3 src/arch/power/isa_traits.hh 42f343470ee3 src/arch/power/locked_mem.hh 42f343470ee3 src/arch/power/microcode_rom.hh 42f343470ee3 src/arch/power/miscregs.hh 42f343470ee3 src/arch/power/mmaped_ipr.hh 42f343470ee3 src/arch/power/pagetable.hh 42f343470ee3 src/arch/power/pagetable.cc 42f343470ee3 src/arch/power/predecoder.hh 42f343470ee3 src/arch/power/registers.hh 42f343470ee3 src/arch/power/remote_gdb.hh 42f343470ee3 src/arch/power/stacktrace.hh 42f343470ee3 src/arch/power/tlb.hh 42f343470ee3 src/arch/power/types.hh 42f343470ee3 src/arch/power/utility.hh 42f343470ee3 src/arch/power/utility.cc 42f343470ee3 src/arch/power/vtophys.hh 42f343470ee3 src/arch/sparc/faults.hh 42f343470ee3 src/arch/sparc/kernel_stats.hh 42f343470ee3 src/arch/sparc/nativetrace.hh 42f343470ee3 src/arch/sparc/nativetrace.cc 42f343470ee3 src/arch/sparc/tlb.cc 42f343470ee3 src/arch/sparc/vtophys.cc 42f343470ee3 src/arch/x86/cpuid.cc 42f343470ee3 src/arch/x86/nativetrace.hh 42f343470ee3 src/arch/x86/nativetrace.cc 42f343470ee3 src/arch/x86/registers.hh 42f343470ee3 src/arch/x86/tlb.cc 42f343470ee3 src/arch/x86/utility.cc 42f343470ee3 src/base/cprintf.hh 42f343470ee3 src/base/cprintf.cc 42f343470ee3 src/base/hashmap.hh 42f343470ee3 src/base/inet.hh 42f343470ee3 src/base/inet.cc 42f343470ee3 src/base/mysql.hh 42f343470ee3 src/base/mysql.cc 42f343470ee3 src/base/statistics.hh 42f343470ee3 src/base/statistics.cc 42f343470ee3 src/base/stats/info.hh 42f343470ee3 src/base/stats/mysql.hh 42f343470ee3 src/base/stats/mysql.cc 42f343470ee3 src/base/stats/mysql_run.hh 42f343470ee3 src/base/stats/output.hh 42f343470ee3 src/base/stats/output.cc 42f343470ee3 src/base/stats/text.hh 42f343470ee3 src/base/stats/text.cc 42f343470ee3 src/base/stats/types.hh 42f343470ee3 src/base/stats/visit.hh 42f343470ee3 src/base/stats/visit.cc
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Steve, you had commented that panic() and fatal() are marked as no return. Then, why should these warnings appear? And why would the compiler be fine with ERROR_MSG? -- Nilay On Thu, 23 Dec 2010, Nilay Vaish wrote: I am using GCC 4.4, I never see any of these warnings. Let me try with 4.2.4. Nilay On Thu, 23 Dec 2010, Steve Reinhardt wrote: Did you try with debug, opt, and fast? I see these errors a lot in the regressions: /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:127: warning: no return statement in function returning non-void /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:170: warning: no return statement in function returning non-void cc1plus: warnings being treated as errors If you're not seeing that with any of the builds, maybe you're using a different gcc version... zizzer has 4.2.4. Or maybe something's just messed up on zizzer... let me know if you think those errors are bogus. Steve On Thu, Dec 23, 2010 at 7:36 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I ran the regression tests on a fresh m5 clone for the two MOESI protocols and they pass. Can some one explain to me what the error messages mean? Can I have look at the file - /z/m5/regression/regress-2010-12-23-03:00:01? -- Nilay On Thu, 23 Dec 2010, nathan binkert wrote: Don't forget to compile m5.fast. Things are compiled differently in m5.debug/m5.opt and m5.fast Nate On Thu, Dec 23, 2010 at 6:52 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I am looking in to why the tests failed. -- Nilay 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 ___ 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 ___ 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
It could be an issue with gcc 4.2.4 not properly handling the no return attribute in some cases... that being a bug that's fixed in 4.4 would explain why it works for you. That's just speculation on my part though. Does anyone else have any experience with this? Does the error go away on 4.2.4 if you put the dead 'return' statement back in the particular place that it's complaining about? Steve On Thu, Dec 23, 2010 at 8:12 AM, Nilay Vaish ni...@cs.wisc.edu wrote: Steve, you had commented that panic() and fatal() are marked as no return. Then, why should these warnings appear? And why would the compiler be fine with ERROR_MSG? -- Nilay On Thu, 23 Dec 2010, Nilay Vaish wrote: I am using GCC 4.4, I never see any of these warnings. Let me try with 4.2.4. Nilay On Thu, 23 Dec 2010, Steve Reinhardt wrote: Did you try with debug, opt, and fast? I see these errors a lot in the regressions: /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:127: warning: no return statement in function returning non-void /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:170: warning: no return statement in function returning non-void cc1plus: warnings being treated as errors If you're not seeing that with any of the builds, maybe you're using a different gcc version... zizzer has 4.2.4. Or maybe something's just messed up on zizzer... let me know if you think those errors are bogus. Steve On Thu, Dec 23, 2010 at 7:36 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I ran the regression tests on a fresh m5 clone for the two MOESI protocols and they pass. Can some one explain to me what the error messages mean? Can I have look at the file - /z/m5/regression/regress-2010-12-23-03:00:01? -- Nilay On Thu, 23 Dec 2010, nathan binkert wrote: Don't forget to compile m5.fast. Things are compiled differently in m5.debug/m5.opt and m5.fast Nate On Thu, Dec 23, 2010 at 6:52 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I am looking in to why the tests failed. -- Nilay 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 ___ 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 ___ 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] Cron m5test@zizzer /z/m5/regression/do-regression quick
I do not have GCC 4.2.4, but with GCC 4.2.2 I do not see those warnings. On Thu, 23 Dec 2010, Steve Reinhardt wrote: It could be an issue with gcc 4.2.4 not properly handling the no return attribute in some cases... that being a bug that's fixed in 4.4 would explain why it works for you. That's just speculation on my part though. Does anyone else have any experience with this? Does the error go away on 4.2.4 if you put the dead 'return' statement back in the particular place that it's complaining about? Steve On Thu, Dec 23, 2010 at 8:12 AM, Nilay Vaish ni...@cs.wisc.edu wrote: Steve, you had commented that panic() and fatal() are marked as no return. Then, why should these warnings appear? And why would the compiler be fine with ERROR_MSG? -- Nilay On Thu, 23 Dec 2010, Nilay Vaish wrote: I am using GCC 4.4, I never see any of these warnings. Let me try with 4.2.4. Nilay On Thu, 23 Dec 2010, Steve Reinhardt wrote: Did you try with debug, opt, and fast? I see these errors a lot in the regressions: /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:127: warning: no return statement in function returning non-void /z/m5/regression/zizzer/m5/build/ALPHA_SE_MOESI_CMP_directory/mem/ruby/system/PerfectCacheMemory.hh:170: warning: no return statement in function returning non-void cc1plus: warnings being treated as errors If you're not seeing that with any of the builds, maybe you're using a different gcc version... zizzer has 4.2.4. Or maybe something's just messed up on zizzer... let me know if you think those errors are bogus. Steve ___ 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 am able to reproduce the warning. But I have to compile the files on my
own (as in, write the compilation command on the command line) in order to
reproduce the warning.
This is the proposed patch.
--
Nilay
diff --git a/src/mem/ruby/system/PerfectCacheMemory.hh
b/src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh
@@ -124,6 +124,7 @@
bool block_stc, ENTRY* entry)
{
panic(not implemented);
+return true;
}
// tests to see if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemoryENTRY::cacheProbe(const Address newAddress) const
{
panic(cacheProbe called in perfect cache);
+return newAddress;
}
// looks an address up in the cache
On Thu, 23 Dec 2010, Nilay Vaish wrote:
I do not have GCC 4.2.4, but with GCC 4.2.2 I do not see those warnings.
On Thu, 23 Dec 2010, Steve Reinhardt wrote:
It could be an issue with gcc 4.2.4 not properly handling the no return
attribute in some cases... that being a bug that's fixed in 4.4 would
explain why it works for you. That's just speculation on my part though.
Does anyone else have any experience with this? Does the error go away on
4.2.4 if you put the dead 'return' statement back in the particular place
that it's complaining about?
Steve
On Thu, Dec 23, 2010 at 8:12 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
Steve, you had commented that panic() and fatal() are marked as no
return. Then, why should these warnings appear? And why would the
compiler
be fine with ERROR_MSG?
--
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: PerfectCacheMemory: Add return statements to tw...
changeset fbf4b1b18202 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fbf4b1b18202
description:
PerfectCacheMemory: Add return statements to two functions.
Two functions in src/mem/ruby/system/PerfectCacheMemory.hh,
tryCacheAccess()
and cacheProbe(), end with calls to panic(). Both of these functions
have
return type other than void. Any file that includes this header file
fails
to compile because of the missing return statement. This patch adds
dummy
values so as to avoid the compiler warnings.
diffstat:
src/mem/ruby/system/PerfectCacheMemory.hh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diffs (19 lines):
diff -r f249937228b5 -r fbf4b1b18202 src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh Wed Dec 22 23:15:24 2010 -0600
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh Thu Dec 23 13:36:18 2010 -0600
@@ -124,6 +124,7 @@
bool block_stc, ENTRY* entry)
{
panic(not implemented);
+return true;
}
// tests to see if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemoryENTRY::cacheProbe(const Address newAddress) const
{
panic(cacheProbe called in perfect cache);
+return newAddress;
}
// looks an address up in the cache
___
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
Do you mean you have to enter the compilation command manually to use the
different version of gcc? You can override the default compiler by setting
CC=path as a scons argument (or something like that... typing from memory
here).
Or was there another reason?
Steve
On Thu, Dec 23, 2010 at 11:10 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
I am able to reproduce the warning. But I have to compile the files on my
own (as in, write the compilation command on the command line) in order to
reproduce the warning.
This is the proposed patch.
--
Nilay
diff --git a/src/mem/ruby/system/PerfectCacheMemory.hh
b/src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh
@@ -124,6 +124,7 @@
bool block_stc, ENTRY* entry)
{
panic(not implemented);
+return true;
}
// tests to see if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemoryENTRY::cacheProbe(const Address newAddress) const
{
panic(cacheProbe called in perfect cache);
+return newAddress;
}
// looks an address up in the cache
On Thu, 23 Dec 2010, Nilay Vaish wrote:
I do not have GCC 4.2.4, but with GCC 4.2.2 I do not see those warnings.
On Thu, 23 Dec 2010, Steve Reinhardt wrote:
It could be an issue with gcc 4.2.4 not properly handling the no return
attribute in some cases... that being a bug that's fixed in 4.4 would
explain why it works for you. That's just speculation on my part though.
Does anyone else have any experience with this? Does the error go away
on
4.2.4 if you put the dead 'return' statement back in the particular place
that it's complaining about?
Steve
On Thu, Dec 23, 2010 at 8:12 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
Steve, you had commented that panic() and fatal() are marked as no
return. Then, why should these warnings appear? And why would the
compiler
be fine with ERROR_MSG?
--
Nilay
___
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] Cron m5test@zizzer /z/m5/regression/do-regression quick
Something else must be going on. There are a lot of cases where this
sort of thing happens, so something must be different about the
compilation environment for these files. Perhaps we should try to
compile on zizzer with VERBOSE=True to see what happens. We can also
give Nilay an account on zizzer so he can experiment. Unfortunately,
I don't have time to do that right at the moment.
Nate
I am able to reproduce the warning. But I have to compile the files on my
own (as in, write the compilation command on the command line) in order to
reproduce the warning.
This is the proposed patch.
--
Nilay
diff --git a/src/mem/ruby/system/PerfectCacheMemory.hh
b/src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh
@@ -124,6 +124,7 @@
bool block_stc, ENTRY* entry)
{
panic(not implemented);
+ return true;
}
// tests to see if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemoryENTRY::cacheProbe(const Address newAddress) const
{
panic(cacheProbe called in perfect cache);
+ return newAddress;
}
// looks an address up in the cache
On Thu, 23 Dec 2010, Nilay Vaish wrote:
I do not have GCC 4.2.4, but with GCC 4.2.2 I do not see those warnings.
On Thu, 23 Dec 2010, Steve Reinhardt wrote:
It could be an issue with gcc 4.2.4 not properly handling the no return
attribute in some cases... that being a bug that's fixed in 4.4 would
explain why it works for you. That's just speculation on my part though.
Does anyone else have any experience with this? Does the error go away
on
4.2.4 if you put the dead 'return' statement back in the particular place
that it's complaining about?
Steve
On Thu, Dec 23, 2010 at 8:12 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
Steve, you had commented that panic() and fatal() are marked as no
return. Then, why should these warnings appear? And why would the
compiler
be fine with ERROR_MSG?
--
Nilay
___
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] changeset in m5: PerfectCacheMemory: Add return statements to tw...
I don't want to be overly controlling, but I don't think this is the
correct fix and I don't think you should have committed this
changeset. As a stop gap, I guess this is OK, but this really is not
the right fix.
Nate
On Thu, Dec 23, 2010 at 11:41 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
changeset fbf4b1b18202 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fbf4b1b18202
description:
PerfectCacheMemory: Add return statements to two functions.
Two functions in src/mem/ruby/system/PerfectCacheMemory.hh,
tryCacheAccess()
and cacheProbe(), end with calls to panic(). Both of these functions
have
return type other than void. Any file that includes this header file
fails
to compile because of the missing return statement. This patch adds
dummy
values so as to avoid the compiler warnings.
diffstat:
src/mem/ruby/system/PerfectCacheMemory.hh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diffs (19 lines):
diff -r f249937228b5 -r fbf4b1b18202 src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh Wed Dec 22 23:15:24 2010 -0600
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh Thu Dec 23 13:36:18 2010 -0600
@@ -124,6 +124,7 @@
bool block_stc, ENTRY* entry)
{
panic(not implemented);
+ return true;
}
// tests to see if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemoryENTRY::cacheProbe(const Address newAddress) const
{
panic(cacheProbe called in perfect cache);
+ return newAddress;
}
// looks an address up in the cache
___
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] changeset in m5: PerfectCacheMemory: Add return statements to tw...
I am in complete agreement with you. But I do not want to keep the
repository in a broken state.
Nilay
On Thu, 23 Dec 2010, nathan binkert wrote:
I don't want to be overly controlling, but I don't think this is the
correct fix and I don't think you should have committed this
changeset. As a stop gap, I guess this is OK, but this really is not
the right fix.
Nate
On Thu, Dec 23, 2010 at 11:41 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
changeset fbf4b1b18202 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fbf4b1b18202
description:
PerfectCacheMemory: Add return statements to two functions.
Two functions in src/mem/ruby/system/PerfectCacheMemory.hh,
tryCacheAccess()
and cacheProbe(), end with calls to panic(). Both of these functions have
return type other than void. Any file that includes this header file
fails
to compile because of the missing return statement. This patch adds dummy
values so as to avoid the compiler warnings.
diffstat:
src/mem/ruby/system/PerfectCacheMemory.hh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diffs (19 lines):
diff -r f249937228b5 -r fbf4b1b18202 src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh Wed Dec 22 23:15:24 2010 -0600
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh Thu Dec 23 13:36:18 2010 -0600
@@ -124,6 +124,7 @@
bool block_stc, ENTRY* entry)
{
panic(not implemented);
+ return true;
}
// tests to see if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemoryENTRY::cacheProbe(const Address newAddress) const
{
panic(cacheProbe called in perfect cache);
+ return newAddress;
}
// looks an address up in the cache
___
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
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] src/base comments
I looked a little more at the base dir, and there are a bunch more files are also unused (at least to the extent that I compiled everything successfully after I removed them). R src/base/compression/base.hh R src/base/compression/lzss_compression.cc R src/base/compression/lzss_compression.hh R src/base/compression/null_compression.hh The last remnant's of Erik's cache compression work... I expect that even if someone revisits that, they may want to use a different interface or something, so I'm fine with whacking this. Thoughts? R src/base/crc.cc R src/base/crc.hh Nate? R src/base/fifo_buffer.cc R src/base/fifo_buffer.hh R src/base/hybrid_pred.cc R src/base/hybrid_pred.hh R src/base/predictor.hh R src/base/res_list.hh R src/base/sat_counter.cc R src/base/sat_counter.hh I think these are all classes that Steve Raasch wrote for the old SS-based out-of-order model that are no longer used. I think we should definitely get rid of them. There are two files (sched_list.hh and timebuf.hh) that are used by some of the CPU models... these seem rather specialized for the base dir, and arguably could go into sim or even cpu. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] does drain need to be so complicated?
Long story, but CountedDrainEvent is bugging me (again)... it's not an event (it never gets scheduled; it's just a callback) and it derives unnecessarily from SimLoopExitEvent (it just uses the inherited cause and code fields to set the cause and code fields of a new SimLoopExitEvent it creates when it's really ready to exit). The resulting code is very confusing since it's not what it appears to be. One solution would be to make it a Callback object instead of an Event; this would at least make the code match the usage and purpose. However, that's not totally trivial, since the current event is exposed through swig to python so that the count value can be set from the python code. The result is that that simple change requires more swig and python tweaking than you might expect. I'm wondering why we need to dynamically allocate this object at all... the only benefit I see is that in theory, we could have multiple disjoint parts of the system draining concurrently but with independent completion detection. In reality, I don't see how we would really do that, unless we had multiple python threads calling the python drain() function concurrently, which doesn't seem likely to happen in our lifetimes. Is anyone opposed to just using a global variable for the drain counter, and a global function to decrement it and exit the sim loop when it hits zero? Steve ___ 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
A better solution would be to put M5_DUMMY_RETURN there. I know there'd were
some issues with some versions of gcc not respecting the attribute no return.
This might be the case.
Ali
Sent from my ARM powered device
On Dec 23, 2010, at 1:10 PM, Nilay Vaish ni...@cs.wisc.edu wrote:
I am able to reproduce the warning. But I have to compile the files on my own
(as in, write the compilation command on the command line) in order to
reproduce the warning.
This is the proposed patch.
--
Nilay
diff --git a/src/mem/ruby/system/PerfectCacheMemory.hh
b/src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh
@@ -124,6 +124,7 @@
bool block_stc, ENTRY* entry)
{
panic(not implemented);
+return true;
}
// tests to see if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemoryENTRY::cacheProbe(const Address newAddress) const
{
panic(cacheProbe called in perfect cache);
+return newAddress;
}
// looks an address up in the cache
On Thu, 23 Dec 2010, Nilay Vaish wrote:
I do not have GCC 4.2.4, but with GCC 4.2.2 I do not see those warnings.
On Thu, 23 Dec 2010, Steve Reinhardt wrote:
It could be an issue with gcc 4.2.4 not properly handling the no return
attribute in some cases... that being a bug that's fixed in 4.4 would
explain why it works for you. That's just speculation on my part though.
Does anyone else have any experience with this? Does the error go away on
4.2.4 if you put the dead 'return' statement back in the particular place
that it's complaining about?
Steve
On Thu, Dec 23, 2010 at 8:12 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
Steve, you had commented that panic() and fatal() are marked as no
return. Then, why should these warnings appear? And why would the compiler
be fine with ERROR_MSG?
--
Nilay
___
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] Error in uploading diff
Yes it does. The easiest way to use it is the hg postreview plugin that integates with mercurial and you won't have any issues. Ali Sent from my ARM powered device On Dec 23, 2010, at 1:49 AM, Nilay ni...@cs.wisc.edu wrote: Apparently Review Board requires git-styled diffs. On Wed, December 22, 2010 8:34 pm, nathan binkert wrote: I don't have time to look at it right now, but I've attached the directory that the error message is referring to. On Wed, Dec 22, 2010 at 6:22 PM, Nilay Vaish ni...@cs.wisc.edu wrote: Can some one try applying the attached diff? It touches only src/mem/protocol/MOESI_CMP_directory-* files. Review Board is failing in applying this diff. I tried and it works correctly. This is the output from Review Board -- The patch to 'src/mem/protocol/MOESI_CMP_directory-L1cache.sm' didn't apply cleanly. The temporary files have been left in '/tmp/reviewboard.3s7DQ8' for debugging purposes. `patch` returned: patching file /tmp/reviewboard.3s7DQ8/tmpAp0ogH Hunk #1 succeeded at 6 with fuzz 2 (offset -130 lines). Hunk #2 FAILED at 150. Hunk #3 FAILED at 184. Hunk #4 FAILED at 272. Hunk #5 FAILED at 289. Hunk #6 FAILED at 306. Hunk #7 FAILED at 335. Hunk #8 FAILED at 353. Hunk #9 FAILED at 373. Hunk #10 FAILED at 380. Hunk #11 FAILED at 393. Hunk #12 FAILED at 425. Hunk #13 FAILED at 440. Hunk #14 FAILED at 479. Hunk #15 FAILED at 493. Hunk #16 FAILED at 511. Hunk #17 FAILED at 529. Hunk #18 FAILED at 543. Hunk #19 FAILED at 597. Hunk #20 FAILED at 604. Hunk #21 FAILED at 640. Hunk #22 FAILED at 655. Hunk #23 FAILED at 676. Hunk #24 FAILED at 690. Hunk #25 FAILED at 708. Hunk #26 FAILED at 721. Hunk #27 FAILED at 739. Hunk #28 FAILED at 768. Hunk #29 FAILED at 780. Hunk #30 FAILED at 1180. 29 out of 30 hunks FAILED -- saving rejects to file /tmp/reviewboard.3s7DQ8/tmpAp0ogH-new.rej Do you think some thing is wrong with the diff? Thanks Nilay ___ 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 -- Nilay ___ 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
