https://gem5-review.googlesource.com/c/public/gem5/+/45621
On Mon, May 17, 2021 at 4:59 PM Gabe Black <gabe.bl...@gmail.com> wrote: > 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 <bbr...@ucdavis.edu> 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 <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
