As Matt S had mentioned, I'm working on getting ROCm 4 support running and I'm just debugging an issue that's popped up when using it on develop, but it runs on stable. Once I get that figured out, we'll be using Ubuntu 20 in the GCN Docker image instead of Ubuntu 16. We intend for ROCm 4 support to be in the gem5 21.1 release.
In regards to running in a more "normal" environment, there are a couple of issues with ROCm 4 that I think we would need to resolve first: The first one is gem5-related: ROCr-Runtime uses a currently unimplemented syscall (memfd_create), but you can disable it when compiling from source. The second one is an issue with running ROCm in a simulator: ROCclr will compile some blit kernels on-the-fly whenever you run a program. It takes forever, and it crashes at the end in gem5 anyway. Currently I just return when that function is called, and for the programs I've run there haven't been any ill effects. There's also a difference in how pre-built/cached kernels are handled in MIOpen (stored in database vs directories), which we can also change when compiling from source. I've also had issues with trying to install parts of ROCm from source and then subsequent parts of ROCm from .deb packages or apt. That's one of the reasons for the complexity in the GCN dockerfile. If that issue has gone away with ROCm 4 (I haven't tried yet) that would simplify the dockerfile greatly as we would only need to build ROCclr from source, assuming memfd_create is implemented, and everything else could be installed from apt. Kyle ________________________________ From: gem5-dev@gem5.org <gem5-dev@gem5.org> Sent: Friday, May 14, 2021 1:07 PM To: gem5 Developer List <gem5-dev@gem5.org> Cc: Matt Sinclair <msincl...@wisc.edu>; Poremba, Matthew <matthew.pore...@amd.com>; Gabe Black <gabe.bl...@gmail.com>; Bobby Bruce <bbr...@ucdavis.edu> Subject: [gem5-dev] Re: Build failed in Jenkins: compiler-checks #72 To clarify the docker situation, here's a quick rundown of how docker is used with gem5: Docker is the fallback for people who are using outdated/weird/unsupported systems and want to use gem5. It's also handy for testing as we can quickly spin up different environments (different OS's, different compilers, different dependencies) and see how gem5 performs. Docker will run in all major OS's (Mac, Windows, Linux). As long as you can run docker, you should be able to build/run gem5. One of my problems with docker is its CLI is needlessly verbose and confusing. You need to specify way too much boilerplate stuff to get it going. However we have provided some documentation here for gem5 users: http://www.gem5.org/documentation/general_docs/building#docker. We're in charge of the images and can change them as requirements change. In respect to the GPU/GCN3 stuff: This is a special case. The environment needed to compile x86_gcn3 and run GCN3 is specific to the point that it'd be unreasonable to ask a user to set it all up just to run some GPU simulations (see the Dockerfile here to get an idea: https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/util/dockerfiles/gcn-gpu/Dockerfile). So, for this, we recommend always compiling and running within docker, even if you're using a system that can build/run gem5 without virtualization. I did not realize the GCN3 docker image was using GCC 5, so that is problematic. I also think it using Ubuntu 16.04 isn't a good idea either as we're not really supporting that anymore. Given GCN3 is already patching a lot of library code to get this all working, is it possible to patch ROCm to work with newer compilers? Also, this may come across as a cheeky question (but I don't mean it to be): Is there anything in the pipeline to have the X86_GCN3 build run in a more vanilla environment? E.g., build and run in Ubuntu 18.04 with just a few APT installs? I would be in strong support of such a move. It'd simplify a lot. -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Thu, May 13, 2021 at 5:00 PM Gabe Black via gem5-dev <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>> wrote: So, is this something *inside* the simulation which needs to be compiled with a particular version of gcc, or is it a part of the simulator itself? I was imagining the former, but if it's the later I see why it's problematic. How tightly coupled is this ROCm code base? Is it just a matter of updating weird gcc-isms in the code, or does it (for instance) actually use gcc machinery and need literal porting to a different version of that machinery? Gabe On Thu, May 13, 2021 at 4:56 PM Matt Sinclair <sincl...@cs.wisc.edu<mailto:sincl...@cs.wisc.edu>> wrote: This is actually what we do right now — we have a docker setup for Ubuntu 16 and the GPU experiments are strongly recommended to be run inside it. My concern though is if we deprecate support for gcc 5 before the ROCm 4 support is pushed, the codebases would diverge, because all the cool new features you mentioned would not be compatible with the gcc version we have to run in the current docker setup. Again, my hope is this is a short-term issue though, so it may be moot. Matt On Thu, May 13, 2021 at 6:51 PM Gabe Black via gem5-dev <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>> wrote: I'm pretty clueless as far as how the GPU code is built, but would it be possible to build it in a docker or something with a separate older compiler? Would it be reasonable to provide a docker for gem5 building in general, so we can decouple from ye-olde versions of RedHat? In the past Jason and/or Bobby have sent me a command line which builds gem5 inside of a docker with the source bind mounted, and that seemed to work well. Does that come with other baggage or limitations which make that infeasible? For instance, I don't think this is true, but does it not work on Mac? I don't think we should *require* building inside a docker, but that could give people working on old systems a solution if we move to more up to date tools. Gabe On Thu, May 13, 2021 at 4:45 PM Matt Sinclair <sincl...@cs.wisc.edu<mailto:sincl...@cs.wisc.edu>> wrote: Just to be clear: Kyle R has ROCm 4.0 working locally on stable (but not develop), and our plan is to push the 4.0 support once Kyle’s current set of patches (which have a few more to be pushed still) are committed and we debug the issues with develop. So, in theory, we’re talking about a fairly short term need to keep gcc 5. Matt On Thu, May 13, 2021 at 6:42 PM Matt Sinclair <sincl...@cs.wisc.edu<mailto:sincl...@cs.wisc.edu>> wrote: At least for the moment, the GPU support relies on gcc 5.4, since the version of AMD’s ROCm stack that is supported requires 5.4 for the ML libraries. We are working on updating both FS and SE mode support for newer versions of ROCm, which work with newer versions of gcc, but I would need to dig to figure out what the minimum gcc version they support is (probably whatever goes with Ubuntu 20 by default). Either way, in the short term, unless we want to deprecate all GPU support, it would be good not to deprecate gcc 5. Matt P: do you know what gcc version ROCm 4.0 supports? Matt On Thu, May 13, 2021 at 6:15 PM Jason Lowe-Power via gem5-dev <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>> wrote: I think the main question for (not) dropping support is the LTS for Ubuntu and RHEL. It looks like Ubuntu 16.04 just dropped out of standard support, so we can probably drop support for the default there, now. https://wiki.ubuntu.com/Releases TBH, I can't really tell what's currently supported for RHEL. I think 7 is nearing the end of "normal" support. Someone else can try to decipher the documentation :). https://access.redhat.com/support/policy/updates/errata Jason On Thu, May 13, 2021 at 4:08 PM Gabe Black via gem5-dev <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>> wrote: If we were willing to bump clang support all the way up to version 9 (a big leap, released 19 September 2019) we would get support for __builtin_LINE and __builtin_FILE, which are there to support std::source_location which is a c++20 feature but which can be used without enabling c++20. That would be really helpful in turning macros which capture file/line information like panic() and warn() into normal functions. Gabe On Thu, May 13, 2021 at 3:58 PM Gabe Black <gabe.bl...@gmail.com<mailto:gabe.bl...@gmail.com>> wrote: I have no objection to moving the compiler versions up. I don't really know what benchmark we use to decide when that's ok to do. If we do move up, it would be nice to move to a version which would let us use c++17. For gcc, the oldest version with any support is 5, there seems to be pretty solid support by version 7, pretty much complete compiler support by 8, pretty much complete library support by 9, and it's the default version by 11. If we remove support for 5 and 6, I think that might bring us into position to use c++17 with 7, and I think if we move to 8 it's pretty safe. Version 5.2 was released on July 16, 2015 Version 7.3 was released on January 25, 2018 Version 8.1 was released on May 2, 2018 Version 11.1 was released very recently on April 27, 2021. For clang, it seems to be a little more straightforward, and we'd just need version 5. This was released on 7 September 2017. So, with no other data points, I'd vote for updating to gcc version 7.3 (or just 7+), and clang 5, and then enabling c++17. https://en.cppreference.com/w/cpp/compiler_support/17 https://www.gnu.org/software/gcc/projects/cxx-status.html#cxx17 https://clang.llvm.org/cxx_status.html https://en.wikipedia.org/wiki/Clang#Status_history https://gcc.gnu.org/releases.html On Thu, May 13, 2021 at 1:43 PM Bobby Bruce via gem5-dev <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>> wrote: These two patchset should fix most of this: https://gem5-review.googlesource.coThism/c/public/gem5/+/45479<https://gem5-review.googlesource.com/c/public/gem5/+/45479>, https://gem5-review.googlesource.com/c/public/gem5/+/45481 Unfortunately, we currently can't compile with GCC 5 as deprecation of enum values were only introduced in GCC 6. So this change is problematic: https://gem5.googlesource.com/public/gem5/+/6d7c3afcd44843fb93578d63ad1f5401906d17ad/src/sim/aux_vector.hh#100, and will continue to break the compilation tests. Perhaps this is worthy of discussion: how long do we want to continue supporting GCC 5? What's our policy here? The GCC 5 and 6 release series are no longer supported, but I wouldn't go as far to say these are old compilers completely unused in the wider world. -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Tue, May 11, 2021 at 11:45 PM jenkins-no-reply--- via gem5-dev <gem5-dev@gem5.org<mailto:gem5-dev@gem5.org>> wrote: See <https://jenkins.gem5.org/job/compiler-checks/72/display/redirect?page=changes> Changes: [shingarov] arch-power: Fix precedence of register operands [shingarov] arch-power: Add fields for DS form instructions [m] arch-x86: Implement ACPI root tables [m] arch-x86: Add ACPI support for MADT [m] configs: Use MADT in x86 full system simulation [shingarov] arch-power: Refactor load-store instructions [gabe.black] arch,cpu: Rename arch/registers.hh to arch/vecregs.hh. [gabe.black] tests: Delete the nmtest "UnitTest". [gabe.black] tests: Remove the stattest "UnitTest". [gabe.black] misc: Delete the unittest/genini.py script. [gabe.black] scons,tests: Delete support for the UnitTest scons class/function. [gabe.black] arch-x86: Fix x86 build. [gabe.black] arch-x86: Let individual reg uops specialize their arguments. [gabe.black] arch-x86: Factor out duplication in the new RegOp base classes. [gabe.black] arch-x86: Generalize the RegOp operands. [gabe.black] arch-x86: Use the new op bases for memory microops. [gabe.black] arch-x86: Remove static code from debug.isa and fix style. [gabe.black] arch-x86: Use the *Op classes with FP microops. [gabe.black] arch-x86: Use the newly flexible RegOpT to implement the limm uop. [gabe.black] arch-x86: Correct style and use uop args in specop.isa. [gabe.black] arch-x86: Fix style and use uop args in seqop.isa. [gabe.black] arch-x86: Style fixes and use uop args in the media ops. [gabe.black] arch-x86: Use regIdx() instead of creating an InstRegIndex directly. [gabe.black] arch-x86: Eliminate the DependenceTags in registers.hh. [gabe.black] arch-x86: Create a separate type for floating point reg idxs. [gabe.black] arch-x86: Specialize the remaining operand types for uops. [gabe.black] arch: Delete a few unused vector register types/constants. [gabe.black] arch-x86: Make pick, signedPick and merge take indexes directly. [gabe.black] arch-x86: Use the new multiplication helpers in the mul uops. [gabe.black] arch-x86: Move the step division helper out of the ISA desc. [gabe.black] arch-x86: Get rid of the now unused print(Src|Dest)Reg methods. [gabe.black] base: Add macros to mark things as deprecated. [gabe.black] base: Mark the unused DPRINTF_UNCONDITIONAL macro as deprecated. [gabe.black] base,arch,dev,mem: Always compile DPRINTFs, even if they're disabled. [gabe.black] base: Collapse the DTRACE macro in DPRINTF. [gabe.black] base: Simplify the definition of DTRACE. [Giacomo Travaglini] arch-arm: Fix SMM* instructions [gabe.black] base,python: Simplify how we check if a debug flag is enabled. [gabe.black] base: Move TRACING_ON check into Flag::tracing(). [gabe.black] misc: Collapse all uses of DTRACE(x) to Debug::x. [gabe.black] base,arch-sparc: Overhaul the small fenv wrapper in base. [gabe.black] arch-arm: Use src/base/fenv.hh instead of raw fenv.h. [gabe.black] cpu: Delete an unnecessary return in RegId::flatIndex. [gabe.black] arch,cpu: Get rid of is*Reg() methods in RegId. [gabe.black] cpu: Get rid of the unused NumRegClasses constant. [gabe.black] cpu: Get rid of the redundant PhysRegIndex type. [gabe.black] scons,misc: Remove the ability to disable some trivial features. [gabe.black] scons: Pull builder definitions out of SConstruct. [gabe.black] scons: Simplify finding the python lib with ParseConfig. [gabe.black] scons: Update comments in SConstruct. [gabe.black] python: Collapse away the now unused readCommandWithReturn function. [gabe.black] python,scons: Move readCommand and compareVersions into site_scons. [gabe.black] arch-x86: Clean up x86 integer indexes. [gabe.black] arch-x86: Create some infrastructure for x86 microop operands. [gabe.black] arch: Set %(op_idx)s properly when predicated operands are present. [gabe.black] arch-x86: Build source picking into the operands. [gabe.black] dev: Overload swap_bytes, don't specialize the template. [gabe.black] sim: Use type_traits to steer swap_bytes. [gabe.black] base: Move the macros in compiler.hh to a GEM5_ prefix. [gabe.black] misc: Replace M5_VAR_USED with GEM5_VAR_USED. [gabe.black] misc: Replace M5_NODISCARD with GEM5_NO_DISCARD. [gabe.black] misc: Replace M5_FALLTHROUGH with GEM5_FALLTHROUGH. [gabe.black] misc: Replace M5_ATTR_PACKED with GEM5_PACKED. [gabe.black] arch-sparc: Replace M5_NO_INLINE with GEM5_NO_INLINE. [gabe.black] misc: Replace M5_LOCAL and M5_WEAK with GEM5_LOCAL and GEM5_WEAK. [gabe.black] misc: Replace M5_ALIGNED with GEM5_ALIGNED. [gabe.black] misc: Replace M5_UNREACHABLE with GEM5_UNREACHABLE. [gabe.black] base: Replace M5_UNLIKELY with GEM5_UNLIKELY. [gabe.black] misc: Replace M5_FOR_EACH_IN_PACK with GEM5_FOR_EACH_IN_PACK. [gabe.black] misc: Replace M5_CLASS_VAR_USED with GEM5_CLASS_VAR_USED. [gabe.black] sim: Deprecate M5_AT_* constants. [gabe.black] arch: Stop using deprecated M5_AT_* constants. ------------------------------------------ Started by timer Running as SYSTEM Building in workspace <https://jenkins.gem5.org/job/compiler-checks/ws/> Selected Git installation does not exist. Using Default The recommended git tool is: NONE No credentials specified Cloning the remote Git repository Cloning repository https://gem5.googlesource.com/public/gem5 > git init <https://jenkins.gem5.org/job/compiler-checks/ws/> # timeout=10 Fetching upstream changes from https://gem5.googlesource.com/public/gem5 > git --version # timeout=10 > git --version # 'git version 2.25.1' > git fetch --tags --force --progress -- > https://gem5.googlesource.com/public/gem5 > +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url https://gem5.googlesource.com/public/gem5 # > timeout=10 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # > timeout=10 Avoid second fetch > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10 Checking out Revision b1a396bfcfa66e05f28475758edb3e16e53c5047 (refs/remotes/origin/develop) > git config core.sparsecheckout # timeout=10 > git checkout -f b1a396bfcfa66e05f28475758edb3e16e53c5047 # timeout=10 Commit message: "arch: Stop using deprecated M5_AT_* constants." > git rev-list --no-walk 808056ce4e2c56415062e0a455851c1bedc8d9cd # timeout=10 [compiler-checks] $ /bin/sh -xe /tmp/jenkins1137832772359858327.sh + ./util/compiler-tests.sh -j 12 Starting build tests with 'gcc-version-10'... 'gcc-version-10' was found in the comprehensive tests. All ISAs will be built. * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-10'... Done. * Building target 'NULL_MOESI_CMP_directory.fast' with 'gcc-version-10'... Done. * Building target 'ARM.opt' with 'gcc-version-10'... Done. * Building target 'ARM.fast' with 'gcc-version-10'... ! Failed with exit code 2. * Building target 'Garnet_standalone.opt' with 'gcc-version-10'... Done. * Building target 'Garnet_standalone.fast' with 'gcc-version-10'... Done. * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-10'... Done. * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-10'... ! Failed with exit code 2. * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-10'... Done. * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-10'... Done. * Building target 'X86.opt' with 'gcc-version-10'... Done. * Building target 'X86.fast' with 'gcc-version-10'... Done. * Building target 'POWER.opt' with 'gcc-version-10'... Done. * Building target 'POWER.fast' with 'gcc-version-10'... Done. * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-10'... Done. * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-10'... Done. * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-10'... Done. * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-10'... Done. * Building target 'RISCV.opt' with 'gcc-version-10'... Done. * Building target 'RISCV.fast' with 'gcc-version-10'... Done. * Building target 'GCN3_X86.opt' with 'gcc-version-10'... Done. * Building target 'GCN3_X86.fast' with 'gcc-version-10'... ! Failed with exit code 2. * Building target 'MIPS.opt' with 'gcc-version-10'... Done. * Building target 'MIPS.fast' with 'gcc-version-10'... Done. * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-10'... Done. * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-10'... Done. * Building target 'SPARC.opt' with 'gcc-version-10'... Done. * Building target 'SPARC.fast' with 'gcc-version-10'... Done. Starting build tests with 'gcc-version-9'... * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-9'... Done. * Building target 'NULL_MOESI_CMP_directory.fast' with 'gcc-version-9'... Done. Starting build tests with 'gcc-version-8'... * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-8'... Done. * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-8'... Done. Starting build tests with 'gcc-version-7'... * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-7'... Done. * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-7'... ! Failed with exit code 2. Starting build tests with 'gcc-version-6'... * Building target 'ARM.opt' with 'gcc-version-6'... Done. * Building target 'ARM.fast' with 'gcc-version-6'... ! Failed with exit code 2. Starting build tests with 'gcc-version-5'... * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-5'... ! Failed with exit code 2. * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-5'... ! Failed with exit code 2. Starting build tests with 'clang-version-9'... 'clang-version-9' was found in the comprehensive tests. All ISAs will be built. * Building target 'NULL_MOESI_CMP_token.opt' with 'clang-version-9'... Done. * Building target 'NULL_MOESI_CMP_token.fast' with 'clang-version-9'... Done. * Building target 'POWER.opt' with 'clang-version-9'... Done. * Building target 'POWER.fast' with 'clang-version-9'... Done. * Building target 'NULL_MOESI_hammer.opt' with 'clang-version-9'... Done. * Building target 'NULL_MOESI_hammer.fast' with 'clang-version-9'... Done. * Building target 'NULL_MOESI_CMP_directory.opt' with 'clang-version-9'... Done. * Building target 'NULL_MOESI_CMP_directory.fast' with 'clang-version-9'... Done. * Building target 'SPARC.opt' with 'clang-version-9'... Done. * Building target 'SPARC.fast' with 'clang-version-9'... Done. * Building target 'MIPS.opt' with 'clang-version-9'... Done. * Building target 'MIPS.fast' with 'clang-version-9'... Done. * Building target 'X86.opt' with 'clang-version-9'... Done. * Building target 'X86.fast' with 'clang-version-9'... Done. * Building target 'NULL_MESI_Two_Level.opt' with 'clang-version-9'... Done. * Building target 'NULL_MESI_Two_Level.fast' with 'clang-version-9'... Done. * Building target 'RISCV.opt' with 'clang-version-9'... Done. * Building target 'RISCV.fast' with 'clang-version-9'... Done. * Building target 'ARM.opt' with 'clang-version-9'... Done. * Building target 'ARM.fast' with 'clang-version-9'... ! Failed with exit code 2. * Building target 'GCN3_X86.opt' with 'clang-version-9'... Done. * Building target 'GCN3_X86.fast' with 'clang-version-9'... ! Failed with exit code 2. * Building target 'Garnet_standalone.opt' with 'clang-version-9'... Done. * Building target 'Garnet_standalone.fast' with 'clang-version-9'... Done. * Building target 'X86_MOESI_AMD_Base.opt' with 'clang-version-9'... Done. * Building target 'X86_MOESI_AMD_Base.fast' with 'clang-version-9'... Done. * Building target 'ARM_MESI_Three_Level.opt' with 'clang-version-9'... Done. * Building target 'ARM_MESI_Three_Level.fast' with 'clang-version-9'... ! Failed with exit code 2. Starting build tests with 'clang-version-8'... * Building target 'X86_MOESI_AMD_Base.opt' with 'clang-version-8'... Done. * Building target 'X86_MOESI_AMD_Base.fast' with 'clang-version-8'... Done. Starting build tests with 'clang-version-7'... * Building target 'ARM_MESI_Three_Level.opt' with 'clang-version-7'... Done. * Building target 'ARM_MESI_Three_Level.fast' with 'clang-version-7'... ! Failed with exit code 2. Starting build tests with 'clang-version-6.0'... * Building target 'SPARC.opt' with 'clang-version-6.0'... Done. * Building target 'SPARC.fast' with 'clang-version-6.0'... Done. Starting build tests with 'clang-version-5.0'... * Building target 'X86_MOESI_AMD_Base.opt' with 'clang-version-5.0'... Done. * Building target 'X86_MOESI_AMD_Base.fast' with 'clang-version-5.0'... Done. Starting build tests with 'clang-version-4.0'... * Building target 'NULL_MOESI_hammer.opt' with 'clang-version-4.0'... Done. * Building target 'NULL_MOESI_hammer.fast' with 'clang-version-4.0'... Done. Starting build tests with 'clang-version-3.9'... * Building target 'Garnet_standalone.opt' with 'clang-version-3.9'... Done. * Building target 'Garnet_standalone.fast' with 'clang-version-3.9'... Done. Build step 'Execute shell' marked build as failure Archiving artifacts _______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org<mailto:gem5-dev@gem5.org> To unsubscribe send an email to gem5-dev-le...@gem5.org<mailto:gem5-dev-le...@gem5.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org<mailto:gem5-dev@gem5.org> To unsubscribe send an email to gem5-dev-le...@gem5.org<mailto:gem5-dev-le...@gem5.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org<mailto:gem5-dev@gem5.org> To unsubscribe send an email to gem5-dev-le...@gem5.org<mailto:gem5-dev-le...@gem5.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org<mailto:gem5-dev@gem5.org> To unsubscribe send an email to gem5-dev-le...@gem5.org<mailto:gem5-dev-le...@gem5.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Regards, Matt Sinclair Assistant Professor University of Wisconsin-Madison Computer Sciences Department cs.wisc.edu/~sinclair<http://cs.wisc.edu/~sinclair> -- Regards, Matt Sinclair Assistant Professor University of Wisconsin-Madison Computer Sciences Department cs.wisc.edu/~sinclair<http://cs.wisc.edu/~sinclair> _______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org<mailto:gem5-dev@gem5.org> To unsubscribe send an email to gem5-dev-le...@gem5.org<mailto:gem5-dev-le...@gem5.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Regards, Matt Sinclair Assistant Professor University of Wisconsin-Madison Computer Sciences Department cs.wisc.edu/~sinclair<http://cs.wisc.edu/~sinclair> _______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org<mailto:gem5-dev@gem5.org> To unsubscribe send an email to gem5-dev-le...@gem5.org<mailto:gem5-dev-le...@gem5.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
