jyknight wrote:
The intent of this standards change is that everyone should be able to depend
on library functions from string.h, no matter how minimal or bare-metal their
environment.
The requirement is now:
- , , , , , ,
, , , and .
- , except strcoll, strdup, strerror, strndup, strtok, st
jyknight wrote:
This looks potentially-reasonable from the _Clang_ subproject POV, but from a
whole-project POV, I think we ought to actually provide a conforming
freestanding mode somehow, probably via llvm-libc.
So I'd kinda like to hear from llvm-libc folks what they're thinking here.
@jhu
jyknight wrote:
Wait, _on by default_?
Perhaps I'm out of line with current thinking here, but IMO, on-by-default
should only diagnose things which are likely to be harmful -- NOT just a style
or inefficiency issue, which seems to be all this is diagnosing. That LLVM's
style conflicts with it
jyknight wrote:
Just to say again, I think the discussion may be crisper if we consider this as
two entirely-distinct features:
1. An expansion of "compatible type" for purposes of pointer casts/non-UB/etc.
2. The ability to provide two definitions of the same struct type in the same
scope, to
jyknight wrote:
- In C89: it's impossible to get the address of a temporary struct, so the
lifetime is irrelevant.
- In C99: you now can get the address (from an array subobject), but the
lifetime was defined as "until the next sequence point". This made it
technically illegal to access even n
@@ -3115,11 +3115,24 @@ void CastOperation::CheckCStyleCast() {
Self.CurFPFeatureOverrides());
}
}
- if (DestType->isNullPtrType() && !SrcType->isNullPtrType()) {
-Self.Diag(SrcExpr.get()->getExprLoc(), diag::err_nullptr_cast)
@@ -3115,11 +3115,24 @@ void CastOperation::CheckCStyleCast() {
Self.CurFPFeatureOverrides());
}
}
- if (DestType->isNullPtrType() && !SrcType->isNullPtrType()) {
-Self.Diag(SrcExpr.get()->getExprLoc(), diag::err_nullptr_cast)
jyknight wrote:
LLVM's intentional usage is either to reduce redundant vtable emission via
ensuring there is a key method, OR, to intentionally create a useless vtable,
in order to reduce redundant debuginfo emission (it can be emitted only in the
vtable's TU when there's a vtable.) I expect b
jyknight wrote:
I now see there's two different parts of the problem to worry about:
First case: A redeclaration in a _different_ scope. This always defines a new
distinct type. This was valid before C23, and is still valid regardless of
whether the type is compatible. (In contrast with functi
@@ -450,6 +453,116 @@ class StmtComparer {
};
} // namespace
+static bool IsStructurallyEquivalent(StructuralEquivalenceContext &Context,
+ const Attr *Attr1, const Attr *Attr2) {
+ // Two attributes are structurally equivalent if they are
jyknight wrote:
It seems to me that we could simplify the implementation by being a bit more
literal in the interpretation of the requirements: look only at the type,
alignment, name, and bitfield-width of members. Just don't bother checking
other stuff
I'd hope it can look more like a simple
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/133125
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
> We make a VariableArrayType whose element type is a VariableArrayType rather
> than a ConstantArrayType of size 7 whose element type is a VariableArrayType.
Yea. Up till now I think there was no observable difference between the outer
array having a constant or variable boun
@@ -0,0 +1,92 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// RUN: %clang_cc1 -std=c2y -emit-llvm -o - %s | FileCheck %s
+
+// This tests the codegen behavior for _Countof.
+// CHECK-LABEL: define dso_local i32 @test1(
+
@@ -1073,6 +1073,28 @@ inputs. Here is some example of ``$``-prefixed options:
Language and Target-Independent Features
+Freestanding Builds
+---
+Passing the ``-ffreestanding`` flag causes Clang to build for a freestand
@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c2y -pedantic -Wall -Wno-comment -verify
%s
+
+/* WG14 N3369: Clang 21
+ * _Lengthof operator
+ *
+ * Adds an operator to get the length of an array. Note that WG14 N3469 renamed
+ * this operator to _Countof.
+ */
+
+int gl
https://github.com/jyknight approved this pull request.
LGTM to me now. I hope we will eventually provide a conforming freestanding
implementation, but that's future work.
https://github.com/llvm/llvm-project/pull/132232
___
cfe-commits mailing list
c
@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c2y -pedantic -Wall -Wno-comment -verify
%s
+
+/* WG14 N3369: Clang 21
+ * _Lengthof operator
+ *
+ * Adds an operator to get the length of an array. Note that WG14 N3469 renamed
+ * this operator to _Countof.
+ */
+
+int gl
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/132232
___
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/132232
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1073,6 +1073,28 @@ inputs. Here is some example of ``$``-prefixed options:
Language and Target-Independent Features
+Freestanding Builds
+---
+Passing the ``-ffreestanding`` flag causes Clang to build for a freestand
@@ -9242,3 +9242,15 @@ Declares that a function potentially allocates heap
memory, and prevents any pot
of ``nonallocating`` by the compiler.
}];
}
+
+def ValueTypeDocs : Documentation {
+ let Category = DocCatDecl;
+ let Content = [{
+The ``value_type`` attribute can be u
@@ -6,27 +6,20 @@
#include
-#define DERP this is an error
-
void func(...) { // expected-warning {{'...' as the only parameter of a
function is incompatible with C standards before C23}}
// Show that va_start doesn't require the second argument in C23 mode.
va_list l
jyknight wrote:
Abandoning in favor of kadircet's #125722 and #125714.
https://github.com/llvm/llvm-project/pull/124141
___
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/124141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
(Oh, all these suppression mappings fixes will need to be backported to the
20.x branch too.)
https://github.com/llvm/llvm-project/pull/125714
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/125722
___
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/125714
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -547,11 +547,9 @@ void
WarningsSpecialCaseList::processSections(DiagnosticsEngine &Diags) {
StringRef DiagGroup = SectionEntry->getKey();
if (Diags.getDiagnosticIDs()->getDiagnosticsInGroup(
WarningFlavor, DiagGroup, GroupDiags)) {
- StringRef Sugge
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/124141
This allows the same file to be used on multiple Clang versions, without
generating output spam.
Also disable parsing of the suppressions file in the Driver, where it's not
needed. This was previously causing
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/124141
>From 56faefda954130f1f67d160d6ccc98e50f22674c Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Thu, 23 Jan 2025 11:02:20 -0500
Subject: [PATCH 1/2] [Clang] Silently ignore unknown warnings in
`--warning-su
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/121943
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3911,14 +3926,31 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange,
SourceRange ExprRange,
}
}
- // Pointer to object of size zero is not allowed.
- if (RequireCompleteType(Ptr->getBeginLoc(), AtomTy,
- diag::err_incomplete_type))
@@ -3963,8 +3995,8 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange,
SourceRange ExprRange,
return ExprError();
}
- if (!IsC11 && !AtomTy.isTriviallyCopyableType(Context) &&
- !AtomTy->isScalarType()) {
+ if (!IsC11 && Form != TestAndSet && Form != Clear
@@ -3686,12 +3687,18 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange,
SourceRange ExprRange,
C11CmpXchg,
// bool __atomic_compare_exchange(A *, C *, CP, bool, int, int)
-GNUCmpXchg
+GNUCmpXchg,
+
+// bool __atomic_test_and_set(A *, int)
+Test
https://github.com/jyknight commented:
Looks basically good to me, just a couple suggestions to improve the code
clarity.
https://github.com/llvm/llvm-project/pull/121943
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -3911,14 +3926,31 @@ ExprResult Sema::BuildAtomicExpr(SourceRange CallRange,
SourceRange ExprRange,
}
}
- // Pointer to object of size zero is not allowed.
- if (RequireCompleteType(Ptr->getBeginLoc(), AtomTy,
- diag::err_incomplete_type))
@@ -1977,16 +1977,16 @@ def AtomicNandFetch : AtomicBuiltin {
let Prototype = "void(...)";
}
-def AtomicTestAndSet : Builtin {
+def AtomicTestAndSet : AtomicBuiltin {
let Spellings = ["__atomic_test_and_set"];
- let Attributes = [NoThrow];
- let Prototype = "bool(void v
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/121943
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
Yes, the code in libpcap is correct, and the new Clang behavior is incorrect.
`__atomic_clear` and `__atomic_test_and_set` are intentionally different from
the other atomic builtins, in that they are _not_ type-generic, but instead
always operate on the single byte at the provi
jyknight wrote:
Hm, I had a thought which might meet the needs here, and not add additional
confusion: we could have the Darwin SDKROOT environment variable override both
`-isysroot` and `--sysroot`. Would that help the original issue?
https://github.com/llvm/llvm-project/pull/115993
_
jyknight wrote:
This is the intended/expected behavior.
On every other platform, `-isysroot` is supposed to be an override setting the
sysroot only for the header files, and _never_ overriding the linker sysroot.
The `--sysroot` flag, on the other hand, sets the value used for both libraries
https://github.com/jyknight approved this pull request.
https://github.com/llvm/llvm-project/pull/117364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2047,6 +2047,14 @@ StringRef CodeGenModule::getMangledName(GlobalDecl GD) {
GD.getWithKernelReferenceKind(KernelReferenceKind::Kernel),
ND));
+ // This invariant should hold true in the future.
+ // Prior work:
+ //
https://discourse.l
Author: James Y Knight
Date: 2024-11-21T21:03:11-05:00
New Revision: dc580c9cf65d9bdad92e127325b50e712422379b
URL:
https://github.com/llvm/llvm-project/commit/dc580c9cf65d9bdad92e127325b50e712422379b
DIFF:
https://github.com/llvm/llvm-project/commit/dc580c9cf65d9bdad92e127325b50e712422379b.diff
jyknight wrote:
(...and maybe we could also get rid of the similar hacks we did for
_mm_mfence/etc before? The commit message for
727ab8a80346eeec39e13293f5dc01cc82bb1d95 didn't say anything about the
rationale, but if it's the same as this, then perhaps so?)
https://github.com/llvm/llvm-proj
jyknight wrote:
So, this is interesting, because the decls _already_ don't conflict, normally.
They only conflict if the x86intrin.h is included within a `extern "C++" {}`
block, _and_ is included after windows.h.
It comes down to, effectively this. Note, run the examples with
`-fms-extension
jyknight wrote:
Some projects still seem to have a requirement for compatibility with GCC 4.8
-- which supports a lot of C++11 but didn't apply the change in CWG 1473, and
thus _require_ the space in `operator"" _udl`. That is somewhat unfortunate.
Two examples from the first page of github se
jyknight wrote:
Here's another test-case which is broken by this commit (both at this commit,
and after the follow-up PRs). It seems to no longer allow non-type template
packs of multiple types. I'm surprised we have no test-cases for this in the
clang test-suite!
```
template class Arg>
str
jyknight wrote:
> I think that's a separable issue from this PR
Yep. I brought it up mainly in case consideration of that set of issues might
necessitate design changes here. It sounds like that's not the case though, so
I'm happy for it to not be a blocker for this PR.
https://github.com/llv
jyknight wrote:
I worry about string literals in vague-linkage entities, because the "version"
of the string literal which is referred to from an inline-function/variable at
runtime may not actually be the same version of the string literal seen in the
current compilation -- at runtime we may
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/107155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
I'll commit as soon as anyone gives it an approval. :)
https://github.com/llvm/llvm-project/pull/107155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
If we don't keep the include-guard, then we'll report the same warning once per
`#include`, instead of once per TU, which is probably not ideal.
https://github.com/llvm/llvm-project/pull/107155
___
cfe-commits mailing list
cfe-commits@
jyknight wrote:
The only impact is that any modular header which includes this file will end up
with a definition of the header guard, instead of importing it, right? It's not
clear to me why it's useful to care about that?
(I totally do understand worrying about cases which result in e.g. hav
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/107155
This avoids issuing the deprecation diagnostic when building the module.
Not building it into a module shouldn't cause any negative impacts, since it no
longer has any declarations other than the header guard.
jyknight wrote:
Do the include guard macros make it problematic to expose as a textual header?
I would not have thought that to be the case.
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:
jyknight wrote:
I think we can just switch it to be a textual header; it no longer has any
decls.
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
jyknight wrote:
We aren't compliant for assignment either with x87 float/double -- e.g. enable
`-O2` on your example.
I think we need to say that we conform except on 32-bit x86 with SSE2 disabled,
and link to an appropriate bug. Maybe we'll fix that backend someday. Or maybe
not.
https://gi
https://github.com/jyknight approved this pull request.
LGTM, thanks.
https://github.com/llvm/llvm-project/pull/101005
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jyknight wrote:
It seems a bit confusing to me to create a situation where `-ffast-math` is
equivalent to `-ffp-model=aggressive`, not `-ffp-model=fast`.
https://github.com/llvm/llvm-project/pull/100453
___
cfe-commits mailing list
cfe-commits@lists.l
jyknight wrote:
@RKSimon has fixed in abacc5220e228012b0b86ca2ed540ef1a715f1ee, thanks. Sorry
for missing that!
https://github.com/llvm/llvm-project/pull/98505
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
@@ -94,14 +94,15 @@ entry:
;
; MMX Store
+; Note: doesn't actually emit a non-temporal store here.
;
define void @test_mmx(ptr nocapture %a0, ptr nocapture %a1) {
; ALL-LABEL: test_mmx:
; ALL: # %bb.0: # %entry
; ALL-NEXT:movq (%rdi), %mm0
; ALL-NEXT:psrl
@@ -159,6 +159,20 @@ AMDGPU Support
X86 Support
^^^
+- The MMX vector intrinsic functions from ``*mmintrin.h`` which
+ operate on `__m64` vectors, such as ``_mm_add_pi8``, have been
+ reimplemented to use the SSE2 instruction-set and XMM registers
+ unconditionally.
Author: James Y Knight
Date: 2024-07-24T18:39:16-04:00
New Revision: b79568654e38a14ef921af932ed96abd8961b1ed
URL:
https://github.com/llvm/llvm-project/commit/b79568654e38a14ef921af932ed96abd8961b1ed
DIFF:
https://github.com/llvm/llvm-project/commit/b79568654e38a14ef921af932ed96abd8961b1ed.diff
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/96540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -49,12 +49,10 @@ typedef __bf16 __m128bh __attribute__((__vector_size__(16),
__aligned__(16)));
#endif
/* Define the default attributes for the functions in this file. */
-#define __DEFAULT_FN_ATTRS
\
- __attribute__((_
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/98273
>From 546963316017935bfbbc05d7095d645344fbd5f5 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 10 Jul 2024 00:49:25 -0400
Subject: [PATCH 1/3] Clang: don't unnecessarily convert inline-asm operands to
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/99340
___
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/99340
>From 2cb327b0377d4196982842455e2aaf4e6a21f667 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 10:43:45 -0400
Subject: [PATCH 1/4] Handle constant "pointers" for
`__atomic_always_lock_free`
@@ -94,14 +94,15 @@ entry:
;
; MMX Store
+; Note: doesn't actually emit a non-temporal store here.
;
define void @test_mmx(ptr nocapture %a0, ptr nocapture %a1) {
; ALL-LABEL: test_mmx:
; ALL: # %bb.0: # %entry
; ALL-NEXT:movq (%rdi), %mm0
; ALL-NEXT:psrl
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/99352
___
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/99352
___
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/99352
___
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/99352
___
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/99352
>From 70160e033ac94de92fc2cd6289548094cd893498 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 11:40:38 -0400
Subject: [PATCH 1/5] Remove 3dnow from X86TargetParser.
This should've been par
jyknight wrote:
I believe all the comments here are addressed; any more concerns/comments, or
is this good to go?
https://github.com/llvm/llvm-project/pull/96540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99340
>From 2cb327b0377d4196982842455e2aaf4e6a21f667 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 10:43:45 -0400
Subject: [PATCH 1/3] Handle constant "pointers" for
`__atomic_always_lock_free`
https://github.com/jyknight edited
https://github.com/llvm/llvm-project/pull/99340
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -124,6 +124,24 @@ _Static_assert(__atomic_always_lock_free(4, &i64), "");
_Static_assert(!__atomic_always_lock_free(8, &i32), "");
_Static_assert(__atomic_always_lock_free(8, &i64), "");
+// Validate use with fake pointers constants. This mechanism is used to allow
+// vali
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99340
>From 2cb327b0377d4196982842455e2aaf4e6a21f667 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 10:43:45 -0400
Subject: [PATCH 1/2] Handle constant "pointers" for
`__atomic_always_lock_free`
@@ -175,8 +175,6 @@ X86_FEATURE_COMPAT(AVX512BF16, "avx512bf16",
34)
X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect", 35)
// Below Features has some missings comparing to gcc, it's because gcc has some
// not one-to-one mapped in llvm.
-X86_FEATURE_
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99352
>From 70160e033ac94de92fc2cd6289548094cd893498 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 11:40:38 -0400
Subject: [PATCH 1/4] Remove 3dnow from X86TargetParser.
This should've been par
@@ -175,8 +175,6 @@ X86_FEATURE_COMPAT(AVX512BF16, "avx512bf16",
34)
X86_FEATURE_COMPAT(AVX512VP2INTERSECT, "avx512vp2intersect", 35)
// Below Features has some missings comparing to gcc, it's because gcc has some
// not one-to-one mapped in llvm.
-X86_FEATURE_
@@ -124,6 +124,24 @@ _Static_assert(__atomic_always_lock_free(4, &i64), "");
_Static_assert(!__atomic_always_lock_free(8, &i32), "");
_Static_assert(__atomic_always_lock_free(8, &i64), "");
+// Validate use with fake pointers constants. This mechanism is used to allow
+// vali
https://github.com/jyknight updated
https://github.com/llvm/llvm-project/pull/99352
>From 70160e033ac94de92fc2cd6289548094cd893498 Mon Sep 17 00:00:00 2001
From: James Y Knight
Date: Wed, 17 Jul 2024 11:40:38 -0400
Subject: [PATCH 1/3] Remove 3dnow from X86TargetParser.
This should've been par
@@ -171,14 +171,14 @@ constexpr FeatureBitset FeaturesClearwaterforest =
// Geode Processor.
constexpr FeatureBitset FeaturesGeode =
-FeatureX87 | FeatureCMPXCHG8B | FeatureMMX | Feature3DNOW | Feature3DNOWA;
jyknight wrote:
OK, making the change.
I note
https://github.com/jyknight approved this pull request.
Thanks, LGTM. I like this version.
Did this change also fix any other bugs? Since it looks like we were previously
not skipping ProcessDeclAttribute for ``[[]]`` attributes in C23 mode, when
IncludeCXX11Attributes == false, and we were su
@@ -171,14 +171,14 @@ constexpr FeatureBitset FeaturesClearwaterforest =
// Geode Processor.
constexpr FeatureBitset FeaturesGeode =
-FeatureX87 | FeatureCMPXCHG8B | FeatureMMX | Feature3DNOW | Feature3DNOWA;
jyknight wrote:
(I somewhat lean towards submi
@@ -171,14 +171,14 @@ constexpr FeatureBitset FeaturesClearwaterforest =
// Geode Processor.
constexpr FeatureBitset FeaturesGeode =
-FeatureX87 | FeatureCMPXCHG8B | FeatureMMX | Feature3DNOW | Feature3DNOWA;
jyknight wrote:
Possibly not?
We didn't enabl
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/99352
This addresses the spurious inclusion of (now unsupported) target features
'-3dnow' and '-3dnowa', when disabling mmx.
It should've been part of PR #96246, but was missed.
>From 70160e033ac94de92fc2cd628954809
https://github.com/jyknight created
https://github.com/llvm/llvm-project/pull/99340
The second argument passed to these builtins is used to validate whether the
object's alignment is sufficient for atomic operations of the given size.
Currently, the builtins can be folded at compile time only
jyknight wrote:
Thanks for the report! Looks like I missed some 3dnow mentions in
llvm/lib/TargetParser/X86TargetParser.cpp, so `-mno-mmx` is still emitting this
feature.
I don't believe it should have any impact other than the warning spam, but I
will fix it.
https://github.com/llvm/llvm-pr
https://github.com/jyknight closed
https://github.com/llvm/llvm-project/pull/96246
___
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.
Sounds good enough to me, thank you!
https://github.com/llvm/llvm-project/pull/98736
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
@@ -481,7 +481,7 @@ defm WriteAESKeyGen : X86SchedWritePair;
// Key Generation.
// Carry-less multiplication instructions.
defm WriteCLMul : X86SchedWritePair;
-// EMMS/FEMMS
jyknight wrote:
Thanks, done. That was a leftover from a previous iteration where I
@@ -936,6 +936,24 @@ X86 Support
^^^
- Remove knl/knm specific ISA supports: AVX512PF, AVX512ER, PREFETCHWT1
+- Support has been removed for the AMD "3DNow!" instruction-set.
+ Neither modern AMD CPUs, nor any Intel CPUs implement these
+ instructions, and they were
@@ -7,7 +7,7 @@
define <2 x i32> @test_pswapdsi(<2 x i32> %a) nounwind readnone {
jyknight wrote:
Done.
https://github.com/llvm/llvm-project/pull/96246
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
jyknight wrote:
The part I'm confused about is that this commit doesn't appear to simply be
adding "or `alignas`" to some code that said "if `_Alignas`". Yes, the newly
added `isAlignas()` checks do cover both attributes, but `_Alignas` was still
working even after b9cf7f1.
That is, in clang
@@ -57594,6 +57599,86 @@ static SDValue combinePDEP(SDNode *N, SelectionDAG
&DAG,
return SDValue();
}
+// Fixup the MMX intrinsics' types: in IR they are expressed with <1 x i64>,
jyknight wrote:
We perhaps _could_ use i64, but i64 is also not a legal type
1 - 100 of 450 matches
Mail list logo
