Thanks for the info! Since it's looking like we'll need to keep GCC 5 around for a little while longer, I believe the following patch will fix the compilation issues we're facing: https://gem5-review.googlesource.com/c/public/gem5/+/45539
Bobby -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Fri, May 14, 2021 at 11:59 AM Kyle Roarty <kroa...@wisc.edu> wrote: > 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> > 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> > 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> > 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> > 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> > 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> 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> > 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> 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> 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> 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 > To unsubscribe send an email to 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 > > _______________________________________________ > 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 > > _______________________________________________ > 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 > > -- > Regards, > Matt Sinclair > Assistant Professor > University of Wisconsin-Madison > Computer Sciences Department > cs.wisc.edu/~sinclair > > -- > Regards, > Matt Sinclair > Assistant Professor > University of Wisconsin-Madison > Computer Sciences Department > cs.wisc.edu/~sinclair > > _______________________________________________ > 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 > > -- > Regards, > Matt Sinclair > Assistant Professor > University of Wisconsin-Madison > Computer Sciences Department > cs.wisc.edu/~sinclair > > _______________________________________________ > 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 > >
_______________________________________________ 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
