I don't have any opposition, and don't know of any real reason we can't bump things up to Clang 6. Clang 6 is what you get by default on Ubuntu 18.04 with APT. As we no longer support 16.04, I think it'd be ok to bump things up to that. That being said, I don't think I've ever had any problems with earlier versions of clang. It's one of those "low effort to support but probably not giving us much value anyway" things.
-- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Fri, May 14, 2021 at 5:38 PM Gabe Black <gabe.bl...@gmail.com> wrote: > On this topic, what do people think about moving up the version of clang? > It would be great to get those __builtin_FILE and __builtin_LINE builtins, > since then we can potentially even un-macro really stubborn things like > panic and warn. Maybe not DPRINTF still, since that expects to call things > like curTick() and name() within the calling context, and I don't think > there's yet a good way to do that (grab the enclosing scope/context) > without a macro. > > I think we're less sensitive to the version of clang we're using? I think > using clang is a more proactive choice (I assume), and if you can choose > clang you could just fall back to gcc if yours wasn't new enough, and > with just a little more flexibility might be able to choose a newer one > which is in range. > > Gabe > > On Fri, May 14, 2021 at 5:32 PM Bobby Bruce <bbr...@ucdavis.edu> wrote: > >> 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
