Ok, sounds good, I'll put together a CL for bumping clang up to v6, and we can discuss further there.
Any opposition/thoughts on going all the way up to v9? Like I said, I would like to de-macro all the things, and that gives us consistent access to some tools that will help do that. Gabe On Mon, May 17, 2021 at 1:08 PM Bobby Bruce <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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:* [email protected] <[email protected]> >>>> *Sent:* Friday, May 14, 2021 1:07 PM >>>> *To:* gem5 Developer List <[email protected]> >>>> *Cc:* Matt Sinclair <[email protected]>; Poremba, Matthew < >>>> [email protected]>; Gabe Black <[email protected]>; Bobby >>>> Bruce <[email protected]> >>>> *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 < >>>> [email protected]> 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 <[email protected]> >>>> 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 < >>>> [email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 < >>>> [email protected]> 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 < >>>> [email protected]> 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 <[email protected]> >>>> 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 < >>>> [email protected]> 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 < >>>> [email protected]> 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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>>> >>>> _______________________________________________ >>>> gem5-dev mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>>> >>>> _______________________________________________ >>>> gem5-dev mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>>> >>>> _______________________________________________ >>>> gem5-dev mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>>> >>>>
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
