[clang] Adjust modulemap to mark mm3dnow as textual header. (PR #107155)

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

[clang] Turn `-Wdeprecated-literal-operator` on by default (PR #111027)

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

[clang] Reland: [clang] Finish implementation of P0522 (PR #111711)

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

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

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

[clang] [clang] implement current direction of CWG2765 for string literal comparisons in constant evaluation (PR #109208)

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

[clang] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h conflicts (PR #115099)

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

[clang] [Win/X86] Make _m_prefetch[w] builtins to avoid winnt.h conflicts (PR #115099)

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

[clang] [Darwin][Driver][clang] Prioritise `-isysroot` over `--sysroot` consistently (PR #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

[clang] [Darwin][Driver][clang] Prioritise `-isysroot` over `--sysroot` consistently (PR #115993)

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 _

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #121943)

@@ -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))

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #121943)

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

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #121943)

@@ -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

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #121943)

@@ -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

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #121943)

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

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #121943)

@@ -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

[clang] [clang] Parse warning-suppression-mapping after setting up diagengine (PR #125714)

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

[clang] [clang] Stop parsing warning suppression mappings in driver (PR #125722)

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

[clang] [clang] Parse warning-suppression-mapping after setting up diagengine (PR #125714)

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

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #120449)

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

[clang] [clang][codegen] Mention the invariant that LLVM demangler should be … (PR #117346)

@@ -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

[clang] [C23] Fixed the value of BOOL_WIDTH (PR #117364)

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

[clang] dc580c9 - Switch test back from getRealFileSystem to createPhysicalFileSystem

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

[clang] [Clang] Silently ignore unknown warnings in `--warning-suppression-mappings` (PR #124141)

@@ -547,11 +547,9 @@ void WarningsSpecialCaseList::processSections(DiagnosticsEngine &Diags) { StringRef DiagGroup = SectionEntry->getKey(); if (Diags.getDiagnosticIDs()->getDiagnosticsInGroup( WarningFlavor, DiagGroup, GroupDiags)) { - StringRef Sugge

[clang] [Clang] Silently ignore unknown warnings in `--warning-suppression-mappings` (PR #124141)

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 `--warn

[clang] [Clang] Silently ignore unknown warnings in `--warning-suppression-mappings` (PR #124141)

the suppression file is parsed _before_ the diagnostic state has been setup. >From 56faefda954130f1f67d160d6ccc98e50f22674c Mon Sep 17 00:00:00 2001 From: James Y Knight Date: Thu, 23 Jan 2025 11:02:20 -0500 Subject: [PATCH] [Clang] Silently ignore unknown warnings in `--warning-suppression-mappi

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #121943)

@@ -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))

[clang] [Clang] Re-write codegen for atomic_test_and_set and atomic_clear (PR #121943)

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

[clang] [Clang] Silently ignore unknown warnings in `--warning-suppression-mappings` (PR #124141)

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

[clang] [Clang] Silently ignore unknown warnings in `--warning-suppression-mappings` (PR #124141)

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

[clang] [clang] Add value_type attr, use it to add noalias when pass-by-value. (PR #95004)

@@ -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

[clang] [Docs] Document freestanding requirements (PR #132232)

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

[clang] [Docs] Document freestanding requirements (PR #132232)

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

[clang] [llvm] Enable unnecessary-virtual-specifier by default (PR #133265)

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

[clang] [C2y] Implement WG14 N3369 and N3469 (_Countof) (PR #133125)

@@ -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

[clang] [Docs] Document freestanding requirements (PR #132232)

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

[clang] [C2y] Implement WG14 N3369 and N3469 (_Countof) (PR #133125)

@@ -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

[clang] [Docs] Document freestanding requirements (PR #132232)

@@ -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

[clang] [C23] Implement WG14 N3037 (PR #132939)

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

[clang] [C2y] Implement WG14 N3369 and N3469 (_Countof) (PR #133125)

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

[clang] [C2y] Implement WG14 N3369 and N3469 (_Countof) (PR #133125)

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

[clang] [C2y] Implement WG14 N3369 and N3469 (_Countof) (PR #133125)

@@ -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( +

[clang] [C23] Implement WG14 N3037 (PR #132939)

@@ -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

[clang] [C23] Implement WG14 N3037 (PR #132939)

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

[clang] [llvm] Enable unnecessary-virtual-specifier by default (PR #133265)

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

[clang] [C23] Allow casting from a null pointer constant to nullptr_t (PR #133742)

@@ -3115,11 +3115,24 @@ void CastOperation::CheckCStyleCast() { Self.CurFPFeatureOverrides()); } } - if (DestType->isNullPtrType() && !SrcType->isNullPtrType()) { -Self.Diag(SrcExpr.get()->getExprLoc(), diag::err_nullptr_cast)

[clang] [C23] Allow casting from a null pointer constant to nullptr_t (PR #133742)

@@ -3115,11 +3115,24 @@ void CastOperation::CheckCStyleCast() { Self.CurFPFeatureOverrides()); } } - if (DestType->isNullPtrType() && !SrcType->isNullPtrType()) { -Self.Diag(SrcExpr.get()->getExprLoc(), diag::err_nullptr_cast)

[clang] [C11] Implement WG14 N1285 (temporary lifetimes) (PR #133472)

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

[clang] Disable -fdollars-in-identifiers by default (PR #135407)

jyknight wrote: > It appears that gcc only disallows '$' in identifiers in C++26 mode. Not sure > how relevant that is to clang. > [bugzilla](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343) Or am I > misreading that thread? As far as I can tell, GCC has _not_ disallowed '$' in identifier

[clang] [C23] Add __builtin_c23_va_start (PR #131166)

@@ -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

[clang] [C23] Implement WG14 N3037 (PR #132939)

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

[clang] [Docs] Document freestanding requirements (PR #132232)

@@ -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

[clang] [Docs] Document freestanding requirements (PR #132232)

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

[clang] [Docs] Document freestanding requirements (PR #132232)

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

[clang] [libcxx] [llvm] [Clang] Add warnings when mixing different charN_t types (PR #138708)

jyknight wrote: I like the idea of this warning, but I'm afraid the diagnostic wording isn't sufficient to result in correct fixes to code. Instead, it seems to result in simply adding explicit casts to make the compiler shut up. Even from people who know what they're doing w.r.t. Unicode. Th

[clang] [clang-tools-extra] [lldb] [clang] Remove intrusive reference count from `DiagnosticOptions` (PR #139584)

jyknight wrote: I'm trying to update some non-in-tree code after this change, and I don't think I understand the newly-expected lifetime rules after this change. I see all the comments that say this makes lifetime clearer...so I expect I'm just misunderstanding things. Previously, Diagnostics

[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

jyknight added a comment. In https://reviews.llvm.org/D42933#1090384, @jfb wrote: > In https://reviews.llvm.org/D42933#1090286, @smeenai wrote: > > > I'd be fine with adding an option to relax the printf checking if the size > > and alignment of the specifier and the actual type match, even if t

[PATCH] D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers

jyknight added a comment. In https://reviews.llvm.org/D42933#1091817, @jfb wrote: > In https://reviews.llvm.org/D42933#1091809, @jyknight wrote: > > > I also think that special casing these two specifiers doesn't make sense. > > The problem is a general issue -- and one I've often found irritati

[PATCH] D47137: [Sparc] Add floating-point register names

jyknight added a comment. Can you add a test that we support this? clang/test/CodeGen/sparcv8-inline-asm.c would be a good place to add a test case similar to that in clang/test/CodeGen/aarch64-inline-asm.c : test_gcc_registers. Repository: rC Clang https://reviews.llvm.org/D47137 _

[PATCH] D47138: [Sparc] Use the leon arch for Leon3's when using an external assembler

jyknight added a comment. There are more leon-based v8 CPUs listed in clang/lib/Basic/Targets/Sparc.cpp, which need to be listed here, also. Separately, I think it'd be a good idea to refactor to put this info into the SparcCPUInfo struct, so that it's harder for them to get out of sync. Repo

[PATCH] D47138: [Sparc] Use the leon arch for Leon3's when using an external assembler

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. In https://reviews.llvm.org/D47138#1107637, @dcederman wrote: > I did not find a good way to access the SparcCPUInfo struct from here. No > other arch under Toolchains seems to access Targ

[PATCH] D47137: [Sparc] Add floating-point register names

jyknight added inline comments. Comment at: lib/Basic/Targets/Sparc.cpp:32 +"f22", "f23", "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31", "f32", +"f33", "f34", "f35", "f36", "f37", "f38", "f39", "f40", "f41", "f42", "f43", +"f44", "f45", "f46", "f47", "f48",

[PATCH] D37954: Try to shorten system header paths when using -MD depfiles

jyknight added a comment. I think the diagnosis on the original issue was incorrect. It seems to me that it was caused by the prefix being set as "/bin" instead of "/usr/bin", because clang _doesn't_ actually canonicalize its prefix, even when -no-canonical-prefixes isn't specified! All it does

[PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

jyknight added a comment. I'd still _very_ much like a solution that is acceptable for all libc to use, and have that on by default. However, I guess this is fine. Only concern I have is that it seems odd that so many test-cases needed to be changed. What fails without those test changes? ht

[PATCH] D49927: [libc++] Exclude posix_l/strtonum fallback inclusion for newlib > 2.4

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. Typo in commit message? They were added to 2.5, not 2.4 (the code is right, just the comment is wrong). Repository: rCXX libc++ https://reviews.llvm.org/D49927 _

[PATCH] D32146: PR32476: __nop_locale_mgmt.h not needed with newlib 2.5+

This revision was automatically updated to reflect the committed changes. Closed by commit rL305394: PR32476: __nop_locale_mgmt.h not needed with newlib 2.5+ (authored by jyknight). Changed prior to commit: https://reviews.llvm.org/D32146?vs=102265&id=102562#toc Repository: rL LLVM https://

[PATCH] D34105: Define _GNU_SOURCE for rtems c++

This revision was automatically updated to reflect the committed changes. Closed by commit rL305399: Define _GNU_SOURCE for rtems c++ (authored by jyknight). Changed prior to commit: https://reviews.llvm.org/D34105?vs=102188&id=102565#toc Repository: rL LLVM https://reviews.llvm.org/D34105

[PATCH] D34294: Rework libcxx strerror_r handling.

jyknight created this revision. Herald added subscribers: krytarowski, srhines. The set of #ifdefs used to handle the two incompatible variants of strerror_r were not complete (they didn't handle newlib appropriately). Rather than attempting to make the ifdefs more complex, make them unnecessary

[PATCH] D34294: Rework libcxx strerror_r handling.

jyknight added a comment. In https://reviews.llvm.org/D34294#782806, @krytarowski wrote: > New one is harder to comprehend and less portable (usage of `__atribute__`). I can't disagree more strongly. This is fundamentally portable C++ code -- __attribute__((unused)) is simply warning suppress

[PATCH] D34294: Rework libcxx strerror_r handling.

jyknight added a comment. EricWF, wdyt? https://reviews.llvm.org/D34294 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D35755: [Solaris] gcc toolchain handling revamp

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. This looks reasonable on the face of it. I'm assuming you know the layout for Solaris, and it doesn't seem to change the behavior of non-Solaris, so LGTM. https://reviews.llvm.org/D35755

[PATCH] D47894: [clang]: Add support for "-fno-delete-null-pointer-checks"

jyknight added a comment. In https://reviews.llvm.org/D47894#1125653, @efriedma wrote: > The problem would come from propagating nonnull-ness from something which > isn't inherently nonnull. For example, strlen has a nonnull argument, so > `strlen(NULL)` is UB, therefore given `int z = strlen(

[PATCH] D47894: [clang]: Add support for "-fno-delete-null-pointer-checks"

jyknight added a comment. In https://reviews.llvm.org/D47894#1125961, @srhines wrote: > In https://reviews.llvm.org/D47894#1125728, @jyknight wrote: > > > In https://reviews.llvm.org/D47894#1125653, @efriedma wrote: > > > > > The problem would come from propagating nonnull-ness from something whi

[PATCH] D52703: Allow ifunc resolvers to accept arguments

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. Given that there's no technical reason for the compiler to prohibit this (it was just clang trying to diagnose a probable user-error, which turns out to not be as probable as ), this seems

[PATCH] D52924: Make __builtin_object_size use the EM_IgnoreSideEffects evaluation mode.

This revision was automatically updated to reflect the committed changes. Closed by commit rC344110: ExprConstant: Make __builtin_object_size use EM_IgnoreSideEffects. (authored by jyknight, committed by ). Herald added a subscriber: kristina. Changed prior to commit: https://reviews.llvm.org/D

[PATCH] D53199: Fix the behavior of clang's -w flag.

jyknight created this revision. jyknight added a reviewer: rsmith. It is intended to disable _all_ warnings, even those upgraded to errors via `-Werror=warningname` or `#pragma clang diagnostic error' https://reviews.llvm.org/D53199 Files: clang/lib/Basic/DiagnosticIDs.cpp clang/test/Fronte

[PATCH] D52939: ExprConstant: Propagate correct return values from constant evaluation.

jyknight updated this revision to Diff 169641. jyknight marked 11 inline comments as done. jyknight added a comment. Address most comments. https://reviews.llvm.org/D52939 Files: clang/include/clang/AST/Expr.h clang/lib/AST/ExprConstant.cpp Index: clang/lib/AST/ExprConstant.cpp ===

[PATCH] D52939: ExprConstant: Propagate correct return values from constant evaluation.

jyknight added inline comments. Comment at: clang/lib/AST/ExprConstant.cpp:12-32 // Constant expression evaluation produces four main results: // // * A success/failure flag indicating whether constant folding was successful. //This is the 'bool' return value used by mo

[PATCH] D53199: Fix the behavior of clang's -w flag.

jyknight added a comment. Ping. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53199/new/ https://reviews.llvm.org/D53199 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57330: Adjust documentation for git migration.

jyknight created this revision. jyknight added reviewers: jlebar, rnk, mehdi_amini. Herald added subscribers: jsji, jfb, arphaman, christof, delcypher, hiraditya, nhaehnle, jvesely, nemanjai, kubamracek, arsenm. Herald added a reviewer: bollu. Herald added a reviewer: serge-sans-paille. This fixe

[PATCH] D57330: Adjust documentation for git migration.

jyknight updated this revision to Diff 183891. jyknight added a comment. Fix some warnings I added. Restore TestSuiteMakefileGuide.rst, which apparently isn't 100% obsolete. (But it is incorrect, and I'm not sure exactly how to fix it, so I just left a FIXME). CHANGES SINCE LAST ACTION https:

[PATCH] D53199: Fix the behavior of clang's -w flag.

jyknight added inline comments. Comment at: clang/lib/Basic/DiagnosticIDs.cpp:460-463 + // Honor -w: this disables all messages mapped to Warning severity, and *also* + // any diagnostics which are not Error/Fatal by default (that is, they were + // upgraded by any of the mec

[PATCH] D53199: Fix the behavior of clang's -w flag.

jyknight updated this revision to Diff 183966. jyknight marked 2 inline comments as done. jyknight added a comment. Fix to not disable remarks, reword comment, adjust implementation-of-module.m test-case. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D53199/new/ https://reviews.llvm.org

[PATCH] D57330: Adjust documentation for git migration.

jyknight marked 8 inline comments as done. jyknight added a comment. In D57330#1375096 , @labath wrote: > I am not sure we should be recommending to people to place the build folder > under the llvm-project checkout. Is that how people use the monorepo bu

[PATCH] D57330: Adjust documentation for git migration.

This revision was automatically updated to reflect the committed changes. jyknight marked 2 inline comments as done. Closed by commit rC352514: Adjust documentation for git migration. (authored by jyknight, committed by ). Changed prior to commit: https://reviews.llvm.org/D57330?vs=183891&id=18

[PATCH] D53199: Fix the behavior of clang's -w flag.

This revision was automatically updated to reflect the committed changes. Closed by commit rL352535: Fix the behavior of clang's -w flag. (authored by jyknight, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit: https://reviews.llvm.org/D53199?vs=183966&id=184142#

[PATCH] D57315: [opaque pointer types] Add a FunctionCallee wrapper type, and use it.

This revision was automatically updated to reflect the committed changes. Closed by commit rC352791: [opaque pointer types] Add a FunctionCallee wrapper type, and use it. (authored by jyknight, committed by ). Herald added a subscriber: cfe-commits. Changed prior to commit: https://reviews.llvm

[PATCH] D55057: [Headers] Make max_align_t match GCC's implementation.

jyknight added inline comments. Comment at: lib/Headers/__stddef_max_align_t.h:40 __attribute__((__aligned__(__alignof__(long double; +#ifdef __i386__ + __float128 __clang_max_align_nonce3 Can you fix clang to consistently define `__SIZEOF_FLOAT128__`

[PATCH] D55057: [Headers] Make max_align_t match GCC's implementation.

jyknight added inline comments. Comment at: lib/Headers/__stddef_max_align_t.h:40 __attribute__((__aligned__(__alignof__(long double; +#ifdef __i386__ + __float128 __clang_max_align_nonce3 uweigand wrote: > jyknight wrote: > > Can you fix clang to con

[PATCH] D55150: Emit warnings from the driver for use of -mllvm or -Xclang options.

jyknight created this revision. jyknight added reviewers: rsmith, chandlerc. Herald added a subscriber: arphaman. This warning, Wexperimental-driver-option, is on by default, exempt from -Werror, and may be disabled. Additionally, change the documentation to note that these options are not intend

[PATCH] D55057: [Headers] Make max_align_t match GCC's implementation.

jyknight added inline comments. Comment at: lib/Headers/__stddef_max_align_t.h:40 __attribute__((__aligned__(__alignof__(long double; +#ifdef __i386__ + __float128 __clang_max_align_nonce3 EricWF wrote: > uweigand wrote: > > jyknight wrote: > > > uwei

[PATCH] D54547: PTH-- Remove feature entirely-

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. Since you've already submitted a fix to Boost, https://github.com/boostorg/build/commit/3385fe2aa699a45e722a1013658f824b6a7c761f, I think this is fine to remove. CHANGES SINCE LAST ACTIO

[PATCH] D55150: Emit warnings from the driver for use of -mllvm or -Xclang options.

jyknight added a comment. In D55150#1318082 , @chandlerc wrote: > I think this should be `internal-driver-option` and the text updated? I don't > think these are necessarily experimental, they're internals of the compiler > implementation, and not a supp

[PATCH] D55150: Emit warnings from the driver for use of -mllvm or -Xclang options.

jyknight added a comment. In D55150#1321046 , @kristina wrote: > Personally I'm against this type of warning as it's likely anyone using > `-mllvm` is actually intending to adjust certain behaviors across one or more > passes with a lot of switches suppo

[PATCH] D55150: Emit warnings from the driver for use of -mllvm or -Xclang options.

jyknight added a comment. In D55150#1321705 , @kristina wrote: > > There is a cost to having people encode these flags into their build > > systems -- it can then cause issues if we ever change these internal flags. > > I do not think any Clang maintaine

[PATCH] D55150: Emit warnings from the driver for use of -mllvm or -Xclang options.

jyknight added a comment. In D55150#1321759 , @george.karpenkov wrote: > Using `-Xclang` is the only way to pass options to the static analyzer, I > don't think we should warn on it. Well,, that seems unfortunate if we have the only supported interface

[PATCH] D55150: Emit warnings from the driver for use of -mllvm or -Xclang options.

jyknight added a comment. In D55150#1321829 , @efriedma wrote: > I'm not sure that putting a warning that can be disabled really helps here; > anyone who needs the option will just disable the warning anyway, and then > users adding additional options so

[PATCH] D54355: Use is.constant intrinsic for __builtin_constant_p

jyknight added a comment. In D54355#1327237 , @craig.topper wrote: > Here's the test case that we have https://reviews.llvm.org/P8123 gcc seems > to accept it at O0 Smaller test case: extern unsigned long long __sdt_unsp; void foo() { __a

[PATCH] D57914: [Driver] Allow enum SanitizerOrdinal to represent more than 64 different sanitizer checks, NFC.

jyknight added a comment. The intricate initialization-order workarounds apparently don't work in all build modes, so I've updated this code to have constexpr functions and initializations in r355278. Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57914/new/ http

[PATCH] D58154: Add support for -fpermissive.

jyknight added a comment. Hm -- in GCC, -fpermissive has nothing at all to do with -pedantic/-pedantic-errors, but I suppose it should be fine to do this way. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58154/new/ https://reviews.llvm.org/D58154 ___

[PATCH] D58154: Add support for -fpermissive.

jyknight added a comment. The errors disabled by this feature are default-error warnings -- you can already get the same effect by using -Wno-. Why is it bad to additionally allow -fpermissive to disable them? (If we have any diagnostics which are currently default-on-warnings which should not

<    1   2   3   4   5   6   7   8   9   >