jyknight wrote:
Heads up: this commit has triggered some weird errors for a compile, but only
when clang header modules are enabled. A std::vector, that's built through a
large amount of template gunk that definitely involves template template
parameter matching, ends up failing vector's
jyknight wrote:
Please update the constraint code list
https://llvm.org/docs/LangRef.html#supported-constraint-code-list with any new
codes.
https://github.com/llvm/llvm-project/pull/92338
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jyknight wrote:
https://discourse.llvm.org/t/rfc-building-llvm-for-webassembly/79073 and PR
#92677 also just arrived at the scene with a different take on implementing the
same thing. Looks like there's significant interest in this area!
https://github.com/llvm/llvm-project/pull/91051
jyknight wrote:
We _don't_ diagnose it at the end of the definition of M -- it looks like we
explicitly intentionally stopped doing so in the commit I referenced. That's
why I'm a little confused here.
With this patch, we start to diagnose only in the final line of code, `void
test(M m =
jyknight wrote:
Here's a test case that clang diagnoses with `-Wundefined-inline` after this
patch, which I'm not sure whether is correct or not. It might violate
https://eel.is/c++draft/temp.inst#11 to attempt to instantiate the unused
`S::operator int`?
I'm having a hard time telling
jyknight wrote:
I note that this commit (probably unintentionally) fixed an issue with the
`-Wnonnull` warning for return values in Objective-C++ code.
Previously, `id _Nonnull foo() { return nullptr; }` does not warn under `clang
-fobjc-arc -target x86_64-apple-macos11 -x objective-c++
@@ -842,25 +842,6 @@ void Linux::addProfileRTLibs(const llvm::opt::ArgList
,
ToolChain::addProfileRTLibs(Args, CmdArgs);
}
-llvm::DenormalMode
-Linux::getDefaultDenormalModeForType(const llvm::opt::ArgList ,
- const JobAction ,
-
https://github.com/jyknight approved this pull request.
One final nit before you submit, though: please update the PR description and
the release notes to also mention that x86 no longer modifies
`-fdenormal-fp-math` based on `-ffast-math`.
https://github.com/llvm/llvm-project/pull/80475
@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those
languages.
C++ Language Changes
+C++17 Feature Support
+^
+- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE``
+ predefined macros
@@ -1792,6 +1792,11 @@ class TargetInfo : public TransferrableTargetInfo,
/// Whether to support HIP image/texture API's.
virtual bool hasHIPImageSupport() const { return true; }
+ /// The minimum offset between two objects to avoid false sharing.
+ virtual unsigned
@@ -1792,6 +1792,11 @@ class TargetInfo : public TransferrableTargetInfo,
/// Whether to support HIP image/texture API's.
virtual bool hasHIPImageSupport() const { return true; }
+ /// The minimum offset between two objects to avoid false sharing.
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/89446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight commented:
I think having the on-by-default diagnostic before we release this
functionality is critically important -- but the primarily-useful part of that
is going to be for the public libc++ APIs which expose these values (and, that
already landed in mainline).
@@ -89,6 +89,19 @@ sections with improvements to Clang's support for those
languages.
C++ Language Changes
+C++17 Feature Support
+^
+- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE``
+ predefined macros
jyknight wrote:
To get back to my previous point about the semantics implemented by this patch
being unfortunate -- the upshot is that, now:
```
#include
#define NDEBUG
#import
```
will include assert.h twice (even though the latter is an "import") _only_ if
modules are enabled. If modules
jyknight wrote:
>> The end result should be that #imported and #pragma once-guarded files are
>> treated the same way as #ifndef-guarded files.
> While I don't necessarily disagree with that goal in principle, it wasn't
> true before this change either.
Well, yes, I know it isn't true yet --
jyknight wrote:
> The problem I'm trying to fix is that nobody knows when it's appropriate to
> use #import vs #include
But you haven't really (and I think cannot) fixed that.
> using header guards or #pragma once is very "un-Objective-C".
Yes, this is quite unfortunate. The best answer
jyknight wrote:
Oh -- I'd also note that even if this is reverted, ilya-biryukov may want to
continue to investigate the source-location issue -- it's entirely possible
that the correct fix will trigger that same problem!
https://github.com/llvm/llvm-project/pull/83660
jyknight wrote:
I think the bug this change was attempting to fix is actually the same as
#38554 and related bugs -- which, it appears, was not really fixed.
The underlying problem here is that `#pragma once` should should work
identically to ifndef guards, as far as what macros/decls are
@@ -770,6 +770,18 @@ bool TargetInfo::validateOutputConstraint(ConstraintInfo
) const {
case 'E':
case 'F':
break; // Pass them.
+case '{': {
jyknight wrote:
It's unclear to me whether this uses the same register parsing logic as the
@@ -1760,6 +1760,50 @@ references can be used instead of numeric references.
return -1;
}
+Hard Register Operands for ASM Constraints
+==
+
+Clang supports the ability to specify specific hardware registers in inline
+assembly
jyknight wrote:
Thanks for reviving the change!
I'm definitely in favor of this, but since it adds no new functionality (only
better usability), the value proposition is significantly lessened (IMO, to the
point where it may not be be worthwhile to do) if it gets implemented ONLY in
clang.
jyknight wrote:
+1 on the high-level plan. Switching from a linear offset to a
{local-module-index, offset-within-module} pair sounds great!
https://github.com/llvm/llvm-project/pull/86912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jyknight wrote:
Can reduce further to:
```
template
concept h = requires(T i) { [] {}(i); };
template struct k;
template struct k {
struct n;
};
using o = k::n;
```
But, is `requires(T i) { [] {}(i); };` actually valid? I think that _should_
fail the requirement, since you cannot call
jyknight wrote:
> Don't know but everything passed now!
Well, I'm not an expert on the objc codegen...but unless you, or someone else,
can explain that my concern is invalid, I think this change cannot be made.
https://github.com/llvm/llvm-project/pull/79191
jyknight wrote:
What config is this bot using? Is it "-target sparc-solaris -mcpu=v9" (that is:
32-bit sparc, but with v9 cpu available)?
I see that SparcV9TargetInfo sets MaxAtomicInlineWidth to 64 unconditionally.
But, the message `warning: large atomic operation may incur significant
jyknight wrote:
Is there a valid use for having "EHCleanup" that _doesn't_ handle branches
across it? That is, do we _ever_ need a cleanup to be called only for an
exception thrown, and not otherwise leaving the scope? I'm just wondering if we
can simplify things conceptually here and remove
https://github.com/jyknight approved this pull request.
Sorry for the delay. This looks good to me now!
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/81173
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
> I don't see why the current denormal-fp-math setting behavior is a blocking
> issue for this change
Because this PR as-is causes us to start parsing the "-shared" flag for
compilation actions in order to determine which denormal-fp-math setting to
use. Users should not pass
jyknight wrote:
I'm proposing a simple change we can make _now_, in order to unblock this PR
which at least gets rid of crtfastmath for shared libraries! I don't think this
needs to be the end of the story; additional, more large-scale changes can be
made afterwards...
> Are youe suggesting
jyknight wrote:
> > > > So, alternatively...we could just go with the simplest solution, and
> > > > use "ieee" as the default even under -ffast-math.
> >
> >
> > +1. **There hasn't been a performance reason to use FTZ/DAZ since ~2011.**
> > Maybe there's still a power benefit? But in that
jyknight wrote:
@RKSimon: I'm not sure if you intended your comment to be a blocker; I was
about to press the merge button when you commented (and would still wish to
now).
https://github.com/llvm/llvm-project/pull/74275
___
cfe-commits mailing list
jyknight wrote:
> So, alternatively...we could just go with the simplest solution, and use
> "ieee" as the default even under -ffast-math.
This is feeling like the best option to me, at this point. Easily
implementable, and doesn't seem to make things significantly worse than they
are today,
jyknight wrote:
> You'll get different results depending on whether the input is implicitly
> flushed in fcmp vs. not in the is.fpclass
This sounds intuitively like the sort of semantics-breaking optimization which
is expected from `-ffast-math`. If the only issues are things like getting a
jyknight wrote:
> It is not always safe to run preserve-sign code under IEEE settings
I can see that this is used in a bunch of optimization/constant-folding passes,
but I don't have a feel for what the actual impact is:
1. Which value allows generating the "fastest" math code -- disregarding
jyknight wrote:
I think there is a bit of a problematic interaction with getDenormalModeForType
[here](https://github.com/llvm/llvm-project/blob/7a94acb2da5b20d12f13f3c5f4eb0f3f46e78e73/clang/lib/Driver/ToolChains/Linux.cpp#L838C8-L838C37).
"-shared" is (should be) a flag used only for
jyknight wrote:
Underaligned atomic operations are expanded to an appropriate `__atomic_*`
libcall via mostly target-independent code in AtomicExpandPass
(https://github.com/llvm/llvm-project/blob/7ecfb66c77ad77dabbb705cbb1f3b17a3d1391a4/llvm/lib/CodeGen/AtomicExpandPass.cpp#L210)
and never
jyknight wrote:
Does this cause an ABI incompatibility? E.g. if we have a case where an
existing object calls copyStruct on a given object (which presumably has its
own internal mutex), and a newly compiled object file calls `__atomic_load` on
the same object, implemented with its own
jyknight wrote:
This is incorrect: X86 does not support unaligned atomics.
However, LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary). So the ObjC code's
`hasUnalignedAtomics` could be removed, and let the backend deal with
jyknight wrote:
BTW, please don't rebase/amend commits and force-push, it makes a it extremely
difficult to review the changes since the previous review -- especially if the
new changes are commingled with a rebase.
Much better to simply push new commits on top of your existing branch. And if
jyknight wrote:
Yes, that's an acceptable/correct solution in that circumstance. Given we
already have a forced-atomics option, IMO it probably makes sense to still
require users to specify that explicitly, rather than effectively defaulting it
to on with Zaamo.
However, I must say, I cannot
jyknight wrote:
There's two sets of atomic functions:
`__atomic_*` are provided by libatomic, and might use locking, or not.
`__sync_*` should always be lock-free. These are only used on certain
architectures where it's guaranteed that the operation _can_ be implemented
lock-free, but it's
jyknight wrote:
Ah, I see that now. SGTM, thanks for the clarification!
https://github.com/llvm/llvm-project/pull/77692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
My suggestion on #69994 had been to stop implying
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` from
`_LIBCPP_ENABLE_CXX20_REMOVED_FEATURES` in LLVM 18 at the same time as
deprecating it. Did you intend to _not_ do that, or was it just missed?
@@ -1056,6 +1056,23 @@ def CC_Intel_OCL_BI : CallingConv<[
CCDelegateTo
]>;
+def CC_X86_64_Preserve_None : CallingConv<[
+ // We don't preserve general registers, so all of them can be used to pass
+ // arguments except
+ // - RBPframe pointer
+ // - R10
@@ -1056,6 +1056,23 @@ def CC_Intel_OCL_BI : CallingConv<[
CCDelegateTo
]>;
+def CC_X86_64_Preserve_None : CallingConv<[
+ // We don't preserve general registers, so all of them can be used to pass
+ // arguments except
+ // - RBPframe pointer
+ // - R10
@@ -33,9 +33,9 @@ void test_i32_atomics(_Atomic(int32_t) * a, int32_t b) {
}
void test_i64_atomics(_Atomic(int64_t) * a, int64_t b) {
- // LA32: call i64 @__atomic_load_8
- // LA32: call void @__atomic_store_8
- // LA32: call i64 @__atomic_fetch_add_8
+ // LA32: load
@@ -23,7 +23,7 @@ typedef __int128_t int128_t;
// PPC64-QUADWORD-ATOMICS:[[TMP3:%.*]] = load atomic i128, ptr
[[TMP1:%.*]] acquire, align 16
//
// PPC64-LABEL: @test_load(
-// PPC64:call void @__atomic_load(i64 noundef 16, ptr noundef
[[TMP3:%.*]], ptr noundef
https://github.com/jyknight commented:
Overall, I think this is a great improvement.
And I believe it should be correct to do now, after fixing the backends'
MaxAtomicSizeInBitsSupported in #75703 #75185 #75112 #74385 #74389, and fixing
Clang's propagation of alignment to atomicrmw/cmpxchg in
@@ -7,22 +7,19 @@
// RUN: %clang_cc1 -triple riscv64 -target-feature +a -O1 -emit-llvm %s -o - \
// RUN: | FileCheck %s -check-prefix=RV64IA
-// This test demonstrates that MaxAtomicInlineWidth is set appropriately when
jyknight wrote:
I think this test
@@ -1,120 +1,147 @@
-// RUN: %clang_cc1 < %s -triple armv5e-none-linux-gnueabi -emit-llvm -O1 |
FileCheck %s
-
-// FIXME: This file should not be checking -O1 output.
-// Ie, it is testing many IR optimizer passes as part of front-end
verification.
+// RUN: %clang_cc1 < %s
@@ -1047,122 +1019,19 @@ RValue CodeGenFunction::EmitAtomicExpr(AtomicExpr *E) {
Dest = Atomics.castToAtomicIntPointer(Dest);
}
- // Use a library call. See: http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary .
- if (UseLibcall) {
-bool UseOptimizedLibcall = false;
-
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/73176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1047,122 +1019,19 @@ RValue CodeGenFunction::EmitAtomicExpr(AtomicExpr *E) {
Dest = Atomics.castToAtomicIntPointer(Dest);
}
- // Use a library call. See: http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary .
- if (UseLibcall) {
-bool UseOptimizedLibcall = false;
-
@@ -30113,32 +30120,40 @@ TargetLoweringBase::AtomicExpansionKind
X86TargetLowering::shouldExpandAtomicStoreInIR(StoreInst *SI) const {
Type *MemType = SI->getValueOperand()->getType();
- bool NoImplicitFloatOps =
-
Author: James Y Knight
Date: 2024-01-03T09:34:07-05:00
New Revision: b3d26426b06ee74bf79f766375a37c384aa0132b
URL:
https://github.com/llvm/llvm-project/commit/b3d26426b06ee74bf79f766375a37c384aa0132b
DIFF:
jyknight wrote:
Ping!
https://github.com/llvm/llvm-project/pull/74275
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
> This sounds extremely unsound
It is completely unsound. The constraints that approximately every architecture
has on LL/SC loops make it unsound to ever generate isolated LL and SC
instructions at the IR level, as we are currently doing on AArch64, ARM, and
Hexagon.
We
@@ -31259,14 +31274,23 @@ static SDValue LowerATOMIC_STORE(SDValue Op,
SelectionDAG ,
if (!IsSeqCst && IsTypeLegal)
return Op;
- if (VT == MVT::i64 && !IsTypeLegal) {
+ if (!IsTypeLegal && !Subtarget.useSoftFloat() &&
+
@@ -30115,12 +30126,16 @@
X86TargetLowering::shouldExpandAtomicLoadInIR(LoadInst *LI) const {
// If this a 64 bit atomic load on a 32-bit target and SSE2 is enabled, we
// can use movq to do the load. If we have X87 we can load into an 80-bit
// X87 register and store
@@ -31259,14 +31274,23 @@ static SDValue LowerATOMIC_STORE(SDValue Op,
SelectionDAG ,
if (!IsSeqCst && IsTypeLegal)
return Op;
- if (VT == MVT::i64 && !IsTypeLegal) {
+ if (!IsTypeLegal && !Subtarget.useSoftFloat() &&
+
@@ -228,87 +228,86 @@ define void @widen_broadcast_unaligned(ptr %p0, i32 %v) {
}
define i128 @load_i128(ptr %ptr) {
-; CHECK-O0-LABEL: load_i128:
-; CHECK-O0: # %bb.0:
-; CHECK-O0-NEXT:pushq %rbx
-; CHECK-O0-NEXT:.cfi_def_cfa_offset 16
-; CHECK-O0-NEXT:
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/74275
>From 7baffd6d1f4254b1bd725ddc883a360d79267435 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 2 Dec 2023 23:05:26 -0500
Subject: [PATCH 1/3] [X86] Use plain load/store instead of cmpxchg16b for
@@ -30095,12 +30102,16 @@ TargetLoweringBase::AtomicExpansionKind
X86TargetLowering::shouldExpandAtomicStoreInIR(StoreInst *SI) const {
Type *MemType = SI->getValueOperand()->getType();
- bool NoImplicitFloatOps =
-
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/74292
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
> > Did this change anything for the `scoped_atomic_compare_exchange_n` variant
> > I added recently?
The scoped variant(s) use the same codepath here, so they'll also verify that
the failure order is valid.
https://github.com/llvm/llvm-project/pull/74959
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/74959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
Ping!
https://github.com/llvm/llvm-project/pull/74275
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
Why only `__atomic_exchange`? Presumably we need to be doing the same with
every other of the atomic builtins as well (unless they already have this check
and we only missed it on exchange?)
https://github.com/llvm/llvm-project/pull/75135
jyknight wrote:
PR description needs to be updated after changes. Otherwise LGTM.
https://github.com/llvm/llvm-project/pull/74959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/74275
>From 7baffd6d1f4254b1bd725ddc883a360d79267435 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 2 Dec 2023 23:05:26 -0500
Subject: [PATCH 1/2] [X86] Use plain load/store instead of cmpxchg16b for
@@ -8728,7 +8728,13 @@ def err_atomic_op_needs_atomic_int : Error<
"%select{|atomic }0integer (%1 invalid)">;
def warn_atomic_op_has_invalid_memory_order : Warning<
"memory order argument to atomic operation is invalid">,
- InGroup>;
+ InGroup;
+def
@@ -8728,7 +8728,13 @@ def err_atomic_op_needs_atomic_int : Error<
"%select{|atomic }0integer (%1 invalid)">;
def warn_atomic_op_has_invalid_memory_order : Warning<
"memory order argument to atomic operation is invalid">,
- InGroup>;
+ InGroup;
+def
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/74959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/74959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/74469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -650,6 +652,7 @@ if (CLANG_ENABLE_BOOTSTRAP)
CLANG_VERSION_MAJOR
CLANG_VERSION_MINOR
CLANG_VERSION_PATCHLEVEL
+CLANG_VERSION_SUFFIX
jyknight wrote:
This list is of CMake variables which automatically get passed through between
stages in a
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/74469
>From 00f710804e77ccc001025a4524ab6882377d1089 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Tue, 5 Dec 2023 08:41:08 -0500
Subject: [PATCH 1/2] Include LLVM_VERSION_SUFFIX in the Clang version string.
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/74469
This causes current mainline to now report "18.0.0git" instead of "18.0.0".
Fixes #53825
>From 00f710804e77ccc001025a4524ab6882377d1089 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Tue, 5 Dec 2023
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/74365
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
I don't think this is a good idea.
Not only is that weird to magically switch to an apple build from a non-apple
platform, this is also not even a particularly useful behavior for an Apple
platform, where "darwin" is basically deprecated, and you're supposed to use a
target
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/74349
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/74349
>From 7fd7ebbf60beacb63ddfff16a7c4405e80cb62b4 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Mon, 4 Dec 2023 12:11:58 -0500
Subject: [PATCH 1/2] Use Address for CGBuilder's CreateAtomicRMW and
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/74349
Update all callers to pass through the Address.
For the older builtins such as `__sync_*` and MSVC `_Interlocked*`, natural
alignment of the atomic access is _assumed_. This change preserves that
behavior. It
@@ -484,6 +484,26 @@ bool
clang::analyze_format_string::parseFormatStringHasFormattingSpecifiers(
return false;
}
+ArgType clang::analyze_format_string::wToArgType(
+int size, bool fast, ASTContext ) {
+ ArgType fastType = C.getTargetInfo().getTriple().isArch64Bit() ?
@@ -286,7 +286,33 @@
clang::analyze_format_string::ParseLengthModifier(FormatSpecifier ,
lmKind = LengthModifier::AsInt3264;
break;
case 'w':
- lmKind = LengthModifier::AsWide; ++I; break;
+ ++I;
+ if (I == E) return false;
+ if (*I == 'f')
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/72869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
Seeing no further feedback, going ahead and submitting.
https://github.com/llvm/llvm-project/pull/72869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
I guess I'd consider the "mental model" here to be that (notionally) `#embed`
is preprocessed by expanding to `#embed_base64`, which is handled by the
compiler proper, not the preprocessor. Yes, that's not entirely true in the
implementation, but it seems like a reasonable way
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/72869
>From 7c51f0cb27079c79f924ff746dccb14637641fe4 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Mon, 20 Nov 2023 13:43:32 +
Subject: [PATCH] Mark some std::string functions noinline.
The intent of these
jyknight wrote:
I'm somewhat concerned about the default for `-E` being to explode `#embed`
into the comma-separated raw integers. Even with moderately-sized embeds, I
think it'll generate unusably-bloated output. The human-readability of a big
list of integers is not better than embedded
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/72718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/72718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
I think we can check whether it's been overridden more easily using an asm
alias like this (when libc++ is built under -fno-exceptions):
```
#include
#include
__attribute__((weak)) void* operator new(std::size_t size) {
void* mem = malloc(size);
if (!mem) abort();
jyknight wrote:
> This pull request implements the entirety of the now-accepted N3017 -
> Preprocessor Embed.
Amazing! I had started to think about looking into getting this implemented
recently, so it's really nice to see an implementation uploaded now!
> I have no intention of following up
jyknight wrote:
Looks like the debug/hardened/safe mode tests are failing
libcxx/std/utilities/template.bitset/bitset.members/to_string.pass.cpp because
the constant evaluations for
```
static_assert(test_to_string<64>());
static_assert(test_to_string<65>());
```
now both hit the constant
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/66576
>From 209a8f9c06a7633737e9f022bc4e61d580ad95e7 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Sat, 16 Sep 2023 12:32:21 +
Subject: [PATCH 1/6] [libcxx] Allow string to use SSO in constant evaluation.
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/66576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/66576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 275 matches
Mail list logo
