Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I can't reproduce these scons errors and they don't seem to happen from a clean build. Can we blow away the current build directory on zizzer and re-run the regression tester? I would do it myself, but I don't have access to zizzer. Thanks, Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Cron Daemon Sent: Friday, April 29, 2011 12:17 AM To: m5-dev@m5sim.org Subject: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubyNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_BaseGarnetNetwork_wrap.cc' . scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_Topology_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_GarnetNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_SimpleNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_GarnetNetwork_d_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubyNetwo rk_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_BaseGarnet Network_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_Topology_w rap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem _wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_GarnetNetw ork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_SimpleNetw ork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_GarnetNetw ork_d_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubyN etwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_BaseGa rnetNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_Topolo gy_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySy stem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_Garnet Network_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_Simple Network_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_Garnet Network_d_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_Ruby Network_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_Base GarnetNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_Topol
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I deleted the build directory but I'll let it rerun naturally tonight. If somebody wants to rerun them manually go ahead. Gabe Quoting Beckmann, Brad brad.beckm...@amd.com: I can't reproduce these scons errors and they don't seem to happen from a clean build. Can we blow away the current build directory on zizzer and re-run the regression tester? I would do it myself, but I don't have access to zizzer. Thanks, Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Cron Daemon Sent: Friday, April 29, 2011 12:17 AM To: m5-dev@m5sim.org Subject: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubyNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_BaseGarnetNetwork_wrap.cc' . scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_Topology_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_GarnetNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_SimpleNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_GarnetNetwork_d_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubyNetwo rk_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_BaseGarnet Network_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_Topology_w rap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem _wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_GarnetNetw ork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_SimpleNetw ork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_GarnetNetw ork_d_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubyN etwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_BaseGa rnetNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_Topolo gy_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySy stem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_Garnet Network_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_Simple Network_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_Garnet Network_d_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_Ruby Network_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/ExtLink.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_Base GarnetNetwork_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/ExtLink.hh' not found, needed by target
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
This is likely due to my push last night, though I ran the full regression suite before I pushed. My guess is that the directory needs to be blown away so a fresh build can happen. Can someone do that for me? I'm in the car about to go camping. Nate On Sat, Apr 16, 2011 at 12:56 AM, Cron Daemon r...@zizzer.eecs.umich.edu wrote: * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing FAILED! * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing FAILED! * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic FAILED! * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp FAILED! * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token FAILED! * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic FAILED! * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing FAILED! * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual FAILED! * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual FAILED! * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing FAILED! * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic FAILED! * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing FAILED! * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic FAILED! *
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
/z/m5/regression/zizzer/m5/build has been deleted. I'm pretty sure that will do it, but let me know if I need to remove anything else. Gabe On 04/16/11 11:13, nathan binkert wrote: This is likely due to my push last night, though I ran the full regression suite before I pushed. My guess is that the directory needs to be blown away so a fresh build can happen. Can someone do that for me? I'm in the car about to go camping. Nate On Sat, Apr 16, 2011 at 12:56 AM, Cron Daemon r...@zizzer.eecs.umich.edu wrote: * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing FAILED! * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing FAILED! * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic FAILED! * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp FAILED! * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token FAILED! * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic FAILED! * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing FAILED! * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual FAILED! * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual FAILED! * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing FAILED! * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic FAILED! *
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
We've had multiple discussions on this (search the list archives for m5-stable and you should find them). We had some debate about how frequently m5-stable should be updated, and how long we want a changeset to mature in m5 before we consider promoting it to m5-stable, but I think we found some values everyone was content with last time... something like every 6 months we'll update m5-stable to the last working revision more than 1 month old, or something like that. (Or maybe it was 3/1, or 6/2, I forgot.) But as Ali says, the catch in automating this process is identifying the last working revision... we could use the regression tests to help narrow that down, but there are a lot of bugs that get pushed that aren't caught by the regression tester, so I wouldn't want to rely solely on that. If we had a better bug-tracking system so we could record facts like changeset Y fixes a bug introduced in changeset X then we could automatically exclude changesets between X and Y, but we don't have that. Steve On Tue, Mar 29, 2011 at 6:38 PM, Ali Saidi sa...@umich.edu wrote: 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 ___ 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] 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
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
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
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I pushed in patch that imports math in MI_example.py -- Nilay On Mon, 28 Mar 2011, Cron Daemon wrote: * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby FAILED! ___ 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
The two issues below are copied from ARM_FS, but other targets had the same problems. These errors are making the build fail. build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void NetworkTest::completeRequest(Packet*)': build/ARM_FS/cpu/testers/networktest/networktest.cc:160: warning: unused variable 'req' build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void NetworkTest::tick()': build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call of overloaded 'pow(int, int)' is ambiguous These warnings should probably be cleaned up too, although I don't know how long they've been there or how hard that would be. build/ARM_FS/mem/ruby/system/Sequencer.cc: In member function 'void Sequencer::issueRequest(const RubyRequest)': build/ARM_FS/mem/ruby/system/Sequencer.cc:616: warning: 'ctype' may be used uninitialized in this function build/ARM_FS/mem/ruby/system/Sequencer.cc:653: warning: 'amtype' may be used uninitialized in this function Quoting Cron Daemon r...@zizzer.eecs.umich.edu: scons: *** [build/ALPHA_SE/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_hammer/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/ALPHA_SE_MESI_CMP_directory/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_token/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/ALPHA_FS/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/MIPS_SE/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/POWER_SE/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/SPARC_SE/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/X86_SE/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/X86_FS/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/ARM_SE/cpu/testers/networktest/networktest.fo] Error 1 scons: *** [build/ARM_FS/cpu/testers/networktest/networktest.fo] Error 1 See /z/m5/regression/regress-2011-03-22-03:00:01 for details. ___ 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
On Tue, 22 Mar 2011, Gabriel Michael Black wrote: The two issues below are copied from ARM_FS, but other targets had the same problems. These errors are making the build fail. build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void NetworkTest::completeRequest(Packet*)': build/ARM_FS/cpu/testers/networktest/networktest.cc:160: warning: unused variable 'req' build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void NetworkTest::tick()': build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call of overloaded 'pow(int, int)' is ambiguous These warnings should probably be cleaned up too, although I don't know how long they've been there or how hard that would be. The warnings related to networktest.cc got added yesterday. build/ARM_FS/mem/ruby/system/Sequencer.cc: In member function 'void Sequencer::issueRequest(const RubyRequest)': build/ARM_FS/mem/ruby/system/Sequencer.cc:616: warning: 'ctype' may be used uninitialized in this function build/ARM_FS/mem/ruby/system/Sequencer.cc:653: warning: 'amtype' may be used uninitialized in this function These I think have been around for quite a while. -- Nilay ___ 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
The warnings related to networktest.cc got added yesterday. These I think have been around for quite a while. Either way, we should be eliminating warnings. 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
You may already be taking care of this, but networktest.cc also had an error (ambiguous use of the pow function) that made all the regressions fail. That needs to be fixed quickly, regardless of what happens with the warnings or who originally worked on the code. Also, code that doesn't compile should really never have been committed in the first place. It couldn't have been tested since it couldn't have been run. Gabe On 03/22/11 15:46, Nilay Vaish wrote: On Tue, 22 Mar 2011, nathan binkert wrote: The warnings related to networktest.cc got added yesterday. Tushar should take care of the warnings related to networktest.cc. These I think have been around for quite a while. Either way, we should be eliminating warnings. I will commit a patch to eliminate the Sequencer related warnings. -- 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
I sent Tushar an email this morning regarding this, hoping to catch him before he went to bed (he's currently in Singapore). Unfortunately he hasn't responded. Hopefully he'll get to this when he wakes up in a few hours. If he doesn't, I'll take a look at it tomorrow morning. I don't have time to do it today. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Gabe Black Sent: Tuesday, March 22, 2011 1:04 PM To: m5-dev@m5sim.org Subject: Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do- regression quick You may already be taking care of this, but networktest.cc also had an error (ambiguous use of the pow function) that made all the regressions fail. That needs to be fixed quickly, regardless of what happens with the warnings or who originally worked on the code. Also, code that doesn't compile should really never have been committed in the first place. It couldn't have been tested since it couldn't have been run. Gabe On 03/22/11 15:46, Nilay Vaish wrote: On Tue, 22 Mar 2011, nathan binkert wrote: The warnings related to networktest.cc got added yesterday. Tushar should take care of the warnings related to networktest.cc. These I think have been around for quite a while. Either way, we should be eliminating warnings. I will commit a patch to eliminate the Sequencer related warnings. -- 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
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
On Sat, March 19, 2011 3:26 am, Cron Daemon wrote: scons: *** Found dependency cycle(s): I am looking at the output of the regression from last night. What do the following errors mean? scons: *** Found dependency cycle(s): Internal Error: no cycle found for node build/POWER_SE/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x28927440) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0xfa57320) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x3fdbab8) in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x315e16c8) in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x315362d8) in state up_to_date Internal Error: no cycle found for node build/POWER_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x28939dd0) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x3fc5758) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x3fbc488) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0xfbc6680) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L2Cache_Controller.hh (SCons.Node.FS.File instance at 0xfbc6ef0) in state up_to_date Internal Error: no cycle found for node build/POWER_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x28922170) in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x31515320) in state up_to_date File /usr/lib/scons/SCons/Taskmaster.py, line 800, in cleanup Child returned 2 When attemping to execute: scons --ignore-style -k USE_MYSQL=no EXTRAS=/z/m5/regression/zizzer/encumbered RUBY=True -j 7 -Q build/ALPHA_SE/tests/fast/quick build/ALPHA_SE_MOESI_hammer/tests/fast/quick build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick build/ALPHA_FS/tests/fast/quick build/MIPS_SE/tests/fast/quick build/POWER_SE/tests/fast/quick build/SPARC_SE/tests/fast/quick build/X86_SE/tests/fast/quick build/X86_FS/tests/fast/quick build/ARM_SE/tests/fast/quick build/ARM_FS/tests/fast/quick Child returned 1 When attemping to execute: util/regress '--scons-opts' '-k USE_MYSQL=no EXTRAS=/z/m5/regression/zizzer/encumbered RUBY=True -j 7 -Q' 'quick' -- Nilay ___ 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
The X86_FS regressions have failed the last couple nights. The first time I attributed to it not catching my change to M5_PATH and something flaky happening with nfs. That was even more of a stretch the second time. My new theory is that scons didn't see that the files the regression uses or that the environment had changed and was just reporting the old result, not rerunning the test. I deleted the previous run for X86_FS (just the build/X86_FS/tests/fast directory) and hopefully we'll now see our first passeds for X86_FS. Gabe On 03/15/11 00:08, Cron Daemon wrote: * build/X86_FS/tests/fast/quick/10.linux-boot/x86/linux/pc-simple-atomic FAILED! * build/X86_FS/tests/fast/quick/10.linux-boot/x86/linux/pc-simple-timing FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * 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/00.hello/alpha/linux/simple-timing-ruby 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 passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 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-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
IIRC, I was expecting some response from Ali as to why M5_DUMMY_RETURN should or should not work. I did not poke in any further. To me it is a compiler bug that we have to work with. I think return panic(); works with both 4.2 and 4.4 series, but we probably do not want that. -- Nilay On Tue, March 8, 2011 11:37 pm, nathan binkert wrote: Nilay, I know that this is a way old e-mail, but did you ever figure this out? Nate On Fri, Dec 24, 2010 at 8:57 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I tried M5_DUMMY_RETURN and it it not working. I checked its definition. It would evaluate to nothing, in which case I do not see why it should help in avoiding the warning. I tried putting a return statement before panic(); return panic(not implemented); This works with GCC 4.2.2. I checked whether GCC has some recorded bug reports for this. I found the following two - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42674 I tried the provided codes. For the first one, 4.2.2 raises a warning but 4.4.0 does not. For the second one, 4.4.0 raises a warning but 4.2.2 does not. -- Nilay On Thu, 23 Dec 2010, Ali Saidi wrote: 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 ___ 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
IIRC, I was expecting some response from Ali as to why M5_DUMMY_RETURN should or should not work. I did not poke in any further. To me it is a compiler bug that we have to work with. I think return panic(); works with both 4.2 and 4.4 series, but we probably do not want that. What I didn't understand was why this was an issue for this file, but not others that are in a similar situation. 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
The reason M5_DUMMY_RETURN didn't work is for gcc it's #defined to nothing because in theory gcc respects __attribute__(no return), but apparently not in this case. Ali On Mar 9, 2011, at 7:00 AM, Nilay wrote: IIRC, I was expecting some response from Ali as to why M5_DUMMY_RETURN should or should not work. I did not poke in any further. To me it is a compiler bug that we have to work with. I think return panic(); works with both 4.2 and 4.4 series, but we probably do not want that. -- Nilay On Tue, March 8, 2011 11:37 pm, nathan binkert wrote: Nilay, I know that this is a way old e-mail, but did you ever figure this out? Nate On Fri, Dec 24, 2010 at 8:57 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I tried M5_DUMMY_RETURN and it it not working. I checked its definition. It would evaluate to nothing, in which case I do not see why it should help in avoiding the warning. I tried putting a return statement before panic(); return panic(not implemented); This works with GCC 4.2.2. I checked whether GCC has some recorded bug reports for this. I found the following two - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42674 I tried the provided codes. For the first one, 4.2.2 raises a warning but 4.4.0 does not. For the second one, 4.4.0 raises a warning but 4.2.2 does not. -- Nilay On Thu, 23 Dec 2010, Ali Saidi wrote: 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 ___ 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 just manually started a new set of regressions that should run this time. Ali On Mar 7, 2011, at 2:00 AM, Cron Daemon wrote: See /z/m5/regression/regress-2011-03-07-03:00:01 for details. ___ 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 looked at this error, and it seems to be another 4.2.4 oddity. It builds fine with my normal compiler, but if I switch to that version I get a linking issue that doesn't make sense. Basically it complains that the constructor for the MicroPanic microop doesn't exist even though it's built into the decoder and is easy to find in decoder.cc. Perhaps it's not figuring out how to resolve types of arguments properly or something. If anyone else wants to look at it as well it's easy to reproduce if you use 4.2.4 which is on zizzer. Gabe On 02/15/11 00:15, Cron Daemon wrote: scons: *** [build/X86_SE/m5.fast.unstripped] Error 1 * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 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/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing 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/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. *
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Perhaps we should upgrade zizzer? Nate On Tue, Feb 15, 2011 at 7:40 PM, Gabe Black gbl...@eecs.umich.edu wrote: I looked at this error, and it seems to be another 4.2.4 oddity. It builds fine with my normal compiler, but if I switch to that version I get a linking issue that doesn't make sense. Basically it complains that the constructor for the MicroPanic microop doesn't exist even though it's built into the decoder and is easy to find in decoder.cc. Perhaps it's not figuring out how to resolve types of arguments properly or something. If anyone else wants to look at it as well it's easy to reproduce if you use 4.2.4 which is on zizzer. Gabe On 02/15/11 00:15, Cron Daemon wrote: scons: *** [build/X86_SE/m5.fast.unstripped] Error 1 * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 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/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing 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/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. *
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I wouldn't complain, although someone might try to use 4.2.4 so it's not necessarily a bad thing to fix this stuff. Gabe On 02/15/11 11:50, nathan binkert wrote: Perhaps we should upgrade zizzer? Nate On Tue, Feb 15, 2011 at 7:40 PM, Gabe Black gbl...@eecs.umich.edu wrote: I looked at this error, and it seems to be another 4.2.4 oddity. It builds fine with my normal compiler, but if I switch to that version I get a linking issue that doesn't make sense. Basically it complains that the constructor for the MicroPanic microop doesn't exist even though it's built into the decoder and is easy to find in decoder.cc. Perhaps it's not figuring out how to resolve types of arguments properly or something. If anyone else wants to look at it as well it's easy to reproduce if you use 4.2.4 which is on zizzer. Gabe On 02/15/11 00:15, Cron Daemon wrote: scons: *** [build/X86_SE/m5.fast.unstripped] Error 1 * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 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/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing 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/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. *
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Ah, ok, I figured it out. There was an errant inline before the constructor in the .cc. I don't know if that's supposed to allow the compiler to eliminate that symbol from the resulting object file, but that seems to be what it was doing sometimes. I'll make sure that fix is doing what I expect it to and then commit it. Gabe On 02/15/11 12:16, Gabe Black wrote: I wouldn't complain, although someone might try to use 4.2.4 so it's not necessarily a bad thing to fix this stuff. Gabe On 02/15/11 11:50, nathan binkert wrote: Perhaps we should upgrade zizzer? Nate On Tue, Feb 15, 2011 at 7:40 PM, Gabe Black gbl...@eecs.umich.edu wrote: I looked at this error, and it seems to be another 4.2.4 oddity. It builds fine with my normal compiler, but if I switch to that version I get a linking issue that doesn't make sense. Basically it complains that the constructor for the MicroPanic microop doesn't exist even though it's built into the decoder and is easy to find in decoder.cc. Perhaps it's not figuring out how to resolve types of arguments properly or something. If anyone else wants to look at it as well it's easy to reproduce if you use 4.2.4 which is on zizzer. Gabe On 02/15/11 00:15, Cron Daemon wrote: scons: *** [build/X86_SE/m5.fast.unstripped] Error 1 * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 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/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing 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/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. *
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Hi Gabe, Since you successfully updated the tests I can't run (ARM_FS), I can take of the remaining errors (i.e. ruby protocol tests). I have a few minor fixes I want to check in that I need to run the regression tester against anyways. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Gabe Black Sent: Tuesday, February 08, 2011 12:15 AM To: M5 Developer List Subject: Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do- regression quick Hmm. I didn't realize all the build targets for ruby protocols had their own separate regressions. I'll have to run those too. Gabe On 02/08/11 00:17, Cron Daemon wrote: * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru6 4/simple-timing-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux /simple-timing-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/ rubytest-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/l inux/memtest-ruby-MESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/sim ple-timing-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/sim ple-timing-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/lin ux/simple-timing-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru 64/simple-timing-ruby-MOESI_CMP_directory FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/lin ux/rubytest-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/ simple-timing-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/ simple-timing-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux /memtest-ruby-MOESI_hammer FAILED! * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/li nux/memtest-ruby-MOESI_CMP_token FAILED! * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha /linux/memtest-ruby-MOESI_CMP_directory FAILED! scons: *** Source `tests/quick/01.hello-2T-smt/ref/alpha/linux/o3- timing/stats.txt' not found, needed by target `build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3- timing/status'. * 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/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple- atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple- timing-mp passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/li nux/rubytest-ruby-MESI_CMP_directory 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 passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple- atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple- atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple- timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple- timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple- timing 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_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha /linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_FS/tests/fast/quick/10.linux- boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux- boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux- boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf- stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux- boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing- ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
The X86 o3 regressions will fail until somebody blasts the build directory. Building O3 is now default, but it won't be picked up into existing build directories. Gabe On 02/05/11 00:10, Cron Daemon wrote: * build/X86_SE/tests/fast/quick/00.hello/x86/linux/o3-timing FAILED! * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token 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-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby 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/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed. * build/ARM_SE/tests/fast/quick/00.hello/arm/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. *
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
The X86 o3 regressions will fail until somebody blasts the build directory. Building O3 is now default, but it won't be picked up into existing build directories. Couldn't that somebody be you? :) 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
On 02/05/11 07:23, nathan binkert wrote: The X86 o3 regressions will fail until somebody blasts the build directory. Building O3 is now default, but it won't be picked up into existing build directories. Couldn't that somebody be you? :) Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev I don't know for sure where the right directory is, and I don't want to go deleting things willy nilly. 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
I don't know for sure where the right directory is, and I don't want to go deleting things willy nilly. zizzer:/z/m5/regression/zizzer/m5/build Tomorrow night (or maybe tonight?) it will run from scratch anyway. 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
This looks like a stale build directory still. It's apparently obsolete intermediate swig files that get mixed in when they shouldn't. [SWIG] X86_SE/python/m5/internal/param_RubySystem.i - _wrap.cc, .py scons: *** [build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 build/X86_SE/python/m5/internal/param_RubySystem.i:26: Error: Unable to find 'python/m5/internal/param_RubyDebug.i' [SWIG] ARM_SE/python/m5/internal/param_RubySystem.i - _wrap.cc, .py build/ARM_SE/python/m5/internal/param_RubySystem.i:26: Error: Unable to find 'python/m5/internal/param_RubyDebug.i' [SWIG] ARM_FS/python/m5/internal/param_RubySystem.i - _wrap.cc, .py build/ARM_FS/python/m5/internal/param_RubySystem.i:26: Error: Unable to find 'python/m5/internal/param_RubyDebug.i' scons: *** [build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 Gabe Cron Daemon wrote: scons: *** [build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_token/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 See /z/m5/regression/regress-2011-01-12-03:00:01 for details. ___ 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
Actually, I take that back. It looks like param_RubySystem.i isn't being regenerated even though RubySystem.py was changed to not have a RubyDebug parameter. I don't know why, but an obvious guess is incomplete dependencies. Gabe Gabe Black wrote: This looks like a stale build directory still. It's apparently obsolete intermediate swig files that get mixed in when they shouldn't. [SWIG] X86_SE/python/m5/internal/param_RubySystem.i - _wrap.cc, .py scons: *** [build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 build/X86_SE/python/m5/internal/param_RubySystem.i:26: Error: Unable to find 'python/m5/internal/param_RubyDebug.i' [SWIG] ARM_SE/python/m5/internal/param_RubySystem.i - _wrap.cc, .py build/ARM_SE/python/m5/internal/param_RubySystem.i:26: Error: Unable to find 'python/m5/internal/param_RubyDebug.i' [SWIG] ARM_FS/python/m5/internal/param_RubySystem.i - _wrap.cc, .py build/ARM_FS/python/m5/internal/param_RubySystem.i:26: Error: Unable to find 'python/m5/internal/param_RubyDebug.i' scons: *** [build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 Gabe Cron Daemon wrote: scons: *** [build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_SE_MOESI_CMP_token/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc] Error 1 scons: *** [build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc] Error 1 See /z/m5/regression/regress-2011-01-12-03:00:01 for details. ___ 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 initially thought this was your RubyDebug.hh change, Nate, but I don't see RubyDebug in the repository anywhere now. In the past I've run into problems where left over files make a build break until you wipe it out and rebuild, specifically having to do with the python stuff. I suspect if you delete these build directories and rerun these might pass, but you might want to look them over to see why they need to be cleared out to work. Maybe something is including all the files in a particular directory, and even though scons isn't building them any more they're still getting picked up and folded in? Gabe Cron Daemon wrote: scons: *** Implicit dependency `build/ALPHA_SE/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_token/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_token/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_FS/params/RubyDebug.hh' not found, needed by target `build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/MIPS_SE/params/RubyDebug.hh' not found, needed by target `build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/POWER_SE/params/RubyDebug.hh' not found, needed by target `build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/SPARC_SE/params/RubyDebug.hh' not found, needed by target `build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/X86_SE/params/RubyDebug.hh' not found, needed by target `build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_SE/params/RubyDebug.hh' not found, needed by target `build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_FS/params/RubyDebug.hh' not found, needed by target `build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc'. See /z/m5/regression/regress-2011-01-11-03:00:01 for details. ___ 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 also received this error after I pulled in Nate's changeset. Removing the build directory fixed the problem for me. Nilay On Tue, January 11, 2011 4:35 am, Gabe Black wrote: I initially thought this was your RubyDebug.hh change, Nate, but I don't see RubyDebug in the repository anywhere now. In the past I've run into problems where left over files make a build break until you wipe it out and rebuild, specifically having to do with the python stuff. I suspect if you delete these build directories and rerun these might pass, but you might want to look them over to see why they need to be cleared out to work. Maybe something is including all the files in a particular directory, and even though scons isn't building them any more they're still getting picked up and folded in? Gabe Cron Daemon wrote: scons: *** Implicit dependency `build/ALPHA_SE/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_token/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_token/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_FS/params/RubyDebug.hh' not found, needed by target `build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/MIPS_SE/params/RubyDebug.hh' not found, needed by target `build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/POWER_SE/params/RubyDebug.hh' not found, needed by target `build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/SPARC_SE/params/RubyDebug.hh' not found, needed by target `build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/X86_SE/params/RubyDebug.hh' not found, needed by target `build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_SE/params/RubyDebug.hh' not found, needed by target `build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_FS/params/RubyDebug.hh' not found, needed by target `build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc'. See /z/m5/regression/regress-2011-01-11-03:00:01 for details. ___ 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
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I also received this error after I pulled in Nate's changeset. Removing the build directory fixed the problem for me. That rings a bell. I think it happened, but I'm not sure why that happened. I'll blow away the build directory on zizzer. 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
I tried M5_DUMMY_RETURN and it it not working. I checked its definition.
It would evaluate to nothing, in which case I do not see why it should
help in avoiding the warning. I tried putting a return statement before
panic();
return panic(not implemented);
This works with GCC 4.2.2.
I checked whether GCC has some recorded bug reports for this. I found the
following two -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42674
I tried the provided codes. For the first one, 4.2.2 raises a warning but
4.4.0 does not. For the second one, 4.4.0 raises a warning but 4.2.2 does
not.
--
Nilay
On Thu, 23 Dec 2010, Ali Saidi wrote:
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
___
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] 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
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] 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
