Commit Graph

10 Commits

Author SHA1 Message Date
jasonliu a319eafd16 [libc++] Provide c++03 alternative for va_copy if available in xlocale.h
Summary:
If we are on c++03 mode for some reason, and __builtin_va_copy is
available, then use it instead of error out on not having va_copy
in 03 mode.

Reviewed by: ldionne

Differential Revision: https://reviews.llvm.org/D100336
2021-07-01 18:02:38 +00:00
zoecarver 8110a73164 [libcxx][gardening] Re-order includes across libcxx.
This commit alphabetizes all includes in libcxx. This is a NFC.

This can also serve as a pseudo "announcement" for how we should order these headers going forward (note: double underscores go before other headers).

Differential Revision: https://reviews.llvm.org/D102941
2021-05-21 13:22:10 -07:00
Zbigniew Sarbinowski 916093f49f [SystemZ][z/OS] correct rc and errno within nanosleep()
This patch fixes rc and errno within nanosleep(). It also updates __rem parameter as well it introduces cast to handle conversions from long into unsigned int to avoid warnings.

Reviewed By: Mordante

Differential Revision: https://reviews.llvm.org/D99373
2021-04-06 15:36:58 +00:00
jasonliu 158026301b [libc++][AIX] Initial patch to unblock the libc++ build on AIX
This path would unblock the build of libc++ library on AIX:
1. Add _AIX guard for _LIBCPP_HAS_THREAD_API_PTHREAD
2. Use uselocale to actually take the locale setting
   into account.
3. extract_mtime and extract_atime mod needed for AIX. As stat
   structure on AIX uses internal structure st_timespec to store
   time for binary compatibility reason. So we need to convert it
   back to timespec here.
4. Do not build cxa_thread_atexit.cpp for libcxxabi on AIX.

Differential Revision: https://reviews.llvm.org/D97558
2021-03-24 22:13:20 +00:00
Martin Storsjö 675401e04c [libcxx] Avoid pulling in xlocinfo.h in public headers
Including xlocinfo.h is a bit of a layering violation; locale.h is
the C library header we should use, while xlocinfo.h is essentially
part of the MS C++ library. Including xlocinfo.h brings in yvals.h,
which brings in yvals_core.h, which defines the MS STL's version
support macros, overriding what libc++'s <version> had defined.

Instead just include locale.h, and provide the few defines we need
for locale categories manually.

Differential Revision: https://reviews.llvm.org/D99213
2021-03-24 23:29:59 +02:00
Muiez Ahmed f6af5efcec [SystemZ][z/OS] vasprintf fix libc++
The aim is to use the correct vasprintf implementation for z/OS libc++, where a copy of va_list ap is needed. In particular, it avoids the potential that the initial internal call to vsnprintf will modify ap and the subsequent call to vsnprintf will use that modified ap.

Differential Revision: https://reviews.llvm.org/D97473
2021-03-18 15:00:57 -04:00
Muiez Ahmed ebe6161c54 [SystemZ][z/OS] Missing locale functions libc++
The aim is to add the missing z/OS specific locale functions for libc++ (newlocale, freelocale and uselocale).

Reviewed By: ldionne, #libc, curdeius

Differential Revision: https://reviews.llvm.org/D98044
2021-03-08 19:32:33 +00:00
Muiez Ahmed 53c8587dcd [SystemZ][z/OS] Missing non-posix functions libc++
The aim is to add missing non-posix functions for z/OS libc++ (strtod_l and strtof_l).

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D97051
2021-03-04 15:23:21 +00:00
Zbigniew Sarbinowski cb2d2ae56a [SystemZ][ZOS] Provide CLOCK_MONOTONIC alternative
We need CLOCK_MONOTONIC equivalent implementation for z/OS within libc++. The default implementation is asserting.

On z/OS the lack of  'clock_gettime()' and 'time_point()' force us to look for alternatives.
The current proposal is to use `gettimeofday()` for CLOCK_MONOTONIC  which is also used in CLOCK_REALTIME.  This will allow us to skip the assertion with compromised CLOCK_MONOTONIC implementation which will not guarantee to never go back in time because it will use `gettimeofday()` but only when it's set.

Is this a good compromise for platforms which does not support monotonic clock?
Hopefully this will spark the discussion and agreement how to proceed in this situation.

Reviewed By: #libc, ldionne, hubert.reinterpretcast

Differential Revision: https://reviews.llvm.org/D93542
2021-02-12 18:39:48 +00:00
Louis Dionne b51756819a [libc++] Rename include/support to include/__support
We do ship those headers, so the directory name should not be something
that can potentially conflict with user-defined directories.

Differential Revision: https://reviews.llvm.org/D95956
2021-02-04 10:16:33 -05:00