[llvm-branch-commits] [libc] [libc] Modular printf option (float only) (PR #147426)

@@ -0,0 +1,41 @@ +#ifdef LIBC_COPT_PRINTF_MODULAR +#include "src/__support/arg_list.h" + +#define LIBC_PRINTF_DEFINE_MODULAR +#include "src/stdio/printf_core/float_dec_converter.h" +#include "src/stdio/printf_core/float_hex_converter.h" +#include "src/stdio/printf_core/parser.h" +

[llvm-branch-commits] [libc] [libc] Modular printf option (float only) (PR #147426)

@@ -0,0 +1,41 @@ +#ifdef LIBC_COPT_PRINTF_MODULAR +#include "src/__support/arg_list.h" + +#define LIBC_PRINTF_DEFINE_MODULAR +#include "src/stdio/printf_core/float_dec_converter.h" +#include "src/stdio/printf_core/float_hex_converter.h" +#include "src/stdio/printf_core/parser.h" +

[llvm-branch-commits] [libc] [libc] Modular printf option (float only) (PR #147426)

@@ -0,0 +1,41 @@ +#ifdef LIBC_COPT_PRINTF_MODULAR +#include "src/__support/arg_list.h" + +#define LIBC_PRINTF_DEFINE_MODULAR +#include "src/stdio/printf_core/float_dec_converter.h" +#include "src/stdio/printf_core/float_hex_converter.h" +#include "src/stdio/printf_core/parser.h" +

[llvm-branch-commits] [llvm] [IR] "modular-format" attribute for functions using format strings (PR #147429)

@@ -2620,6 +2620,23 @@ For example: This attribute indicates that outlining passes should not modify the function. +``"modular_format"=""`` statham-arm wrote: Thanks. An afterthought: even printf and _scanf_ are different enough that they'd need

[llvm-branch-commits] [llvm] [IR] "modular-format" attribute for functions using format strings (PR #147429)

@@ -2620,6 +2620,23 @@ For example: This attribute indicates that outlining passes should not modify the function. +``"modular_format"=""`` statham-arm wrote: Is this intended to be specific to _printf_ style format strings? Or will it potentiall

[llvm-branch-commits] [compiler-rt] release/19.x: [compiler-rt] Stop using x86 builtin on AArch64 with GCC (#93890) (PR #115006)

statham-arm wrote: Despite the force-push, I think the current patch looks the same as the one I clicked approve on (maybe it was just rebased?). I can't see a problem – it's the same patch that hasn't been causing trouble on `main`. https://github.com/llvm/llvm-project/pull/115006 ___

[llvm-branch-commits] [compiler-rt] release/19.x: [compiler-rt] Stop using x86 builtin on AArch64 with GCC (#93890) (PR #115006)

https://github.com/statham-arm approved this pull request. Sounds like a good idea to me! https://github.com/llvm/llvm-project/pull/115006 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/l

[llvm-branch-commits] [clang] [Multilib] Custom flags processing for library selection (PR #110659)

https://github.com/statham-arm approved this pull request. https://github.com/llvm/llvm-project/pull/110659 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Multilib] Custom flags processing for library selection (PR #110659)

@@ -95,9 +96,113 @@ MultilibSet &MultilibSet::FilterOut(FilterCallback F) { void MultilibSet::push_back(const Multilib &M) { Multilibs.push_back(M); } +static void WarnUnclaimedMultilibCustomFlags( +const Driver &D, const SmallVector &UnclaimedCustomFlagValues, +const

[llvm-branch-commits] [clang] [Multilib] Add -fmultilib-flag command-line option (PR #110658)

https://github.com/statham-arm approved this pull request. https://github.com/llvm/llvm-project/pull/110658 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [Multilib] Add -fmultilib-flag command-line option (PR #110658)

@@ -196,6 +196,16 @@ bool ToolChain::defaultToIEEELongDouble() const { return PPC_LINUX_DEFAULT_IEEELONGDOUBLE && getTriple().isOSLinux(); } +static void +processARMAArch64MultilibCustomFlags(Multilib::flags_list &List, statham-arm wrote: Is this system int

[llvm-branch-commits] [clang] [Multilib] Custom flags processing for library selection (PR #110659)

@@ -14,6 +14,12 @@ def err_drv_no_such_file_with_suggestion : Error< def err_drv_unsupported_opt : Error<"unsupported option '%0'">; def err_drv_unsupported_opt_with_suggestion : Error< "unsupported option '%0'; did you mean '%1'?">; +def warn_drv_unsupported_opt : Warning< +

[llvm-branch-commits] [clang] [Multilib] Custom flags processing for library selection (PR #110659)

@@ -95,9 +96,113 @@ MultilibSet &MultilibSet::FilterOut(FilterCallback F) { void MultilibSet::push_back(const Multilib &M) { Multilibs.push_back(M); } +static void WarnUnclaimedMultilibCustomFlags( +const Driver &D, const SmallVector &UnclaimedCustomFlagValues, +const

[llvm-branch-commits] [llvm] release/19.x: [AArch64] Don't replace dst of SWP instructions with (X|W)ZR (#102139) (PR #102316)

https://github.com/statham-arm edited https://github.com/llvm/llvm-project/pull/102316 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/19.x: [AArch64] Don't replace dst of SWP instructions with (X|W)ZR (#102139) (PR #102316)

https://github.com/statham-arm approved this pull request. Seems sensible to me. It's fixing a genuine codegen fault (a subtle one, but of course that makes it worse – harder to spot when it occurs!). And it's a small safe change that disables one very small case of a conceptually simple optim