[gem5-dev] Re: The Nightly Build system is now Live (Compiler tests too!)
It's running on a Google Cloud VM. We're currently getting a feel for what kind of processing power we need, especially as we start to expand and automate more testing over the next few months. So, right now, this gives us flexibility. There are plenty of ways to expand from here: a beefier VM, dedicated notes to spin jobs off to, etc. FYI (bit of an @all): Seems like Jenkins doesn't like pestering people with emails if a built was successful, so no email last night. I'm looking forward to seeing our first failure be posted here (well, kinda...), but if you want to see our tests passing, just visit https://jenkins.gem5.org :). Kind regards, Bobby -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Mon, Jul 27, 2020 at 11:48 PM Ciro Santilli wrote: > Fantastic!!! > > Which infrastructure does it run on? Google Cloud or something else? > -- > *From:* Bobby Bruce via gem5-dev > *Sent:* Monday, July 27, 2020 7:54 PM > *To:* gem5 Developer List > *Cc:* Bobby Bruce > *Subject:* [gem5-dev] The Nightly Build system is now Live (Compiler > tests too!) > > Dear all, > > After some tinkering, we now have a nightly build system deployed, run > from our Jenkins: https://jenkins.gem5.org. If I've set up the > permissions correctly, everyone should be able to see the status of all our > builds from there. Please note, at the time of writing, we're still > experimenting with other testing/building setups, so there may be builds > there that I haven't explained in this email. These can be ignored. > > Right now, the Nightly Builds compile the NULL, ARM, MIPS, POWER, RISCV, > SPARC, and X86 ".opt" variants of gem5, run the unit tests (those executed > via `scons build/null/unittests.opt`), and the "long" testlib regression > tests (those executed via `scons ./main.py run --length long` from the > `tests` directory) on the gem5 develop branch. In order to test that our > email provider is functioning correctly, I've set this up to send an email > to the gem5-dev mailing list on success or failure, though once I've > confirmed the email notifications are working correctly I'll switch this to > send on failure only. > > The nightly builds will execute every day at 11PM PST (6AM UTC). They take > around 6 to 7 hours to complete, therefore normally finishing around 6 to 7 > AM PST (1PM to 2PM UTC). The email sent on the failure will list the > commits included since the last run (in addition to the stdout/stderr logs, > and a link to an archive of the `test/.testing-results` directory) which > should help us narrow down any cause-of-failure. > > In addition to the Nightly Builds, there are also Compile Tests, which > I've setup to run every Wednesday. These take roughly 24 hours to complete > in our current setups, so expect results on Thursdays. The Compiler Tests > simply run the `./util/compiler-tests.sh` script on the develop branch. In > short, these run all variants of gem5, ".opt" and '.fast", across all major > versions of our supported compilers (not a complete cross product, but > decent coverage -- please see the script if you want to know exactly what's > run). > > That's pretty much it for now. We've got plans to expand what's tested in > the near future: running more tests, more frequently, as well as improve > testing for gem5 in general. I hope this email has given a decent overview > of what's going on, but please don't hesitate to get in contact with me if > you have any questions. > > I'd also like to take this opportunity to thank Mike Upton for helping us > set up the Jenkins server and deal with all the teething problems. His > assistance is much appreciated. > > Kind regards, > Bobby > -- > Dr. Bobby R. Bruce > Room 2235, > Kemper Hall, UC Davis > Davis, > CA, 95616 > > web: https://www.bobbybruce.net > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ 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] Change in gem5/gem5[develop]: base,scons: `-wno-deprecated-copy` added for hdf5.cc with GCC
Bobby R. Bruce has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/31754 )
Change subject: base,scons: `-wno-deprecated-copy` added for hdf5.cc with
GCC
..
base,scons: `-wno-deprecated-copy` added for hdf5.cc with GCC
As highlighted by Ciro here:
https://gem5-review.googlesource.com/c/public/gem5/+/31216, and
here: https://gem5.atlassian.net/browse/GEM5-365, It appears that GCC
versions >= 9 requires `-wno-deprecated-copy` which was removed in
commit: https://gem5-review.googlesource.com/c/public/gem5/+/31216.
`-wno-deprecated-copy` appears to work for all versions of GCC. Clang
does not require `-wno-deprecated-copy` nor `-wno-deprecated` for
sucessfull compilation. Therefore branching has been introduced to the
SConscript to address this and simplify the solution.
Change-Id: I233b32aa945d479dd429bb5591272608ba342d8d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31754
Reviewed-by: Bobby R. Bruce
Reviewed-by: Gabe Black
Maintainer: Bobby R. Bruce
Tested-by: kokoro
---
M src/base/SConscript
1 file changed, 4 insertions(+), 1 deletion(-)
Approvals:
Gabe Black: Looks good to me, approved
Bobby R. Bruce: Looks good to me, approved; Looks good to me, approved
kokoro: Regressions pass
diff --git a/src/base/SConscript b/src/base/SConscript
index 657528c..b7a0c1b 100644
--- a/src/base/SConscript
+++ b/src/base/SConscript
@@ -91,7 +91,10 @@
Source('stats/group.cc')
Source('stats/text.cc')
if env['USE_HDF5']:
-Source('stats/hdf5.cc', append={'CXXFLAGS': '-Wno-deprecated'})
+if main['GCC']:
+Source('stats/hdf5.cc',
append={'CXXFLAGS': '-Wno-deprecated-copy'})
+else:
+Source('stats/hdf5.cc')
GTest('addr_range.test', 'addr_range.test.cc')
GTest('addr_range_map.test', 'addr_range_map.test.cc')
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/31754
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I233b32aa945d479dd429bb5591272608ba342d8d
Gerrit-Change-Number: 31754
Gerrit-PatchSet: 6
Gerrit-Owner: Bobby R. Bruce
Gerrit-Reviewer: Bobby R. Bruce
Gerrit-Reviewer: Ciro Santilli
Gerrit-Reviewer: Gabe Black
Gerrit-Reviewer: Jason Lowe-Power
Gerrit-Reviewer: kokoro
Gerrit-MessageType: merged
___
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] Change in gem5/gem5[develop]: configs, mem: Support running VIPER with GCN3
Kyle Roarty has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/30274 )
Change subject: configs, mem: Support running VIPER with GCN3
..
configs, mem: Support running VIPER with GCN3
This changeset adds the necessary changes for running
GCN3 ISA with VIPER in apu_se.py.
Changes to the VIPER protocol configs are made to add support
for DMA and scalar caches.
hsaTopology is added to help the pseudo FS create the files
needed by ROCm to understand the device on which the SW is
being run.
Change-Id: I0f47a6a36bb241a26972c0faafafcf332a7d7d1f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30274
Reviewed-by: Matt Sinclair
Maintainer: Bradford Beckmann
Tested-by: kokoro
---
M configs/example/apu_se.py
A configs/example/hsaTopology.py
M configs/ruby/GPU_VIPER.py
M src/mem/request.hh
M src/mem/ruby/protocol/GPU_VIPER-SQC.sm
5 files changed, 311 insertions(+), 73 deletions(-)
Approvals:
Matt Sinclair: Looks good to me, approved
Bradford Beckmann: Looks good to me, approved
kokoro: Regressions pass
diff --git a/configs/example/apu_se.py b/configs/example/apu_se.py
index 0ff80d8..4e9c75f 100644
--- a/configs/example/apu_se.py
+++ b/configs/example/apu_se.py
@@ -32,7 +32,7 @@
from __future__ import print_function
from __future__ import absolute_import
-import optparse, os, re
+import optparse, os, re, getpass
import math
import glob
import inspect
@@ -49,6 +49,9 @@
from common import Simulation
from common import GPUTLBOptions, GPUTLBConfig
+import hsaTopology
+from common import FileSystemConfig
+
## Script Options
def setOption(parser, opt_str, value = 1):
# check to make sure the option actually exists
@@ -77,9 +80,7 @@
parser.add_option("--cpu-only-mode", action="store_true", default=False,
help="APU mode. Used to take care of problems in "\
"Ruby.py while running APU protocols")
-parser.add_option("-k", "--kernel-files",
- help="file(s) containing GPU kernel code (colon
separated)")
-parser.add_option("-u", "--num-compute-units", type="int", default=1,
+parser.add_option("-u", "--num-compute-units", type="int", default=4,
help="number of GPU compute units"),
parser.add_option("--num-cp", type="int", default=0,
help="Number of GPU Command Processors (CP)")
@@ -89,21 +90,34 @@
# it an option/knob
parser.add_option("--cu-per-sqc", type="int", default=4, help="number of
CUs" \
"sharing an SQC (icache, and thus icache TLB)")
+parser.add_option('--cu-per-scalar-cache', type='int', default=4,
+ help='Number of CUs sharing a scalar cache')
parser.add_option("--simds-per-cu", type="int", default=4, help="SIMD
units" \
"per CU")
+parser.add_option('--cu-per-sa', type='int', default=4,
+ help='Number of CUs per shader array. This must be a '
+ 'multiple of options.cu-per-sqc and
options.cu-per-scalar')
+parser.add_option('--sa-per-complex', type='int', default=1,
+ help='Number of shader arrays per complex')
+parser.add_option('--num-gpu-complexes', type='int', default=1,
+ help='Number of GPU complexes')
parser.add_option("--wf-size", type="int", default=64,
help="Wavefront size(in workitems)")
parser.add_option("--sp-bypass-path-length", type="int", default=4, \
- help="Number of stages of bypass path in vector ALU for
Single Precision ops")
+ help="Number of stages of bypass path in vector ALU for "
+ "Single Precision ops")
parser.add_option("--dp-bypass-path-length", type="int", default=4, \
- help="Number of stages of bypass path in vector ALU for
Double Precision ops")
+ help="Number of stages of bypass path in vector ALU for "
+ "Double Precision ops")
# issue period per SIMD unit: number of cycles before issuing another
vector
parser.add_option("--issue-period", type="int", default=4, \
help="Number of cycles per vector instruction issue
period")
parser.add_option("--glbmem-wr-bus-width", type="int", default=32, \
- help="VGPR to Coalescer (Global Memory) data bus width
in bytes")
+ help="VGPR to Coalescer (Global Memory) data bus width "
+ "in bytes")
parser.add_option("--glbmem-rd-bus-width", type="int", default=32, \
- help="Coalescer to VGPR (Global Memory) data bus width
in bytes")
+ help="Coalescer to VGPR (Global Memory) data bus width
in "
+ "bytes")
# Currently we only support 1 local memory pipe
parser.add_option("--shr-mem-pipes-per-cu", type="int", default=1, \
help="Number of Shared
[gem5-dev] Change in gem5/gem5[develop]: dev-arm: relax GenericTimer check for CPU count
Ciro Santilli has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/31894 )
Change subject: dev-arm: relax GenericTimer check for CPU count
..
dev-arm: relax GenericTimer check for CPU count
At Iff9ad68d64e67b3df51682b7e4e272e5f355bcd6 a check was added to prevent
segfaults when unserializing the GenericTimer in case the new number of
thread contexts was smaller than the old one pre-checkpoint.
However, GenericTimer objects are only created dynamically as needed after
timer miscreg accesses. Therefore, if we take the checkpoint before
touching those registers, e.g. from a simple baremetal example, then the
checkpoint saves zero timers, and upon restore the assert would fail
because we have one thread context and not zero:
fatal: The simulated system has been initialized with 1 CPUs, but the
Generic Timer checkpoint expects 0 CPUs. Consider restoring the checkpoint
specifying 0 CPUs.
This commit solves that by ensuring only that the new thread context count
larger than, but not necessarily equal to the number of cores.
Change-Id: I8bcb05a6faecd4b4845f7fd4d71df95041bf6c99
JIRA: https://gem5.atlassian.net/browse/GEM5-703
---
M src/dev/arm/generic_timer.cc
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/dev/arm/generic_timer.cc b/src/dev/arm/generic_timer.cc
index bf6cd4e..0a44adf 100644
--- a/src/dev/arm/generic_timer.cc
+++ b/src/dev/arm/generic_timer.cc
@@ -426,7 +426,7 @@
cpu_count = OLD_CPU_MAX;
}
-if (cpu_count != system.threads.size()) {
+if (cpu_count > system.threads.size()) {
fatal("The simulated system has been initialized with %d CPUs, "
"but the Generic Timer checkpoint expects %d CPUs. Consider "
"restoring the checkpoint specifying %d CPUs.",
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/31894
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I8bcb05a6faecd4b4845f7fd4d71df95041bf6c99
Gerrit-Change-Number: 31894
Gerrit-PatchSet: 1
Gerrit-Owner: Ciro Santilli
Gerrit-MessageType: newchange
___
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] Change in gem5/gem5[develop]: sim: add UNSERIALIZE_ARRAY_INCOMPLETE
Ciro Santilli has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/31895 )
Change subject: sim: add UNSERIALIZE_ARRAY_INCOMPLETE
..
sim: add UNSERIALIZE_ARRAY_INCOMPLETE
This new serialization method allows the number of unserialized array
elements to be smaller than the new number of elements.
This allows new entries to be added to the end of arrays without breaking
checkpoints.
Change-Id: Ia9588dde24d1eb988d34789fca2883a1c9e7b39d
---
M src/sim/serialize.hh
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/src/sim/serialize.hh b/src/sim/serialize.hh
index 1f31dd2..b8c0c8c 100644
--- a/src/sim/serialize.hh
+++ b/src/sim/serialize.hh
@@ -586,7 +586,7 @@
template
void
arrayParamIn(CheckpointIn , const std::string ,
- T *param, unsigned size)
+ T *param, unsigned size, bool exact_size = true)
{
const std::string (Serializable::currentSection());
std::string str;
@@ -604,9 +604,15 @@
// Need this if we were doing a vector
// value.resize(tokens.size());
-fatal_if(tokens.size() != size,
- "Array size mismatch on %s:%s (Got %u, expected %u)'\n",
- section, name, tokens.size(), size);
+if (exact_size) {
+fatal_if(tokens.size() != size,
+ "Array size mismatch on %s:%s (Got %u, expected %u)'\n",
+ section, name, tokens.size(), size);
+} else {
+fatal_if(tokens.size() > size,
+ "Array size smaller on %s:%s (Got %u, expected %u)'\n",
+ section, name, tokens.size(), size);
+}
for (std::vector::size_type i = 0; i < tokens.size();
i++) {
// need to parse into local variable to handle vector,
@@ -717,8 +723,8 @@
std::string str;
if (!cp.find(section, name, str)) {
fatal("Can't unserialize '%s:%s'\n", section, name);
-}
param.clear();
+}
std::vector tokens;
tokenize(tokens, str, ' ');
@@ -814,6 +820,17 @@
arrayParamIn(cp, #member, member, size)
/**
+ * \def UNSERIALIZE_ARRAY_INCOMPLETE(member, size)
+ *
+ * Unserialize an array, and allow the serialization data to be
+ * smaller than the container size.
+ *
+ * @ingroup api_serialize
+ */
+#define UNSERIALIZE_ARRAY_INCOMPLETE(member, size) \
+arrayParamIn(cp, #member, member, size, false)
+
+/**
* \def SERIALIZE_CONTAINER(member)
*
* @ingroup api_serialize
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/31895
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Ia9588dde24d1eb988d34789fca2883a1c9e7b39d
Gerrit-Change-Number: 31895
Gerrit-PatchSet: 1
Gerrit-Owner: Ciro Santilli
Gerrit-MessageType: newchange
___
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] Change in gem5/gem5[develop]: sim: Add checkpoint parameters for VMA list
Ian Jiang has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/31875 )
Change subject: sim: Add checkpoint parameters for VMA list
..
sim: Add checkpoint parameters for VMA list
Add checkpoint parameters (together with corresponding serialization
and unserialization) for VMA list of class MemState into a separate
section named 'vmalist'.
Without these VMA list parameters, a page table fault will occur when
running with --restore-simpoint-checkpoint, because of an empty VMA
list. For example:
$ ./build/RISCV/gem5.debug --debug-flags=Exec configs/example/se.py \
-c tests/test-progs/hello/bin/riscv/linux/hello \
--cpu-type=NonCachingSimpleCPU --restore-simpoint-checkpoint \
--checkpoint-dir m5out/ -r 2
...
2404000: system.switch_cpus: T0 : @_int_malloc+3392: sd a5, 8(a0) \
: MemWrite : D=0x0001ed21 A=0x862e8
panic: Page table fault when accessing virtual address 0x862e8
...
Example checkpoint output:
[system.cpu.workload.vmalist]
size=3
[system.cpu.workload.vmalist.Vma0]
vmaName=stack
addrRangeStart=...
addrRangeEnd=...
[system.cpu.workload.vmalist.Vma1]
vmaName=heap
addrRangeStart=...
addrRangeEnd=...
[system.cpu.workload.vmalist.Vma2]
...
Change-Id: Ib2fa7ad2c34fe667ce95bc4b10a1affcf60d9c1f
Signed-off-by: Ian Jiang
---
M src/sim/mem_state.hh
1 file changed, 25 insertions(+), 0 deletions(-)
diff --git a/src/sim/mem_state.hh b/src/sim/mem_state.hh
index 1ca80da..bb4fab3 100644
--- a/src/sim/mem_state.hh
+++ b/src/sim/mem_state.hh
@@ -190,7 +190,18 @@
paramOut(cp, "stackMin", _stackMin);
paramOut(cp, "nextThreadStackBase", _nextThreadStackBase);
paramOut(cp, "mmapEnd", _mmapEnd);
+
+ScopedCheckpointSection sec(cp, csprintf("vmalist"));
+paramOut(cp, "size", _vmaList.size());
+int count = 0;
+for (auto vma : _vmaList) {
+ScopedCheckpointSection sec(cp, csprintf("Vma%d", count++));
+paramOut(cp, "vmaName", vma.getName());
+paramOut(cp, "addrRangeStart", vma.start());
+paramOut(cp, "addrRangeEnd", vma.end());
+}
}
+
void
unserialize(CheckpointIn ) override
{
@@ -201,6 +212,20 @@
paramIn(cp, "stackMin", _stackMin);
paramIn(cp, "nextThreadStackBase", _nextThreadStackBase);
paramIn(cp, "mmapEnd", _mmapEnd);
+
+int count;
+ScopedCheckpointSection sec(cp, csprintf("vmalist"));
+paramIn(cp, "size", count);
+for (int i = 0; i < count; ++i) {
+ScopedCheckpointSection sec(cp, csprintf("Vma%d", i));
+std::string name;
+Addr start;
+Addr end;
+paramIn(cp, "vmaName", name);
+paramIn(cp, "addrRangeStart", start);
+paramIn(cp, "addrRangeEnd", end);
+_vmaList.emplace_back(AddrRange(start, end), _pageBytes, name);
+}
}
/**
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/31875
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Ib2fa7ad2c34fe667ce95bc4b10a1affcf60d9c1f
Gerrit-Change-Number: 31875
Gerrit-PatchSet: 1
Gerrit-Owner: Ian Jiang
Gerrit-MessageType: newchange
___
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] Change in gem5/gem5[develop]: sim: Move checkpoint parameters for ptable into seperate section
Ian Jiang has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/31874 )
Change subject: sim: Move checkpoint parameters for ptable into seperate
section
..
sim: Move checkpoint parameters for ptable into seperate section
In checkpoint output files, the parameters for page table including
size and entries are organized not very clearly. For example:
[system.cpu.workload]
...
ptable.size=...
[system.cpu.workload.Entry0]
vaddr=...
paddr=...
flags=...
[system.cpu.workload.Entry1]
...
This commit moves these parameters into a separate section named
'ptable'. For example:
[system.cpu.workload.ptable]
size=...
[system.cpu.workload.ptable.Entry0]
vaddr=...
paddr=...
flags=...
[system.cpu.workload.ptable.Entry1]
...
Change-Id: Iaa4129b3f4f090e8c3651bde90524abba0999c7f
Signed-off-by: Ian Jiang
---
M src/mem/page_table.cc
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mem/page_table.cc b/src/mem/page_table.cc
index 400500b..20faf9b 100644
--- a/src/mem/page_table.cc
+++ b/src/mem/page_table.cc
@@ -168,7 +168,8 @@
void
EmulationPageTable::serialize(CheckpointOut ) const
{
-paramOut(cp, "ptable.size", pTable.size());
+ScopedCheckpointSection sec(cp, csprintf("ptable"));
+paramOut(cp, "size", pTable.size());
PTable::size_type count = 0;
for (auto : pTable) {
@@ -185,7 +186,8 @@
EmulationPageTable::unserialize(CheckpointIn )
{
int count;
-paramIn(cp, "ptable.size", count);
+ScopedCheckpointSection sec(cp, csprintf("ptable"));
+paramIn(cp, "size", count);
for (int i = 0; i < count; ++i) {
ScopedCheckpointSection sec(cp, csprintf("Entry%d", i));
--
To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/31874
To unsubscribe, or for help writing mail filters, visit
https://gem5-review.googlesource.com/settings
Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: Iaa4129b3f4f090e8c3651bde90524abba0999c7f
Gerrit-Change-Number: 31874
Gerrit-PatchSet: 1
Gerrit-Owner: Ian Jiang
Gerrit-MessageType: newchange
___
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] Re: The Nightly Build system is now Live (Compiler tests too!)
Fantastic!!! Which infrastructure does it run on? Google Cloud or something else? From: Bobby Bruce via gem5-dev Sent: Monday, July 27, 2020 7:54 PM To: gem5 Developer List Cc: Bobby Bruce Subject: [gem5-dev] The Nightly Build system is now Live (Compiler tests too!) Dear all, After some tinkering, we now have a nightly build system deployed, run from our Jenkins: https://jenkins.gem5.org. If I've set up the permissions correctly, everyone should be able to see the status of all our builds from there. Please note, at the time of writing, we're still experimenting with other testing/building setups, so there may be builds there that I haven't explained in this email. These can be ignored. Right now, the Nightly Builds compile the NULL, ARM, MIPS, POWER, RISCV, SPARC, and X86 ".opt" variants of gem5, run the unit tests (those executed via `scons build/null/unittests.opt`), and the "long" testlib regression tests (those executed via `scons ./main.py run --length long` from the `tests` directory) on the gem5 develop branch. In order to test that our email provider is functioning correctly, I've set this up to send an email to the gem5-dev mailing list on success or failure, though once I've confirmed the email notifications are working correctly I'll switch this to send on failure only. The nightly builds will execute every day at 11PM PST (6AM UTC). They take around 6 to 7 hours to complete, therefore normally finishing around 6 to 7 AM PST (1PM to 2PM UTC). The email sent on the failure will list the commits included since the last run (in addition to the stdout/stderr logs, and a link to an archive of the `test/.testing-results` directory) which should help us narrow down any cause-of-failure. In addition to the Nightly Builds, there are also Compile Tests, which I've setup to run every Wednesday. These take roughly 24 hours to complete in our current setups, so expect results on Thursdays. The Compiler Tests simply run the `./util/compiler-tests.sh` script on the develop branch. In short, these run all variants of gem5, ".opt" and '.fast", across all major versions of our supported compilers (not a complete cross product, but decent coverage -- please see the script if you want to know exactly what's run). That's pretty much it for now. We've got plans to expand what's tested in the near future: running more tests, more frequently, as well as improve testing for gem5 in general. I hope this email has given a decent overview of what's going on, but please don't hesitate to get in contact with me if you have any questions. I'd also like to take this opportunity to thank Mike Upton for helping us set up the Jenkins server and deal with all the teething problems. His assistance is much appreciated. Kind regards, Bobby -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net ___ 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
