[libcxx-commits] [PATCH] D108630: [libc++] Remove _LIBCPP_HAS_NO_LONG_LONG in favour of using_if_exists
Louis Dionne via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Aug 24 09:06:30 PDT 2021
ldionne added inline comments.
================
Comment at: libcxx/include/stdlib.h:153
}
-#ifndef _LIBCPP_HAS_NO_LONG_LONG
+#if !(defined(__FreeBSD__) && !defined(__LONG_LONG_SUPPORTED))
inline _LIBCPP_INLINE_VISIBILITY lldiv_t div(long long __x,
----------------
dim wrote:
> ldionne wrote:
> > @emaste @dim
> >
> > What does `!defined(__LONG_LONG_SUPPORTED)` mean exactly? It doesn't mean that the `long long` type isn't provided by the compiler, because there are several other uses of `long long` in the library that are not guarded by that check. Is it only about the C Standard Library on FreeBSD not providing `::lldiv`? What about `__builtin_llabs()` -- I would that if `long long` is a valid type, the compiler does implement `__builtin_llabs` as used above and we don't need to guard the above use of it?
> > @emaste @dim
> >
> > What does `!defined(__LONG_LONG_SUPPORTED)` mean exactly? It doesn't mean that the `long long` type isn't provided by the compiler, because there are several other uses of `long long` in the library that are not guarded by that check. Is it only about the C Standard Library on FreeBSD not providing `::lldiv`? What about `__builtin_llabs()` -- I would that if `long long` is a valid type, the compiler does implement `__builtin_llabs` as used above and we don't need to guard the above use of it?
>
> It's a historic thing in our https://github.com/freebsd/freebsd-src/blob/main/include/stdlib.h#L126 and various other standard headers:
>
> ```
> /*
> * Functions added in C99 which we make conditionally available in the
> * BSD^C89 namespace if the compiler supports `long long'.
> * The #if test is more complicated than it ought to be because
> * __BSD_VISIBLE implies __ISO_C_VISIBLE == 1999 *even if* `long long'
> * is not supported in the compilation environment (which therefore means
> * that it can't really be ISO C99).
> *
> * (The only other extension made by C99 in thie header is _Exit().)
> */
> ```
>
> The definition of `__LONG_LONG_SUPPORTED` comes from https://github.com/freebsd/freebsd-src/blob/main/sys/sys/cdefs.h#L391 :
>
> ```
> #if (defined(__GNUC__) && __GNUC__ >= 2) && !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901
> #define __LONG_LONG_SUPPORTED
> #endif
>
> /* C++11 exposes a load of C99 stuff */
> #if defined(__cplusplus) && __cplusplus >= 201103L
> #define __LONG_LONG_SUPPORTED
> #ifndef __STDC_LIMIT_MACROS
> #define __STDC_LIMIT_MACROS
> #endif
> #ifndef __STDC_CONSTANT_MACROS
> #define __STDC_CONSTANT_MACROS
> #endif
> #endif
> ```
>
> Ergo, C++ standards before C++11 have `__LONG_LONG_SUPPORTED` undefined. Unfortunately there are still quite a few programs requiring `-std=c++98` (or more usually `-std=gnu++98`)...
>
Okay, thanks a lot for the background. In that case, I think we can even remove the guard from around the use of `__builtin_llabs` and this patch should be non-breaking.
Would it be possible to add build bots for FreeBSD so we can test changes like those automatically?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D108630/new/
https://reviews.llvm.org/D108630
More information about the libcxx-commits
mailing list