Two extra layers of subdirectory for a handful of single-symbol
Python source files did not improve anything, and it complicated
integration of the hdrgen Python outside the LLVM CMake build.
Summary:
This was originally a hacked together function that served to just
implement some features for OpenMP. That has been moved into OpenMP
itself now that we have exported RPC properly. This can now be deleted.
Make sure to clear out all FE_ALL_EXCEPT bits both before and after
invoking function under test -- otherwise the very first check for the
exception bits in the unit test may fail due to bits set prior to test
invocation.
Consistent with glibc headers, where `noexcept` is used in C++
(or `throw()` in older C++ which llvm-libc doesn't support) in
the public function declarations, `__attribute__((__nothrow__))` is
used in C for compilers that support it.
commit a9aff440d9dd ("[libc][docs] reorganize documentation (#118836)")
moved https://libc.llvm.org/math/index.html to
https://libc.llvm.org/headers/math/index.html which makes links from
various slide decks stale.
There's an extension for sphinx that can generate redirects. Add a dependency
on that, then use it to create a redirect so that those older links still work.
I was able to install this sphinx extension via:
$ sudo apt install python3-sphinx-reredirects
We may need to install this on whatever server generates the llvm
documentation.
Summary:
This installs the shared header to the users installation. I couldn't
decide if this should be a standalone thing or use the existing support
in `include/` mostly because this is completely separate from hdrgen
stuff and it's C++.
Creates a new toctree "Support" under which we have distinct links to arch,
platform, and compiler support.
* Moved "Platform Support" from index landing page to new doc.
* Created explicit "Architecture Support". Requested in https://github.com/llvm/llvm-project/issues/118964#issuecomment-2531503046.
* Moved "Compiler Support" from Status toctree to new Support toctree.
---------
Co-authored-by: Carlo Cabrera <github@carlo.cab>
FreeListHeap uses the _end symbol which conflicts with the _end symbol
defined by GPU start.cpp files so for now we exclude the test and the
fuzzer on GPU.
- Replace section on ABI Compatibility with a rephrased warning at the
top of
the page.
- Add links to the Note.
- Update C and POSIX standards.
- Inline link to fuzzing.
Summary:
In order for this to work with CUDA we need to declare functions as
__host__ and __device__ while also making sure we only call the GPU
functions during the CUDA / HIP compile stage.
Summary:
This is installed unconditionally because of the dependency in the
`hdr/` directory. Remove this so it's only used on the systems that need
it.
Usually posix functions have individual doc pages, and each header has its own
list of required macro definitions. Use a simpler key of "in-latest-posix" to
signal that the URL convention can be followed.
Add support for a "removed-in-posix-2008" key which will link to the 2004 docs
for functions like bcmp, bcopy, bzero, index, and rindex from strings.h.
I don't want to add all of these links for pthreads.h, so automating this will
make documenting these go much faster.
Building with the source directory rooted in the libc subdirectory isn't
tested in CI and can lead to subtle build problems (cf. #118871).
Let's fail fast with a helpful error message instead to help users
configure libc correctly.
Co-authored-by: Nick Desaulniers <nickdesaulniers@users.noreply.github.com>
bcmp, bcopy, and bzero should be moved from libc/src/string/ to
lib/src/strings/ in order for docgen to use existing conventions to find
whether we implement a function or not.
We should add support to docgen for mentioning glibc extensions (mempcpy) or
extensions from other libcs.
so that docgen can find our definitions.
Also eliminate the enums. POSIX is careful to call these "symbolic constants"
rather than specifically whether they are preprocessor macro defines or not.
Enums are useful to expressing mutual exclusion when the enum values are in
distinct enums which can improve type safety. Our enum values weren't using
that pattern though; they were all in one big anonymous enum.
Link:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/pthread.h.htmlFixes: #88997
