summaryrefslogtreecommitdiff
path: root/openmp/runtime/src/kmp_str.cpp
AgeCommit message (Collapse)Author
2025-07-21[OpenMP] Fixup bugs found during fuzz testing (#143455)Jonathan Peyton
A lot of these only trip when using sanitizers with the library. * Insert forgotten free()s * Change (-1) << amount to 0xffffffffu as left shifting a negative is UB * Fixup integer parser to return INT_MAX when parsing huge string of digits. e.g., 452523423423423423 returns INT_MAX * Fixup range parsing for affinity mask so integer overflow does not occur * Don't assert when branch bits are 0, instead warn user that is invalid and use the default value. * Fixup kmp_set_defaults() so the C version only uses null terminated strings and the Fortran version uses the string + size version. * Make sure the KMP_ALIGN_ALLOC is power of two, otherwise use CACHE_LINE. * Disallow ability to set KMP_TASKING=1 (task barrier) this doesn't work and hasn't worked for a long time. * Limit KMP_HOT_TEAMS_MAX_LEVEL to 1024, an array is allocated based on this value. * Remove integer values for OMP_PROC_BIND. The specification only allows strings and CSV of strings. * Fix setting KMP_AFFINITY=disabled + OMP_DISPLAY_AFFINITY=TRUE
2023-08-18[OpenMP] Add option to use different units for blocktimeTerry Wilmarth
This change adds the option of using different units for blocktimes specified via the KMP_BLOCKTIME environment variable. The parsing of the environment now recognizes units suffixes: ms and us. If a units suffix is not specified, the default unit is ms. Thus default behavior is still the same, and any previous usage still works the same. Internally, blocktime is now converted to microseconds everywhere, so settings that exceed INT_MAX in microseconds are considered "infinite". kmp_set/get_blocktime are updated to use the units the user specified with KMP_BLOCKTIME, and if not specified, ms are used. Added better range checking and inform messages for the two time units. Large values of blocktime for default (ms) case (beyond INT_MAX/1000) are no longer allowed, but will autocorrect with an INFORM message. The delay for determining ticks per usec was lowered. It is now 1 million ticks which was calculated as ~450us based on 2.2GHz clock which is pretty typical base clock frequency on X86: (1e6 Ticks) / (2.2e9 Ticks/sec) * (1e6 usec/sec) = 454 usec Really short benchmarks can be affected by longer delay. Update KMP_BLOCKTIME docs. Portions of this commit were authored by Johnny Peyton. Differential Revision: https://reviews.llvm.org/D157646
2023-02-07[OpenMP][libomp] Remove false positive for memory sanitizerJonathan Peyton
The memory sanitizer intercepts the memcpy() call but not the direct assignment of last byte to 0. This leads the sanitizer to believe the last byte of a string based on the kmp_str_buf_t type is uninitialized. Hence, the eventual strlen() inside __kmp_env_dump() leads to an use-of-uninitialized-value warning. Using strncat() instead gives the sanitizer the information it needs. Differential Revision: https://reviews.llvm.org/D143401 Fixes #60501
2023-02-06Revert "[OpenMP][libomp] Remove false positive for memory sanitizer"Ron Lieberman
breaks amdgpu buildbot This reverts commit 402981ee25fe135d63226a7de17dbb14c437c71b.
2023-02-06[OpenMP][libomp] Remove false positive for memory sanitizerJonathan Peyton
The memory sanitizer intercepts the memcpy() call but not the direct assignment of last byte to 0. This leads the sanitizer to believe the last byte of a string based on the kmp_str_buf_t type is uninitialized. Hence, the eventual strlen() inside __kmp_env_dump() leads to an use-of-uninitialized-value warning. Using strncat() instead gives the sanitizer the information it needs. Differential Revision: https://reviews.llvm.org/D143401 Fixes #60501
2021-07-29[OpenMP] libomp: Add new experimental barrier: two-level distributed barrierTerry Wilmarth
Two-level distributed barrier is a new experimental barrier designed for Intel hardware that has better performance in some cases than the default hyper barrier. This barrier is designed to handle fine granularity parallelism where barriers are used frequently with little compute and memory access between barriers. There is no need to use it for codes with few barriers and large granularity compute, or memory intensive applications, as little difference will be seen between this barrier and the default hyper barrier. This barrier is designed to work optimally with a fixed number of threads, and has a significant setup time, so should NOT be used in situations where the number of threads in a team is varied frequently. The two-level distributed barrier is off by default -- hyper barrier is used by default. To use this barrier, you must set all barrier patterns to use this type, because it will not work with other barrier patterns. Thus, to turn it on, the following settings are required: KMP_FORKJOIN_BARRIER_PATTERN=dist,dist KMP_PLAIN_BARRIER_PATTERN=dist,dist KMP_REDUCTION_BARRIER_PATTERN=dist,dist Branching factors (set with KMP_FORKJOIN_BARRIER, KMP_PLAIN_BARRIER, and KMP_REDUCTION_BARRIER) are ignored by the two-level distributed barrier. Patch fixed for ITTNotify disabled builds and non-x86 builds Co-authored-by: Jonathan Peyton <jonathan.l.peyton@intel.com> Co-authored-by: Vladislav Vinogradov <vlad.vinogradov@intel.com> Differential Revision: https://reviews.llvm.org/D103121
2021-06-29Revert "[OpenMP] Add Two-level Distributed Barrier"Johannes Doerfert
This reverts commit 25073a4ecfc9b2e3cb76776185e63bfdb094cd98. This breaks non-x86 OpenMP builds for a while now. Until a solution is ready to be upstreamed we revert the feature and unblock those builds. See: https://reviews.llvm.org/rG25073a4ecfc9b2e3cb76776185e63bfdb094cd98#1005821 and https://reviews.llvm.org/rG25073a4ecfc9b2e3cb76776185e63bfdb094cd98#1005821 The currently proposed fix (D104788) seems not to be ready yet: https://reviews.llvm.org/D104788#2841928
2021-06-16[OpenMP] Add Two-level Distributed BarrierTerry Wilmarth
Two-level distributed barrier is a new experimental barrier designed for Intel hardware that has better performance in some cases than the default hyper barrier. This barrier is designed to handle fine granularity parallelism where barriers are used frequently with little compute and memory access between barriers. There is no need to use it for codes with few barriers and large granularity compute, or memory intensive applications, as little difference will be seen between this barrier and the default hyper barrier. This barrier is designed to work optimally with a fixed number of threads, and has a significant setup time, so should NOT be used in situations where the number of threads in a team is varied frequently. The two-level distributed barrier is off by default -- hyper barrier is used by default. To use this barrier, you must set all barrier patterns to use this type, because it will not work with other barrier patterns. Thus, to turn it on, the following settings are required: KMP_FORKJOIN_BARRIER_PATTERN=dist,dist KMP_PLAIN_BARRIER_PATTERN=dist,dist KMP_REDUCTION_BARRIER_PATTERN=dist,dist Branching factors (set with KMP_FORKJOIN_BARRIER, KMP_PLAIN_BARRIER, and KMP_REDUCTION_BARRIER) are ignored by the two-level distributed barrier. Differential Revision: https://reviews.llvm.org/D103121
2021-02-20[OpenMP][NFC] clang-format the whole openmp projectShilei Tian
Same script as D95318. Test files are excluded. Reviewed By: AndreyChurbanov Differential Revision: https://reviews.llvm.org/D97088
2020-12-31[OpenMP] libomp: Handle implicit conversion warningsTerry Wilmarth
This patch partially prepares the runtime source code to be built with -Wconversion, which should trigger warnings if any implicit conversions can possibly change a value. For builds done with icc or gcc, all such warnings are handled in this patch. clang gives a much longer list of warnings, particularly for sign conversions, which the other compilers don't report. The -Wconversion flag is commented into cmake files, but I'm not going to turn it on. If someone thinks it is important, and wants to fix all the clang warnings, they are welcome to. Types of changes made here involve either improving the consistency of types used so that no conversion is needed, or else performing careful explicit conversions, when we're sure a problem won't arise. Patch is a combination of changes by Terry Wilmarth and Johnny Peyton. Differential Revision: https://reviews.llvm.org/D92942
2020-12-07[OpenMP] NFC: comment adjustedAndreyChurbanov
2020-12-07[OpenMP] libomp: Fix possible NULL dereferencesAndreyChurbanov
Check pointer returned by strchr, as it can be NULL in case of broken format of input string. Introduced new function __kmp_str_loc_numbers for fast parsing of numbers only in the location string. Also made some cleanup of __kmp_str_loc_init declaration and usage: - changed type of init_fname parameter to bool; - changed input from true to false in places where fname is not used. Differential Revision: https://reviews.llvm.org/D90962
2020-01-03[OpenMP] NFC: Fix trivial typos in commentsKelvin Li
Submitted by: kiszk Differential Revision: https://reviews.llvm.org/D72171
2019-01-19Update more file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
2018-12-13[OpenMP] Implement OpenMP 5.0 affinity format functionalityJonathan Peyton
This patch adds the affinity format functionality introduced in OpenMP 5.0. This patch adds: Two new environment variables: OMP_DISPLAY_AFFINITY=TRUE|FALSE OMP_AFFINITY_FORMAT=<string> and Four new API: 1) omp_set_affinity_format() 2) omp_get_affinity_format() 3) omp_display_affinity() 4) omp_capture_affinity() The affinity format functionality has two ICV's associated with it: affinity-display-var (bool) and affinity-format-var (string). The affinity-display-var enables/disables the functionality through the envirable OMP_DISPLAY_AFFINITY. The affinity-format-var is a formatted string with the special field types beginning with a '%' character similar to printf For example, the affinity-format-var could be: "OMP: host:%H pid:%P OStid:%i num_threads:%N thread_num:%n affinity:{%A}" The affinity-format-var is displayed by every thread implicitly at the beginning of a parallel region when any thread's affinity has changed (including a brand new thread being spawned), or explicitly using the omp_display_affinity() API. The omp_capture_affinity() function can capture the affinity-format-var in a char buffer. And omp_set|get_affinity_format() allow the user to set|get the affinity-format-var explicitly at runtime. omp_capture_affinity() and omp_get_affinity_format() both return the number of characters needed to hold the entire string it tried to make (not including NULL character). If not enough buffer space is available, both these functions truncate their output. Differential Revision: https://reviews.llvm.org/D55148 llvm-svn: 349089
2018-09-26[OpenMP][OMPT] A few improvementsJonathan Peyton
This change includes miscellaneous improvements as follows: 1) Added ompt_get_proc_id() implementation for Windows 2) Added parser and print tool for omp-tool-var, just in case it needs to be printed (OMP_DISPLAY_ENV) 3) omp_control_tool is exported on Windows Patch by Hansang Bae Differential Revision: https://reviews.llvm.org/D50538 llvm-svn: 343137
2017-11-09Remove const from variables with dynamic memoryJonas Hahnfeld
Allocated memory is typically not 'const' if it needs to be freed. This patch removes around 50 wrong const attributes, modifies the corresponding functions and finally gets rid of some const_casts. These have especially been strange for __kmp_str_fname_free() that added a 'const' to call __kmp_str_free() which removed it again. Two minor cleanups that I performed in this process: * __kmp_tool_libraries now lives in kmp_settings.cpp as it is used nowhere else. * __kmp_msg_empty was removed as it was never used and Clang now complained that it was assigned a string literal that is 'const char *'. Differential Revision: https://reviews.llvm.org/D39755 llvm-svn: 317797
2017-10-20Apply formatting changesJonathan Peyton
.clang-format's comments are removed and a (hopefully) final set of formatting changes are applied. Differential Revision: https://reviews.llvm.org/D38837 Differential Revision: https://reviews.llvm.org/D38920 llvm-svn: 316227
2017-09-27Remove unnecessary semicolonsJonathan Peyton
Removes semicolons after if {} blocks, function definitions, etc. I was able to apply the large OMPT patch cleanly on top of this one with no conflicts. llvm-svn: 314340
2017-08-19Use va_copy instead of __va_copy to fix building libomp against musl libcJonathan Peyton
Fixes https://bugs.llvm.org/show_bug.cgi?id=34040 Patch by Peter Levine Differential Revision: https://reviews.llvm.org/D36343 llvm-svn: 311269
2017-07-03OpenMP RTL cleanup: eliminated warnings with -Wcast-qual.Andrey Churbanov
Changes are: replaced C-style casts with cons_cast and reinterpret_cast; type of several counters changed to signed; type of parameters of 32-bit and 64-bit AND and OR intrinsics changes to unsigned; changed files formatted using clang-format version 3.8.1. Differential Revision: https://reviews.llvm.org/D34759 llvm-svn: 307020
2017-05-12Clang-format and whitespace cleanup of source codeJonathan Peyton
This patch contains the clang-format and cleanup of the entire code base. Some of clang-formats changes made the code look worse in places. A best effort was made to resolve the bulk of these problems, but many remain. Most of the problems were mangling line-breaks and tabbing of comments. Patch by Terry Wilmarth Differential Revision: https://reviews.llvm.org/D32659 llvm-svn: 302929
2016-12-14Follow up to r289732: Update comments in source files to reference .cpp filesJonathan Peyton
Patch by Hansang Bae llvm-svn: 289739
2016-12-14Change source files from .c to .cppJonathan Peyton
Patch by Hansang Bae Differential Revision: https://reviews.llvm.org/D26688 llvm-svn: 289732