@@ -223,6 +223,13 @@ endif()
# This can be used to detect whether we're in the runtimes build.
set(LLVM_RUNTIMES_BUILD ON)
+if (LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND UNIX AND ${CMAKE_SYSTEM_NAME}
MATCHES "AIX")
+ # Set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF as AIX doesn't s
@@ -1187,16 +1187,19 @@ endif()
# Build with _XOPEN_SOURCE on AIX, as stray macros in _ALL_SOURCE mode tend to
# break things. In this case we need to enable the large-file API as well.
if (UNIX AND ${CMAKE_SYSTEM_NAME} MATCHES "AIX")
- add_compile_definitions(_XOPEN_S
https://github.com/arichardson approved this pull request.
https://github.com/llvm/llvm-project/pull/131200
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
arichardson wrote:
> @arichardson I found the way to override the cache file. Thanks for the
> suggestion!
Thanks this looks good to me.
https://github.com/llvm/llvm-project/pull/131200
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https:
arichardson wrote:
> > Wouldn't it be more maintainable to just force the value to OFF for AIX
> > where the `option()` is defined?
>
> Unfortunately, the cmake command line option `-D
> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON` overrides the `option()` in the cmake
> file.
Sorry if this was no
https://github.com/arichardson edited
https://github.com/llvm/llvm-project/pull/131200
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/arichardson requested changes to this pull request.
Wouldn't it be more maintainable to just set the value to off for AIX where the
`option()` is defined?
https://github.com/llvm/llvm-project/pull/131200
___
lldb-commits mailing lis
arichardson wrote:
Sanitizer build has been fixed but I know this will also break the Fuchsia
build bots if we reland it (see
https://github.com/llvm/llvm-project/pull/115379#issuecomment-2469268557) - not
sure if there is any plan to update those builders to use installed toolchains
for the
arichardson wrote:
> > > https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh
> >
> >
> > It looks like
> > https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh
>
arichardson wrote:
> https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh
It looks like
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh
tries to run `ninja c
arichardson wrote:
> IIUC, the build that encountered issues in this patch ([in the comment
> above](https://github.com/llvm/llvm-project/pull/115380#issuecomment-2590801533))
> is a flavour of (2), right? That seems surprising to me though since we also
> use the same flags when configuring l
arichardson wrote:
I realize there are some issues with this and while it's a nice cleanup, I
don't have the time right now to deal with the potential fallout (build
directory can't be used as a cross-compiler out of the box).
https://github.com/llvm/llvm-project/pull/115380
__
https://github.com/arichardson closed
https://github.com/llvm/llvm-project/pull/106500
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
arichardson wrote:
This will cause huge merge conflicts for all downstreams. While they are easy
to resolve it can be quite annoying. I think we should just do this as part of
the global clang-format.
https://github.com/llvm/llvm-project/pull/82838
_
@@ -374,10 +376,10 @@ static __inline fp_t __compiler_rt_fmax(fp_t x, fp_t y) {
#endif
}
-#elif defined(QUAD_PRECISION) && defined(CRT_HAS_TF_MODE)
+#elif defined(QUAD_PRECISION)
arichardson wrote:
Looks like this was actually required. Probably needs to be c
https://github.com/arichardson closed
https://github.com/llvm/llvm-project/pull/77554
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/arichardson approved this pull request.
Thanks this looks good to me now and should not change anything for other
targets.
https://github.com/llvm/llvm-project/pull/77554
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
htt
@@ -13,8 +13,6 @@
#define QUAD_PRECISION
#include "fp_lib.h"
-#if defined(CRT_HAS_TF_MODE)
arichardson wrote:
I'd suggest replacing this with CRT_HAS_F128 as noted below (unless you're will
to audit all current uses of CRT_HAS_TF_MODE since that currently is
@@ -15,8 +15,6 @@
#include "int_lib.h"
#include "int_math.h"
-#if defined(CRT_HAS_TF_MODE)
arichardson wrote:
I'm not sure if we support architectures without a "tf" floating point type. To
be safe I believe we still need a guard here since this file is comp
@@ -189,11 +189,15 @@ typedef long double tf_float;
#define CRT_LDBL_IEEE_F128
#endif
#define TF_C(x) x##L
-#elif __LDBL_MANT_DIG__ == 113
-// Use long double instead of __float128 if it matches the IEEE 128-bit format.
+#elif __LDBL_MANT_DIG__ == 113 ||
@@ -374,10 +376,10 @@ static __inline fp_t __compiler_rt_fmax(fp_t x, fp_t y) {
#endif
}
-#elif defined(QUAD_PRECISION) && defined(CRT_HAS_TF_MODE)
+#elif defined(QUAD_PRECISION)
// The generic implementation only works for ieee754 floating point. For other
// floating point
21 matches
Mail list logo
