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
