{"id":20683228,"url":"https://github.com/tudasc/typeart","last_synced_at":"2025-04-22T12:21:54.631Z","repository":{"id":40506197,"uuid":"256218328","full_name":"tudasc/TypeART","owner":"tudasc","description":"LLVM-based type and memory allocation tracking sanitizer","archived":false,"fork":false,"pushed_at":"2025-03-19T19:53:48.000Z","size":2066,"stargazers_count":53,"open_issues_count":6,"forks_count":7,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-03-29T15:05:21.704Z","etag":null,"topics":["allocation","llvm","llvm-pass","memory-tracking","mpi","mpi-communication","mpi-datatype","sanitizer","type-safety"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tudasc.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":"AUTHORS","dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-04-16T13:09:49.000Z","updated_at":"2025-03-19T19:30:10.000Z","dependencies_parsed_at":"2024-12-16T15:38:19.002Z","dependency_job_id":"b314972d-bedf-4c64-b556-d7deeb305095","html_url":"https://github.com/tudasc/TypeART","commit_stats":null,"previous_names":[],"tags_count":12,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FTypeART","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FTypeART/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FTypeART/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tudasc%2FTypeART/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tudasc","download_url":"https://codeload.github.com/tudasc/TypeART/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250237885,"owners_count":21397412,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["allocation","llvm","llvm-pass","memory-tracking","mpi","mpi-communication","mpi-datatype","sanitizer","type-safety"],"created_at":"2024-11-16T22:15:58.280Z","updated_at":"2025-04-22T12:21:54.624Z","avatar_url":"https://github.com/tudasc.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"# TypeART \u0026middot; [![License](https://img.shields.io/badge/License-BSD%203--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause) ![](https://github.com/tudasc/TypeART/actions/workflows/basic-ci.yml/badge.svg?branch=master) ![](https://github.com/tudasc/TypeART/actions/workflows/ext-ci.yml/badge.svg?branch=master) [![Coverage Status](https://coveralls.io/repos/github/tudasc/TypeART/badge.svg?branch=master)](https://coveralls.io/github/tudasc/TypeART?branch=master)\n\n## What is TypeART?\n\nTypeART \\[[TA18](#ref-typeart-2018); [TA20](#ref-typeart-2020); [TA22](#ref-typeart-2022)\\] is a type and memory\nallocation tracking sanitizer based on the [LLVM](https://llvm.org) compiler toolchain for C/C++ (OpenMP) codes. It includes an LLVM compiler pass plugin for instrumentation and a runtime library to monitor memory allocations during program execution.\n\nTypeART instruments heap, stack, and global variable allocations with callbacks to its runtime, capturing:\n(1) the memory address, (2) the type-layout information of the allocation (e.g., built-ins, user-defined structs) and (3) number of elements.\n\n## Why use it?\n\nTypeART provides type-related information of allocations in your program to help verify some property, and to help\ngenerate diagnostics if it doesn't hold.\n\nLow-level C APIs often rely on `void*` pointers for generic types, requiring users to manually specify type and size - a process prone to errors. Examples for type unsafe APIs include the Message-Passing Interface (MPI),\ncheckpointing libraries and numeric solver libraries. \nTypeART simplifies verification, ensuring, for example, that a `void*` argument corresponds to an array of expected type `T` with length `n`.\n\n### Use Case: MUST - A dynamic MPI correctness checker\n\nMUST \\[[MU13](#ref-must-2013)\\], a dynamic MPI correctness checker, detects issues like deadlocks or mismatched MPI datatypes. For more details, visit its [project page](https://www.hpc.rwth-aachen.de/must/).\n\nMUST intercepts MPI calls for analysis but cannot deduce the *effective* type of `void*` buffers in MPI APIs. TypeART addresses this by tracking memory (de-)allocations relevant to MPI communication in user code, allowing MUST to validate type compatibility between MPI buffers and declared datatypes.\n\n#### Type checking for MPI calls\n\nTo demonstrate the utility of TypeART, consider the following code:\n\n```c\n// Otherwise unknown to MUST, TypeART tracks this allocation (memory address, type and size):\ndouble* array = (double*) malloc(length*sizeof(double));\n// MUST intercepts this MPI call, asking TypeART's runtime for type information:\n//   1. Is the first argument of type double (due to MPI_DOUBLE)?\n//   2. Is the allocation at least of size *length*? \nMPI_Send((void*) array, length, MPI_DOUBLE, ...)\n```\n\nMUST and TypeART also support MPI [derived datatypes](https://www.mpi-forum.org/docs/mpi-4.1/mpi41-report/node96.htm)\nwith complex underlying data structures. For further details, see\nour [publications](#references), or download MUST (v1.8 or higher integrates TypeART) from\nits [project page](https://itc.rwth-aachen.de/must/).\n\n## Table of Contents\n\n* [1. Using TypeART](#1-using-typeart)\n    * [1.1 Compiling a target code](#11-compiling-a-target-code)\n        * [1.1.1 Building with TypeART](#111-building-with-typeart)\n        * [1.1.2 Options for TypeART passes and compiler wrapper](#112-options-for-typeart-passes-and-compiler-wrapper)\n        * [1.1.3 Serialized type information](#113-serialized-type-information)\n        * [1.1.4 Filtering allocations](#114-filtering-allocations)\n    * [1.2 Executing an instrumented target code](#12-executing-an-instrumented-target-code)\n    * [1.3 Example: MPI demo](#13-example-mpi-demo)\n* [2. Building TypeART](#2-building-typeart)\n    * [2.1 Optional software requirements](#21-optional-software-requirements)\n    * [2.2 Building](#22-building)\n        * [2.2.1 CMake configuration: Options for users](#221-cmake-configuration-options-for-users)\n* [3. Consuming TypeART](#3-consuming-typeart)\n* [References](#references)\n\n## 1. Using TypeART\n\nUsing TypeART involves two phases:\n\n1. Compilation: Compile your code with Clang/LLVM (version 14) using the TypeART LLVM pass plugin. The plugin (1) serializes static type information to a file and (2) instruments relevant allocations. See [Section 1.1](#11-compiling-a-target-code).\n2. Execution: Run the instrumented program with a TypeART runtime client, which uses the callback data to perform analysis facilitating the static type information. See [Section 1.2](#12-executing-an-instrumented-target-code).\n\n### 1.1 Compiling a target code\n\nTypeART’s LLVM compiler pass plugins instrument allocations and serialize static type layouts into a YAML file (default: `typeart-types.yaml`). We provide compiler wrapper scripts (available in the bin folder of the TypeART installation) for Clang and MPI. By default, these wrappers instrument heap, stack, and global allocations, while MPI wrappers filter allocations unrelated to MPI calls (see [Section 1.1.4](#114-filtering-allocations)).\n\n*Note*: Currently, the compilation must be serialized, e.g., `make -j 1`, to ensure consistent type information across translation units.\n\n#### 1.1.1 Building with TypeART\n\nA typical compile invocation may first compile code to object files and then link with any libraries:\n\n```shell\n# Compile:\n$\u003e clang++ -O2 $(COMPILE_FLAGS) -c code.cpp -o code.o\n# Link:\n$\u003e clang++ $(LINK_FLAGS) code.o -o binary\n```\n\nWith TypeART, the recipe needs to be changed to, e.g., use our provided compiler wrapper, as we rely on the LLVM `opt`\n(optimizer) tool to load and apply our TypeART passes to a target code:\n\n```shell\n# Compile, replace direct clang++ call with wrapper of the TypeART installation:\n$\u003e typeart-clang++ -O2 $(COMPILE_FLAGS) -c code.cpp -o code.o\n# Link, also with the wrapper:\n$\u003e typeart-clang++ $(LINK_FLAGS) code.o -o binary\n```\n\nThe wrapper performs the following steps using Clang's `-fpass-plugin`:\n\n1. Compiles the code to LLVM IR retaining original compile flags.\n2. Applies heap instrumentation with TypeART (before optimizations).\n3. Optimizes the code using provided -O flag.\n4. Applies stack and global instrumentation with TypeART (after optimizations).\n5. Links the TypeART runtime library with the provided linker flags.\n\n*Note*: Heap allocations are instrumented before optimizations to prevent loss of type information in some cases.\n\n##### Wrapper usage in CMake build systems\n\nFor plain Makefiles, the wrapper replaces the GCC/Clang compiler variables, e.g., `CC` or `MPICC`. For CMake, during the\nconfiguration, it is advised to disable the wrapper temporarily. This is due to CMake executing internal compiler\nchecks, where we do not need TypeART instrumentation:\n\n```shell\n# Temporarily disable wrapper with environment flag TYPEART_WRAPPER=OFF for configuration:\n$\u003e TYPEART_WRAPPER=OFF cmake -B build -DCMAKE_C_COMPILER=*TypeART bin*/typeart-clang \n# Compile with typeart-clang:\n$\u003e cmake --build build --target install -- -j1\n```\n\n##### MPI wrapper generation\n\nThe wrappers `typeart-mpicc` and `typeart-mpic++` are generated for compiling MPI codes with TypeART.\nHere, we rely on detecting the vendor to generate wrappers with appropriate environment variables to force the use of\nthe Clang/LLVM compiler.\nWe support detection for OpenMPI, Intel MPI and MPICH based on `mpi.h` symbols, and use the following flags for setting the Clang compiler:\n\n| Vendor    | Symbol        | C compiler env. var  | C++ compiler env. var  |\n|-----------|---------------|----------------------|------------------------|\n| Open MPI  | OPEN_MPI      | OMPI_CC              | OMPI_CXX               |\n| Intel MPI | I_MPI_VERSION | I_MPI_CC             | I_MPI_CXX              |\n| MPICH     | MPICH_NAME    | MPICH_CC             | MPICH_CXX              |\n\n\n#### 1.1.2 Options for controlling the TypeART pass\n\nThe pass behavior can be configured with the environment flags as listed below. The TypeART pass prioritizes environment flags (if set) over the default configuration option.\n\nIn particular, `TYPEART_OPTIONS` can be set to globally modify the TypeART pass (stack/heap specific options exist).\nThe format requires the option names separated by a semicolon, e.g., `TYPEART_OPTIONS=\"filter-glob=API_*;no-stats\"` sets the filter glob target to `API_*` and deactivates stats printing of the TypeART pass. \nPrepending `no-` to boolean flags sets them to false.\n\n**Note**: Single environment options are prioritized over `TYPEART_OPTIONS`.\n\n\u003c!--- @formatter:off ---\u003e\n\n| Env. variable                              | Option name                        |    Default value     | Description                                                                                                                                    |\n| :----------------------------------------- | ---------------------------------- | :------------------: | ---------------------------------------------------------------------------------------------------------------------------------------------- |\n| `TYPEART_OPTIONS`                          |                                    |                      | Set multiple options at once, separated by `;`.                                                                                                |\n| `TYPEART_OPTIONS_STACK`                    |                                    |                      | Same as above for stack phase only.                                                                                                            |\n| `TYPEART_OPTIONS_HEAP`                     |                                    |                      | Same as above for heap phase only.                                                                                                             |\n| `TYPEART_TYPES`                            | `types`                            | `typeart-types.yaml` | Serialized type layout information of user-defined types. File location and name can also be controlled with the env variable `TYPEART_TYPES`. |\n| `TYPEART_HEAP`                             | `heap`                             |        `true`        | Instrument heap allocations                                                                                                                    |\n| `TYPEART_STACK`                            | `stack`                            |       `false`        | Instrument stack and global allocations. Enables instrumentation of global allocations.                                                        |\n| `TYPEART_STACK_LIFETIME`                   | `stack-lifetime`                   |        `true`        | Instrument stack `llvm.lifetime.start` instead of `alloca` directly                                                                            |\n| `TYPEART_GLOBAL`                           | `global`                           |       `false`        | Instrument global allocations (see stack).                                                                                                     |\n| `TYPEART_TYPEGEN`                          | `typegen`                          |       `dimeta`       | Values: `dimeta`, `ir`. How serializing of type information is done, see [Section 1.1.3](#113-serialized-type-information).                    |\n| `TYPEART_STATS`                            | `stats`                            |       `false`        | Show instrumentation statistic counters                                                                                                        |\n| `TYPEART_FILTER`                           | `filter`                           |       `false`        | Filter stack and global allocations. See also [Section 1.1.4](#114-filtering-allocations)                                                      |\n| `TYPEART_FILTER_IMPLEMENTATION`            | `filter-implementation`            |        `std`         | Values: `std`, `none`. See also [Section 1.1.4](#114-filtering-allocations)                                                                    |\n| `TYPEART_FILTER_GLOB`                      | `filter-glob`                      |       `*MPI_*`       | Filter API string target (glob string)                                                                                                         |\n| `TYPEART_FILTER_GLOB_DEEP`                 | `filter-glob-deep`                 |       `MPI_*`        | Filter values based on specific API: Values passed as ptr are correlated when string matched.                                                  |\n| `TYPEART_ANALYSIS_FILTER_GLOBAL`           | `analysis-filter-global`           |        `true`        | Filter global alloca based on heuristics                                                                                                       |\n| `TYPEART_ANALYSIS_FILTER_HEAP_ALLOCA`      | `analysis-filter-heap-alloca`      |        `true`        | Filter stack alloca that have a store instruction from a heap allocation                                                                       |\n| `TYPEART_ANALYSTS_FILTER_NON_ARRAY_ALLOCA` | `analysis-filter-non-array-alloca` |       `false`        | Filter scalar valued allocas                                                                                                                   |\n| `TYPEART_ANALYSIS_FILTER_POINTER_ALLOCA`   | `analysis-filter-pointer-alloca`   |        `true`        | Filter allocas of pointer types                                                                                                                |\n\nAdditionally, there are two debug environment flags for dumping the LLVM IR per phase (pre heap, heap, opt, stack) to a set of files.\n\n| Env. variable                   | Description                                                                                                                     |\n| :------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |\n| `TYPEART_WRAPPER_EMIT_IR`       | If set, the compiler wrapper will create 4 files for each TypeART phase with the file pattern `${source_basename}_heap.ll` etc. |\n| `TYPEART_PASS_INTERNAL_EMIT_IR` | Internal pass use only. Toggled by wrapper.                                                                                     |\n\n\u003c!--- @formatter:on ---\u003e\n\n#### 1.1.3 Serialized type information\n\nAfter instrumentation, the file `typeart-types.yaml` (`env TYPEART_TYPES`) contains the static type information. Each user-defined type layout is\nextracted and an integer `type-id` is attached to it. Built-in types (e.g., float) have pre-defined ids and byte\nlayouts.\nTo generate these type layouts, TypeART is using either the [LLVM IR type system](https://llvm.org/docs/LangRef.html#type-system) (`typegen=ir`), or using the external library [llvm-dimeta](https://github.com/ahueck/llvm-dimeta) (`typegen=dimeta`) which extracts type information using [LLVM debug metadata](https://llvm.org/docs/SourceLevelDebugging.html).\nThe latter is default, the former only works with LLVM 14.\n\nThe TypeART instrumentation callbacks use the `type-id`. The runtime library correlates the allocation with the\nrespective type (and layout) during execution. Consider the following struct:\n\nAfter instrumentation, the `typeart-types.yaml` file (also controlled via the `TYPEART_TYPES` environment variable) stores static type information. \nEach user-defined type layout is assigned a unique integer type-id. Built-in types (e.g., float) use predefined type-ids and byte layouts.\n\nDuring execution, TypeART’s runtime library uses the type-id from callbacks to associate allocations with their type and layout. For example, consider the following C struct:\n\n```c\nstruct s1_t {\n  char a[3];\n  struct s1_t* b;\n}\n```\n\nThe TypeART pass may write a `typeart-types.yaml` file with the following content:\n\u003c!--- @formatter:off ---\u003e\n\n```yaml\n- id: 256           // struct type-id\n  name: s1_t\n  extent: 16        // size in bytes\n  member_count: 2\n  offsets: [ 0, 8 ] // byte offsets from struct start\n  types: [ 5, 1 ]   // member type-ids (5-\u003echar, 1-\u003epointer)\n  sizes: [ 3, 1 ]   // member (array) length\n```\n\n\u003c!--- @formatter:on ---\u003e\n\n##### Limitations of LLVM IR Type System\n\nThe list of supported built-in type-ids is defined in [TypeInterface.h](lib/typelib/TypeInterface.h) and reflects the types that TypeART can represent with **LLVM Debug Metadata**.\nIn contrast, when using **LLVM IR Type System**, certain constraints are imposed. For instance, C/C++ types like unsigned integers are unsupported (and represented like signed integers). \n\n\n#### 1.1.4 Filtering allocations\n\nTo improve performance, a translation unit-local (TU) data-flow filter for global and stack variables exist. It follows the LLVM IR use-def chain. If the allocation provably never reaches the target API, it can be filtered. Otherwise, it is instrumented. Use the option `filter` to filter and `filter-glob=\u003ctarget API glob\u003e` (default: `*MPI_*`) to target the correct API.\n\nConsider the following example.\n\n```c\nextern foo_bar(float*); // No definition in the TU \nvoid bar(float* x, float* y) {\n  *x = 2.f; // x is not used after\n  MPI_Send(y, ...);\n}\nvoid foo() {\n  float a = 1.f, b = 2.f, c = 3.f;\n  bar(\u0026a, \u0026b);\n  foo_bar(\u0026c);\n}\n```\n\n1. The filter can remove `a`, as the aliasing pointer `x` is never part of an MPI call.\n2. `b` is instrumented as the aliasing pointer `y` is part of an MPI call.\n3. `c` is instrumented as we cannot reason about the body of `foo_bar`.\n\n### 1.2 Executing an instrumented target code\n\nTo execute the instrumented code, the TypeART runtime library (or a derivative) has to be loaded to accept the\ncallbacks. The library also requires access to the `typeart-types.yaml` file to correlate the `type-id` with the actual type\nlayouts. To specify its path, you can use the environment variable `TYPEART_TYPES`, e.g.:\n\n```shell\n$\u003e export TYPEART_TYPES=/path/to/typeart-types.yaml\n# If the TypeART runtime is not resolved, LD_LIBRARY_PATH is set:\n$\u003e env LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$(TYPEART_LIBPATH) ./binary\n```\n\nAn example for pre-loading a TypeART-based library in the context of MPI is found in the demo,\nsee [Section 1.3](#13-example-mpi-demo).\n\n### 1.3 Example: MPI demo\n\nThe folder [demo](demo) contains an example of MPI-related type errors that can be detected using TypeART. The code is\ncompiled with our instrumentation, and executed by preloading the MPI-related check library implemented\nin [tool.c](demo/tool.c). The check library uses the TypeART [runtime query interface](lib/runtime/RuntimeInterface.h).\nIt overloads the required MPI calls and checks that the passed `void*` buffer is correct w.r.t. the MPI derived\ndatatype.\n\nTo compile and run the demo targets:\n\n- Makefile\n    ```shell\n    # Valid MPI demo:\n    $\u003e MPICC=*TypeART prefix*/bin/typeart-mpicc make run-demo\n    # Type-error MPI demo:\n    $\u003e MPICC=*TypeART prefix*/bin/typeart-mpicc make run-demo_broken\n    ```\n- CMake, likewise:\n    ```shell\n    $\u003e TYPEART_WRAPPER=OFF cmake -S demo -B build_demo -DCMAKE_C_COMPILER=*TypeART prefix*/bin/typeart-mpicc \n    $\u003e cmake --build build_demo --target run-demo\n    $\u003e cmake --build build_demo --target run-demo_broken\n    ```\n\n## 2. Building TypeART\n\nTypeART supports LLVM version 14 and 18 and CMake version \u003e= 3.20.\n\n### 2.1 Optional software requirements\n\n- MPI library: (soft requirement) Needed for the MPI compiler wrappers, tests, the [demo](demo),\n  our [MPI interceptor library](lib/mpi_interceptor), and for logging with our TypeART runtime library within an MPI\n  target application.\n- OpenMP-enabled Clang compiler: Needed for some tests.\n\nOther smaller, external dependencies are defined within the [externals folder](externals) (depending on configuration\noptions), see [Section 2.2.1 (Runtime)](#221-cmake-configuration-options-for-users). They are automatically downloaded\nduring configuration time (internet connection required).\n\n### 2.2 Building\n\nTypeART uses CMake to build, cf. [GitHub CI build file](.github/workflows/basic-ci.yml) for a complete recipe to build.\nExample build recipe (debug build, installs to default prefix\n`${typeart_SOURCE_DIR}/install/typeart`)\n\n```sh\n$\u003e git clone https://github.com/tudasc/TypeART\n$\u003e cd TypeART\n$\u003e cmake -B build\n$\u003e cmake --build build --target install --parallel\n```\n\n#### 2.2.1 CMake configuration: Options for users\n\n##### Binaries (scripts)\n\n\u003c!--- @formatter:off ---\u003e\n\n| Option                       | Default | Description                                                                      |\n| ---------------------------- | :-----: | -------------------------------------------------------------------------------- |\n| `TYPEART_MPI_WRAPPER`        |  `ON`   | Install TypeART MPI wrapper (mpic, mpic++). Requires MPI.                        |\n| `TYPEART_USE_LEGACY_WRAPPER` |  `OFF`  | Use legacy wrapper invoking opt/llc directly instead of Clang's `-fpass-plugin`. |\n\n\n\u003c!--- @formatter:on ---\u003e\n\n##### Runtime\n\n\u003c!--- @formatter:off ---\u003e\n\n| Option                 | Default | Description                                                                                                             |\n|------------------------|:-------:|-------------------------------------------------------------------------------------------------------------------------|\n| `TYPEART_ABSEIL`       |  `ON`   | Enable usage of btree-backed map of the [Abseil project](https://abseil.io/) (LTS release) for storing allocation data. |\n| `TYPEART_PHMAP`        |  `OFF`  | Enable usage of a [btree-backed map](https://github.com/greg7mdp/parallel-hashmap) (alternative to Abseil).             |\n| `TYPEART_SOFTCOUNTERS` |  `OFF`  | Enable runtime tracking of #tracked addrs. / #distinct checks / etc.                                                    |\n| `TYPEART_LOG_LEVEL_RT` |   `0`   | Granularity of runtime logger. 3 is most verbose, 0 is least.                                                           |\n\n\u003c!--- @formatter:on ---\u003e\n\n###### Runtime thread-safety options\n\nDefault mode is to protect the global data structure with a (shared) mutex. Two main options exist:\n\n\u003c!--- @formatter:off ---\u003e\n\n| Option                           | Default  | Description                                                                                                                                        |\n|----------------------------------|:--------:|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| `TYPEART_DISABLE_THREAD_SAFETY`  |  `OFF`   | Disable thread safety of runtime                                                                                                                   |\n| `TYPEART_SAFEPTR`                |  `OFF`   | Instead of a mutex, use a special data structure wrapper for concurrency, see [object_threadsafe](https://github.com/AlexeyAB/object_threadsafe)   |\n\n\u003c!--- @formatter:on ---\u003e\n\n##### LLVM passes\n\n\u003c!--- @formatter:off ---\u003e\n\n| Option                       | Default | Description                                                                                       |\n|------------------------------|:-------:|---------------------------------------------------------------------------------------------------|\n| `TYPEART_SHOW_STATS`         |  `ON`   | Passes show compile-time summary w.r.t. allocations counts                                        |\n| `TYPEART_MPI_INTERCEPT_LIB`  |  `ON`   | Library to intercept MPI calls by preloading and check whether TypeART tracks the buffer pointer  |\n| `TYPEART_MPI_LOGGER`         |  `ON`   | Enable better logging support in MPI execution context                                            |\n| `TYPEART_LOG_LEVEL`          |   `0`   | Granularity of pass logger. 3 is most verbose, 0 is least                                         |\n\n\u003c!--- @formatter:on ---\u003e\n\n##### Testing\n\n\u003c!--- @formatter:off ---\u003e\n\n| Option                        | Default | Description                                                                                                  |\n|-------------------------------|:-------:|--------------------------------------------------------------------------------------------------------------|\n| `TYPEART_TEST_CONFIG`         |  `OFF`  | Enable testing, and set (force) logging levels to appropriate levels for test runner to succeed              |\n| `TYPEART_CODE_COVERAGE`       |  `OFF`  | Enable code coverage statistics using LCOV 1.14 and genhtml (gcovr optional)                                 |\n| `TYPEART_LLVM_CODE_COVERAGE`  |  `OFF`  | Enable llvm-cov code coverage statistics (llvm-cov and llvm-profdata  required)                              |\n| `TYPEART_ASAN, TSAN, UBSAN`   |  `OFF`  | Enable Clang sanitizers (tsan is mutually exclusive w.r.t. ubsan and  asan as they don't play well together) |\n\n\u003c!--- @formatter:on ---\u003e\n\n## 3. Consuming TypeART\nExample using CMake [FetchContent](https://cmake.org/cmake/help/latest/module/FetchContent.html) for consuming the TypeART runtime library.\n\n```cmake\nFetchContent_Declare(\n  typeart\n  GIT_REPOSITORY https://github.com/tudasc/TypeART\n  GIT_TAG v1.9.1\n  GIT_SHALLOW 1\n)\nFetchContent_MakeAvailable(typeart)\n\ntarget_link_libraries(my_project_target PRIVATE typeart::Runtime)\n```\n\n## References\n\n\u003ctable style=\"border:0px\"\u003e\n\u003ctr\u003e\n    \u003ctd valign=\"top\"\u003e\u003ca name=\"ref-typeart-2018\"\u003e\u003c/a\u003e[TA18]\u003c/td\u003e\n    \u003ctd\u003eHück, Alexander and Lehr, Jan-Patrick and Kreutzer, Sebastian and Protze, Joachim and Terboven, Christian and Bischof, Christian and Müller, Matthias S.\n    \u003ca href=https://doi.org/10.1109/Correctness.2018.00011\u003e\n    Compiler-aided type tracking for correctness checking of MPI applications\u003c/a\u003e.\n    In \u003ci\u003e2nd International Workshop on Software Correctness for HPC Applications (Correctness)\u003c/i\u003e,\n    pages 51–58. IEEE, 2018.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n    \u003ctd valign=\"top\"\u003e\u003ca name=\"ref-typeart-2020\"\u003e\u003c/a\u003e[TA20]\u003c/td\u003e\n    \u003ctd\u003eHück, Alexander and Protze, Joachim and Lehr, Jan-Patrick and Terboven, Christian and Bischof, Christian and Müller, Matthias S.\n    \u003ca href=https://doi.org/10.1109/Correctness51934.2020.00010\u003e\n    Towards compiler-aided correctness checking of adjoint MPI applications\u003c/a\u003e.\n    In \u003ci\u003e4th International Workshop on Software Correctness for HPC Applications (Correctness)\u003c/i\u003e,\n    pages 40–48. IEEE/ACM, 2020.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n    \u003ctd valign=\"top\"\u003e\u003ca name=\"ref-typeart-2022\"\u003e\u003c/a\u003e[TA22]\u003c/td\u003e\n    \u003ctd\u003eHück, Alexander and Kreutzer, Sebastian and Protze, Joachim and Lehr, Jan-Patrick and Bischof, Christian and Terboven, Christian and Müller, Matthias S.\n    \u003ca href=https://doi.org/10.1109/MITP.2021.3093949\u003e\n    Compiler-Aided Type Correctness of Hybrid MPI-OpenMP Applications\u003c/a\u003e.\n    In \u003ci\u003eIT Professional\u003c/i\u003e, vol. 24, no. 2, pages 45–51. IEEE, 2022.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n    \u003ctd valign=\"top\"\u003e\u003ca name=\"ref-must-2013\"\u003e\u003c/a\u003e[MU13]\u003c/td\u003e\n    \u003ctd\u003eHilbrich, Tobias and Protze, Joachim and Schulz, Martin and de Supinski, Bronis R. and Müller, Matthias S.\n    \u003ca href=https://doi.org/10.3233/SPR-130368\u003e\n    MPI Runtime Error Detection with MUST: Advances in Deadlock Detection\u003c/a\u003e.\n    In \u003ci\u003eScientific Programming\u003c/i\u003e, vol. 21, no. 3-4,\n    pages 109–121, 2013.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftudasc%2Ftypeart","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftudasc%2Ftypeart","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftudasc%2Ftypeart/lists"}