llvm: optionally build compiler-rt, libcxx and libunwind as runtimes by skosukhin · Pull Request #32476 · spack/spack

skosukhin · 2022-09-01T13:49:34Z

The main idea of this PR is to build compiler-rt, libcxx and libunwind as runtimes (not only when @15:, which was added in #32397 while I was working on this). This, for example, makes it possible to build libcxx even when @13:%gcc@:10.

I have also gone through several patches and updated constraints and comments for them. I also tried to remove patch files from Spack repo and switch to fetching them from the upstream repo, if possible (see #32476 (comment)). ~~There might be more patch files that can be removed from the repo in a similar way but I touched only those that I had to.~~

A short discussion that started with #29530 (comment) might be worth mentioning here.

skosukhin · 2022-09-02T14:40:05Z

The reason for 2d509b5 is described in #32492.

trws · 2022-09-02T15:10:08Z

var/spack/repos/builtin/packages/llvm/package.py

    variant(
        "flang",
        default=False,
-        when="@11: +clang",


Why is this being removed?

#32476 (comment)

var/spack/repos/builtin/packages/llvm/package.py

trws · 2022-09-02T15:11:08Z

var/spack/repos/builtin/packages/llvm/package.py

-        default=True,
-        when="+clang",
-        description="Build the libcxxabi libunwind",
+        "libunwind",


If you want to add an alias with this name, do it, and we can deprecate the old one, but too many things rely on the variants of this package to do it without a deprecation period at this point.

I am sorry. Is there a feature alias or should I simply add a new variant? Does it make much sense, given that the possible values of the variant change anyway from True/False to "none"/"project"/"runtime"? Regarding things that depend on this. Do you mean in the Spack repo? I think I have updated the corresponding packages that depend on llvm. Or do you mean that there are people who use develop in production and expect their configuration files to be compatible with it at all times? I personally dropped this idea 5 years ago.

I don't mind creating an alias, of course, I just want the variants to be consistent with the upstream names to make it easier to understand what is what. I would also replace omp with ~~libomp~~ openmp but didn't want to touch omp_debug and omp_tsan too.

I mean in the spack repo and in other downstream package repos, we've had significant breakage and complaints from previous changes of variant names without a transition period, which is what I'm trying to avoid. The problem is actually the people that don't live on develop, they want a release with the variant marked as deprecated before it is removed in the following one, basically.

We do not currently have an alias feature, though supposedly that's in the works, it would be a separate variant, probably with a default dependent on the value of the existing one for now and set up such that they can't disagree. Annoying I know, but more kind to stable deployments.

trws · 2022-09-02T15:11:36Z

var/spack/repos/builtin/packages/llvm/package.py

-        description="Build the libcxxabi libunwind",
+        "libunwind",
+        values=("none", "project", conditional("runtime", when="+clang @6:")),
+        default="runtime",


Is there ever a reason not to build it as a runtime in versions after it becomes safe to do so?

Good question. Do you mean that we could have +libunwind (or even +internal_unwind) and decide on how to build the component based on the version we build and whether +clang is set? I thought of it and have to admit that I don't have bulletproof arguments against that.

However, I generally try not to limit the users if possible: if a package can be built in a certain configuration and its developers do not say "don't do that", I don't want to make the decision for the users. Also, llvm is heavily used as just a set of libraries (without clang) and the users might want them to be built with the same compiler they use to compile their projects.

Two more things here:

For me, +clang libunwind=runtime and ~clang libunwind=project read better then just +clang and ~clang because I would have to read package.py to understand whether the library that I need is built with the compiler that I want to use.

If we are talking about some backwards compatibility, all packages that had llvm+internal_unwind (llvm~internal_unwind) as a dependency can simply go for llvm libunwind=project (llvm libunwind=none) and don't be afraid that suddenly libunwind is built as a runtime.

I think that I follow the variant name change. Its just for consistently with upstream and I think this is a win for us.

trws · 2022-09-02T15:12:21Z

var/spack/repos/builtin/packages/llvm/package.py

-        default=True,
-        when="+clang @12:",
-        description="Build OpenMP runtime via ENABLE_RUNTIME by just-built Clang",
+        "omp",


Same variant issue as above, name needs to have a deprecation period.

Ok. I will then go further and make it openmp, openmp_tsan and openmp_debug.

var/spack/repos/builtin/packages/llvm/package.py

trws · 2022-09-02T15:13:51Z

var/spack/repos/builtin/packages/llvm/package.py

+    conflicts("+flang", when="@:10")
+    conflicts("+flang", when="~clang")
+    conflicts("+lldb", when="~clang")
+    conflicts("+z3", when="@:7")
+    conflicts("+z3", when="~clang")


Ah, got it, I can resolve the other comments, but I would greatly prefer that these be grouped with the appropriate variant() directives so they're easier to take in as a whole.

I agree. It's just for simple packages we usually have variants, then depends_ons and then conflicts, which is not necessary in general, as far as I know, and makes the code significantly less readable in this case.

trws · 2022-09-02T15:18:28Z

var/spack/repos/builtin/packages/llvm/package.py

+    # libcxx=project imposes compiler conflicts
+    # see https://libcxx.llvm.org/#platform-and-compiler-support for the latest release
+    # and https://github.com/llvm/www-releases for older releases
+    with when("libcxx=project"):


@tgamblin we need a way to deal with useful things like this for the caching stuff, all the inputs are literal, but the directive calls receive variables. Maybe something we could explore https://pypi.org/project/pystarlark/ for, make an invocation of pyskylark with a literal containing directives behave like invocations of those literals? Or, easier, make it so we can import directives from a flat yaml or json value or better dhall or cue document or something? We need to be able to do this stuff, but not being able to cache llvm (given its ubiquity and complexity) would be really unfortunate. =/

trws · 2022-09-02T15:20:56Z

var/spack/repos/builtin/packages/llvm/package.py

-    # sys/ustat.h has been removed in favour of statfs from glibc-2.28. Use fixed sizes:
-    patch("llvm5-sanitizer-ustat.patch", when="@4:6.0.0+compiler-rt")
-
    # Fix lld templates: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230463
    patch("llvm4-lld-ELF-Symbols.patch", when="@4+lld%clang@6:")
    patch("llvm5-lld-ELF-Symbols.patch", when="@5+lld%clang@7:")

-    # Fix missing std:size_t in 'llvm@4:5' when built with '%clang@7:'
-    patch("xray_buffer_queue-cstddef.patch", when="@4:5+compiler-rt%clang@7:")
+    # fix missing ::size_t in 'llvm@4:5'
+    # see comments in the patch file
+    patch(
+        "xray_buffer_queue-cstddef.patch",
+        # we do not cover compiler-rt=runtime because it is not supported when @:5
+        when="@4:5 compiler-rt=project",
+    )

-    # https://github.com/llvm/llvm-project/commit/947f9692440836dcb8d88b74b69dd379d85974ce
-    patch("sanitizer-ipc_perm_mode.patch", when="@5:7+compiler-rt%clang@11:")
-    patch("sanitizer-ipc_perm_mode.patch", when="@5:9+compiler-rt%gcc@9:")
+    # fix building of older versions of llvm with newer versions of glibc
+    for compiler_rt_as in ["project", "runtime"]:
+        with when("compiler-rt={0}".format(compiler_rt_as)):
+            # sys/ustat.h has been removed in favour of statfs from glibc-2.28
+            # see https://reviews.llvm.org/D47281
+            patch(
+                "https://github.com/llvm/llvm-project/commit/383fe5c8668f63ef21c646b43f48da9fa41aa100.patch?full_index=1",
+                sha256="66f01ac1769a6815aba09d6f4347ac1744f77f82ec9578a1158b24daca7a89e6",
+                when="@4:6.0.0",
+            )
+            # fix sanitizer-common build with glibc 2.31
+            # see https://reviews.llvm.org/D70662
+            patch("sanitizer-ipc_perm_mode.patch", when="@5:9")
+    del compiler_rt_as


Is the result of this that we get the same patches in the same cases? It looks like it but I haven't checked through the llvm commit output to be completely sure.

~~I guess I should give a summary of the patch modifications:~~

see #32476 (comment)

trws · 2022-09-02T15:22:29Z

var/spack/repos/builtin/packages/llvm/package.py

-                runtimes.extend(["libcxx", "libcxxabi"])
-            else:
-                projects.extend(["libcxx", "libcxxabi"])
+        if "compiler-rt=runtime" in spec:


If we can standardize on this style, it might be nice to loop over keys in the spec with a given property, and add them to runtimes or projects based on their value. Loving this refactor overall if we can make it fly. 👍

Could you, please, give an example of how to "loop over keys in the spec with a given property"? I thought of refactoring it but the problem was that the variant omp adds openmp and the variant libcxx adds libcxx and libcxxabi. Currently we'd have something like:

for var, params in { "omp": ["openmp"], "libunwind": ["libunwind"], "libcxx": ["libcxx", "libcxxabi"], "compiler-rt": ["compiler-rt"], }.items(): val = spec.variants[var].value if val == "project": projects.extend(params) elif val == "runtime": runtimes.extend(params)

Does it really make sense?

trws · 2022-09-02T15:23:42Z

Also, if you'd like to be a maintainer, I think @haampie and I would welcome the help. There may be some significant changes coming down soon to try and unify the llvm building support across more parts of spack, and having another pair of eyes would be fantastic.

skosukhin · 2022-09-02T17:01:39Z

Also, if you'd like to be a maintainer, I think @haampie and I would welcome the help.

I have already added myself to the list (see 42d01d8). Is there more to do for now regarding that?

skosukhin · 2022-09-05T14:46:06Z

Summary of the patch modifications:

libomp-libflags-as-list.patch - same contents fetched from upstream, the old condition was @3.7:14, the new one is @3.7:14 openmp=project (I could not reproduce the failure either with openmp=project or with openmp=runtime but the comment for the patch said make libflags a list in openmp subproject when ~omp_as_runtime, therefore I assume it is not needed when openmp=runtime)
llvm14-hwloc-ompd.patch - replaced with a "proper" fix from upstream, the old condition was @14, the new one is @14 omp=runtime (I have managed to reproduce the failure when openmp=runtime but openmp=project works without the patch).
constexpr_longdouble.patch and constexpr_longdouble_9.0.patch - same conditions (the old one was +libcxx, the new ones are libcxx=project and libcxx=runtime), same contents fetched from upstream.
llvm5-sanitizer-ustat.patch - same conditions (the old one was +compiler-rt, the new ones are compiler-rt=project and compiler-rt=runtime), same contents fetched from upstream.
sanitizer-ipc_perm_mode.patch - replaced with a "proper" fix from upstream but cannot be fetched since the names of the patched files have changed, the old conditions were @5:7+compiler-rt%clang@11: and @5:9+compiler-rt%gcc@9:, the new ones are @5:9 compiler-rt=project and @5:9 compiler-rt=runtime (the fixed issue has to do with the version of glibc and not the versions of the compiler).
llvm_python_path.patch - same contents fetched from upstream, the old condition was @:11, the new one is @7:11 (the patched logic was added in 7.0.0).
xray_buffer_queue-cstddef.patch - same contents, fixed comments why the patch is needed, no identical commit upstream (nothing to fetch), the old condition was @4:5+compiler-rt%clang@7:, the new one is @4:5 compiler-rt=project (compiler-rt=runtime is not possible when @:5 and the issue is related to the implementation of the C++ standard library, not the compiler version).
lldb_external_ncurses-10.patch - same contents fetched from upstream, the old condition was @10.0.0:11.0.1+lldb, the new one is @10:11+lldb (other 11.x versions need it too).
llvm_py37.patch - same contents fetched from upstream, the old condition was @4:6 ^[email protected]:, the new one is @4:6+python+lldb ^[email protected]: (the patch is not needed when either ~python or ~lldb).
llvm5-lld-ELF-Symbols.patch - same conditions, same contents fetched from the FreeBSD repo (where the patch initially comes from)
llvm4-lld-ELF-Symbols.patch - split into three parts: two parts are fetched from the FreeBSD repo (where the patch originally comes from) and applied under the same condition @4+lld%clang@6:, the third one is a duplicate of llvm_gcc7.patch (see below).
llvm_gcc7.patch - renamed to llvm4-lldb-Utility-TaskPool.patch, the old conditions were @4.0.0:4.0.1+lldb %[email protected]: and @4+lld%clang@6: (as part of llvm4-lld-ELF-Symbols.patch, see above), the new one is @4+lldb (the issue is related to the implementation of the C++ standard library, not the compiler version, and seems to be irrelevant for +lld~lldb.
missing-includes.patch - split into two parts: one part is fetched from upstream and applied under the new confition @8:9.0.0 (was @8), the second part is a duplicate of llvm-gcc11.patch (see below).
llvm-gcc11.patch - same contents fetched from upstream, the old conditions were @9:11%gcc@11:, @8 (as part of missing-includes.patch, see above) and @8:11 (as yet another patch fetched from upstream, see 8bc9eea), the new one is @8:11.
no_cyclades.patch - same conditions, same contents fetched from upstream
no_cyclades9.patch - updated comments, cannot be fetched since the names and formatting of the patched files have changed, the old condition was @6:9, the new one is @3.5.1:9 (the patch is applicable at least starting version 3.5.1, the oldest we try to support).

There seem to be no patches that could be fetched from a reliable source anymore.

skosukhin · 2022-09-05T15:29:13Z

@trws I have also renamed variants omp, omp_tsan and omp_debug to openmp, openmp_tsan and openmp_debug, respectively. I have added aliases omp_debug, internal_unwind, omp_tsan and omp_as_runtime (see 37021ef). Two questions now:

What should we do with libcxx and compiler-rt? The names of the variants are the same but cannot be set with +/~ anymore, e.g. +libcxx~compiler-rt. If we cannot solve this problem and make everything backward compatible, should we bother at all?
How do we warn the users that they use deprecated variants? There seem to be no parameter deprecated for the variant directive. I also thought of something like:
```
    variant(
        "omp_as_runtime",
        values=(True, False, "deprecated"),
        default="deprecated",
        sticky=True, ...
```
and then check whether any of the deprecated variants have value other than "deprecated" and issue a warning but that seems to be too much for Spack to handle.

UPD: The following does not seem to work either:

variant(
    "libcxx",
    values=disjoint_sets(
        # Deprecated values:
        (True, False),
        # New values:
        ("none",),
        ("project", conditional("runtime", when="+clang @6:")),
    ).prohibit_empty_set().with_default("runtime"), ...

trws · 2022-10-20T00:52:25Z

@haampie, how do you feel about this? I'd like to take it, but am still on the fence on how we should deal with variant breakage. For packages in tree they're all fixed here at least.

…euse 'llvm-gcc11.patch'

…r constraints for them

naromero77

@trws Do you have any additional comments about this PR?
@skosukhin Could you please test a couple of configuration with and with OpenMP target offload on your local desktop?

naromero77 · 2023-06-03T04:02:53Z

@spackbot help

spackbot-app · 2023-06-03T04:02:54Z

You can interact with me in many ways!

@spackbot hello: say hello and get a friendly response back!
@spackbot help or @spackbot commands: see this message
@spackbot run pipeline or @spackbot re-run pipeline: to request a new run of the GitLab CI pipeline
@spackbot rebuild everything: to run a pipeline rebuilding all specs from source.
@spackbot fix style if you have write and would like me to run spack style --fix for you.
@spackbot maintainers or @spackbot request review: to look for and assign reviewers for the pull request.

I'll also help to label your pull request and assign reviewers!
If you need help or see there might be an issue with me, open an issue here

naromero77 · 2023-06-03T04:03:56Z

@spackbot re-run pipeline

spackbot-app · 2023-06-03T04:03:59Z

I'm sorry, gitlab does not have your latest revision yet, I can't run that pipeline for you right now.

One likely possibility is that your PR pipeline has been temporarily deferred, in which case, it is awaiting a develop pipeline, and will be run when that finishes.

Please check the gitlab commit status message to see if more information is available.

Details

Unexpected response from gitlab: {'message': '404 Commit Not Found'}

…pack#32476) * llvm: replace +omp_as_runtime with omp=runtime * llvm: fetch 'libomp-libflags-as-list.patch' from upstream repo * llvm: replace 'llvm14-hwloc-ompd.patch' with the official fix from upstream repo * llvm: fix-up for the black reformatting * llvm: fetch 'constexpr_longdouble.patch' from upstream repo * llvm: optionally build libcxx as a runtime * llvm: fetch 'llvm5-sanitizer-ustat.patch' from upstream repo * llvm: update 'sanitizer-ipc_perm_mode.patch' * llvm: refactor compiler conflicts when libcxx=project * llvm: fetch 'llvm_python_path.patch' from upstream repo * llvm: update comments and condition for 'xray_buffer_queue-cstddef.patch' * llvm: optionally build compiler-rt as a runtime * llvm: fetch 'lldb_external_ncurses-10.patch' from upstream repo * llvm: fetch 'llvm_py37.patch' from upstream repo * llvm: rename variant 'internal_unwind' to 'libunwind' * llvm: optionally build libunwind as a runtime * llvm: extend the list of maintainers * llvm: allow for explicit '~clang~flang~libomptarget~lldb~omp_debug~z3' * llvm: fetch 'llvm5-lld-ELF-Symbols.patch' from FreeBSD port repo * llvm: fetch most of 'missing-includes.patch' from upstream repo and reuse 'llvm-gcc11.patch' * llvm: regroup patches for missing include directives and drop compiler constraints for them * llvm: fetch 'llvm-gcc11.patch' from upstream repo * llvm: fetch 'no_cyclades.patch' from upstream repo * llvm: update comments and condition for 'no_cyclades9.patch' * llvm: rename variant 'omp' to 'openmp' * llvm: constrain and rename variant 'omp_tsan' to 'libomp_tsan' * llvm: rename variant 'omp_debug' to 'libomptarget_debug' * llvm: do not apply same patch twice * llvm: constrain and document the '*-thread.patch' patches * llvm: document the '~lld+libomptarget' conflict * llvm: update comments for the 'D133513.diff' patch

@13-15

* llvm: add version 16.0.3 (spack#37472) * llvm: Fix hwloc@1 and hwloc@:2.3 compatibility (spack#35387) * llvm: optionally build compiler-rt, libcxx and libunwind as runtimes (spack#32476) * llvm: replace +omp_as_runtime with omp=runtime * llvm: fetch 'libomp-libflags-as-list.patch' from upstream repo * llvm: replace 'llvm14-hwloc-ompd.patch' with the official fix from upstream repo * llvm: fix-up for the black reformatting * llvm: fetch 'constexpr_longdouble.patch' from upstream repo * llvm: optionally build libcxx as a runtime * llvm: fetch 'llvm5-sanitizer-ustat.patch' from upstream repo * llvm: update 'sanitizer-ipc_perm_mode.patch' * llvm: refactor compiler conflicts when libcxx=project * llvm: fetch 'llvm_python_path.patch' from upstream repo * llvm: update comments and condition for 'xray_buffer_queue-cstddef.patch' * llvm: optionally build compiler-rt as a runtime * llvm: fetch 'lldb_external_ncurses-10.patch' from upstream repo * llvm: fetch 'llvm_py37.patch' from upstream repo * llvm: rename variant 'internal_unwind' to 'libunwind' * llvm: optionally build libunwind as a runtime * llvm: extend the list of maintainers * llvm: allow for explicit '~clang~flang~libomptarget~lldb~omp_debug~z3' * llvm: fetch 'llvm5-lld-ELF-Symbols.patch' from FreeBSD port repo * llvm: fetch most of 'missing-includes.patch' from upstream repo and reuse 'llvm-gcc11.patch' * llvm: regroup patches for missing include directives and drop compiler constraints for them * llvm: fetch 'llvm-gcc11.patch' from upstream repo * llvm: fetch 'no_cyclades.patch' from upstream repo * llvm: update comments and condition for 'no_cyclades9.patch' * llvm: rename variant 'omp' to 'openmp' * llvm: constrain and rename variant 'omp_tsan' to 'libomp_tsan' * llvm: rename variant 'omp_debug' to 'libomptarget_debug' * llvm: do not apply same patch twice * llvm: constrain and document the '*-thread.patch' patches * llvm: document the '~lld+libomptarget' conflict * llvm: update comments for the 'D133513.diff' patch * llvm: add new versions and set default for libomptarget according to os (spack#38092) * llvm: add new versions and set default for libomptarget according to os modified: var/spack/repos/builtin/packages/llvm/package.py * Incorporate reviewer suggestions Co-authored-by: Sergey Kosukhin <[email protected]> --------- Co-authored-by: Sergey Kosukhin <[email protected]> * Add 1606 (spack#38511) * llvm: fix build against libstdc++ 13 (spack#38329) llvm @13-15 is required for ispc, but fails to build with GCC 13. 14.0.6 and 15.0.7 built successfully with upstream patch, 13.0.1 still fails. Thus upstream patch is applied to 14 and 15 only. * ispc: on ARM, build with ARM targets enabled, and updates (spack#38080) * llvm: fix build with libcxx=none * ispc: checksum 1.20.0 * ispc: ensure that it does not crash immediately this would happen if linked to the wrong libc++ * ispc: fix build on macos find ncurses instead of curses and link against tinfo in order to avoid unresolved references to _del_curterm, _set_curterm, _setupterm, and _tigetnum * ispc: enable arm targets, if building on arm * ispc: remove double cmake argument I forgot to remove the constant -DARM_ENABLED=FALSE when adding -DARM_ENABLED with a value depending on target architecture * ispc: fix linux build since 1.20, linux build uses TBB as default tasking system and thus needs to depend on it * ispc: try to fix link error on linux link against both curses (as before) and tinfo (added because of macos) * ispc: update for recent llvm changes libcxx=none instead of ~libcxx --------- Co-authored-by: Satish Balay <[email protected]> Co-authored-by: Jordan Galby <[email protected]> Co-authored-by: Sergey Kosukhin <[email protected]> Co-authored-by: Sajid Ali <[email protected]> Co-authored-by: Sergey Kosukhin <[email protected]> Co-authored-by: Paul R. C. Kent <[email protected]> Co-authored-by: Martin Aumüller <[email protected]>

spackbot-app bot added conflicts dependencies maintainers patch update-package labels Sep 1, 2022

spackbot-app bot requested review from glennpj, haampie, trws and vchuravy September 1, 2022 13:49

skosukhin force-pushed the llvm_runtimes branch from b82f8bb to 42d01d8 Compare September 1, 2022 14:07

spackbot-app bot added the new-variant label Sep 2, 2022

trws reviewed Sep 2, 2022

View reviewed changes

var/spack/repos/builtin/packages/llvm/package.py Show resolved Hide resolved

trws reviewed Sep 2, 2022

View reviewed changes

var/spack/repos/builtin/packages/llvm/package.py Show resolved Hide resolved

trws reviewed Sep 2, 2022

View reviewed changes

skosukhin force-pushed the llvm_runtimes branch 2 times, most recently from d0592b4 to 31f238e Compare September 5, 2022 13:54

alalazo assigned trws Sep 12, 2022

skosukhin added 13 commits June 2, 2023 19:27

llvm: fetch 'llvm5-lld-ELF-Symbols.patch' from FreeBSD port repo

afbeb90

llvm: fetch most of 'missing-includes.patch' from upstream repo and r…

89121be

…euse 'llvm-gcc11.patch'

llvm: regroup patches for missing include directives and drop compile…

eb85569

…r constraints for them

llvm: fetch 'llvm-gcc11.patch' from upstream repo

af13d5b

llvm: fetch 'no_cyclades.patch' from upstream repo

1ea906b

llvm: update comments and condition for 'no_cyclades9.patch'

22dd242

llvm: rename variant 'omp' to 'openmp'

cbeb1ac

llvm: constrain and rename variant 'omp_tsan' to 'libomp_tsan'

d504d0b

llvm: rename variant 'omp_debug' to 'libomptarget_debug'

bc4c2a6

llvm: do not apply same patch twice

07b5f12

llvm: constrain and document the '*-thread.patch' patches

3218a03

llvm: document the '~lld+libomptarget' conflict

27f57cd

llvm: update comments for the 'D133513.diff' patch

c62cfef

skosukhin dismissed naromero77’s stale review via c62cfef June 2, 2023 18:13

skosukhin force-pushed the llvm_runtimes branch from 8bc9eea to c62cfef Compare June 2, 2023 18:13

spackbot-app bot added core PR affects Spack core functionality gitlab Issues related to gitlab integration labels Jun 2, 2023

naromero77 approved these changes Jun 2, 2023

View reviewed changes

naromero77 merged commit 7d5d075 into spack:develop Jun 4, 2023

skosukhin mentioned this pull request Sep 1, 2023

LLVM: Convert variant conflicts to when clauses #39753

Closed

Conversation

skosukhin commented Sep 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

skosukhin commented Sep 2, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skosukhin Sep 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skosukhin Sep 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

trws commented Sep 2, 2022

Uh oh!

skosukhin commented Sep 2, 2022

Uh oh!

skosukhin commented Sep 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

skosukhin commented Sep 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trws commented Oct 20, 2022

Uh oh!

naromero77 left a comment

Choose a reason for hiding this comment

Uh oh!

naromero77 commented Jun 3, 2023

Uh oh!

spackbot-app bot commented Jun 3, 2023

Uh oh!

naromero77 commented Jun 3, 2023

Uh oh!

spackbot-app bot commented Jun 3, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

skosukhin commented Sep 1, 2022 •

edited

Loading

skosukhin Sep 2, 2022 •

edited

Loading

skosukhin Sep 2, 2022 •

edited

Loading

skosukhin commented Sep 5, 2022 •

edited

Loading

skosukhin commented Sep 5, 2022 •

edited

Loading