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

jyknight added a comment. In https://reviews.llvm.org/D34158#827178, @joerg wrote: > I had a long discussion with James about this on IRC without reaching a clear > consensus. I consider forcing this behavior on all targets to be a major bug. > It should be opt-in and opt-in only: > > (1) The h

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

jyknight added a comment. Just to restate: the ideal outcome of this discussion for me would be to resolve things such that _ALL_ libc implementations will feel comfortable using this technique to provide the C11-required predefined macros. I'd love for linux, freebsd, macos, solaris, etc etc l

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

jyknight added a comment. In https://reviews.llvm.org/D34158#838454, @mibintc wrote: > This patch is responding to @jyknight 's concern about preprocessed input. > The patch as it stands doesn't have this issue. I added 2 test cases, one > using option -x cpp-output, and another for a source fi

[PATCH] D69876: Allow output constraints on "asm goto"

jyknight accepted this revision. jyknight added a comment. LGTM modulo some minor wording. Comment at: clang/docs/LanguageExtensions.rst:1256-1258 +Clang provides support for the `goto form of GCC's extended +assembly`_ with

[PATCH] D71848: Allow the discovery of Android NDK's triple-prefixed binaries.

jyknight added inline comments. Comment at: clang/lib/Driver/Driver.cpp:4696 + llvm::Triple ToolchainTriple = TC.getTriple(); + if (ToolchainTriple.isAndroid()) { +std::string ArchName = ToolchainTriple.getArchName(); Adding the hardcoding here seems unfort

[PATCH] D69876: Allow output constraints on "asm goto"

jyknight added a comment. I think you pushed the incorrect change? This was the clang half, but now it's showing the LLVM half. Can you re-upload the diff for the clang half? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69876/new/ https://reviews

[PATCH] D69876: Allow output constraints on "asm goto"

jyknight added inline comments. Comment at: clang/lib/AST/Stmt.cpp:646-648 + // Labels are placed after "InOut" operands. Adjust accordingly. + if (IsLabel) +N += getNumPlusOperands(); void wrote: > jyknight wrote: > > I'm confused about this pa

[PATCH] D69876: Allow output constraints on "asm goto"

jyknight reopened this revision. jyknight added a comment. This revision is now accepted and ready to land. Reopening, since this didn't actually land yet. BTW, this review still has the wrong contents in the latest uploaded-diff (showing llvm changes, not clang changes). Repository: rG LLVM

[PATCH] D69868: Allow "callbr" to return non-void values

jyknight added inline comments. Comment at: llvm/lib/CodeGen/MachineVerifier.cpp:701 + } else if (MBB->succ_size() == LandingPadSuccs.size() || + MBB->succ_size() == IndirectPadSuccs.size()) { // It's possible that the block legitimately ends with a

[PATCH] D69868: Allow "callbr" to return non-void values

jyknight added inline comments. Comment at: llvm/lib/CodeGen/MachineVerifier.cpp:701 + } else if (MBB->succ_size() == LandingPadSuccs.size() || + MBB->succ_size() == IndirectPadSuccs.size()) { // It's possible that the block legitimately ends with a

[PATCH] D71848: Allow the discovery of Android NDK's triple-prefixed binaries.

jyknight added a comment. Since this change is not android-only, please update change description, and update some non-android tests. E.g. maybe the tests in clang/test/Driver/linux-ld.c for ubuntu_14.04_multiarch_tree should check the path at which ld is found. While the existing Inputs/ubunt

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

jyknight added inline comments. Herald added a project: clang. Comment at: lib/Headers/__stddef_max_align_t.h:44 +#endif } max_align_t; #endif EricWF wrote: > rsmith wrote: > > I don't want to hold up the immediate fix in this patch for this, but... we > > sho

[PATCH] D67847: [Support] make report_fatal_error `abort` instead of `exit`

jyknight added a comment. In D67847#1693694 , @rnk wrote: > In D67847#1691898 , @jyknight wrote: > > > The `abort()` function raises SIGABRT, for which the default behavior is to > > trigger a coredump. Do we actua

[PATCH] D86881: Make -fvisibility-inlines-hidden apply to static local variables in inline functions on Darwin

jyknight added a comment. But this (re-)breaks the functionality of -fvisibility-inlines-hidden on Darwin. That seems bad? I'd've liked to see more of an explanation as to why this was considered a necessary breakage. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://r

[PATCH] D86790: [FE] Use preferred alignment instead of ABI alignment for complete object when applicable

jyknight added inline comments. Comment at: clang/include/clang/AST/ASTContext.h:256 - /// A cache from types to size and alignment information. using TypeInfoMap = llvm::DenseMap; + /// A cache from types to size and ABI-specified alignment information. P

[PATCH] D86790: [FE] Use preferred alignment instead of ABI alignment for complete object when applicable

jyknight added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:4539 CharUnits CCAlign = getParamTypeAlignment(Ty); CharUnits TyAlign = getContext().getTypeAlignInChars(Ty); Xiangling_L wrote: > jasonliu wrote: > > Question: > > It looks

[PATCH] D86790: [FE] Use preferred alignment instead of ABI alignment for complete object when applicable

jyknight added a comment. I'm happy with this now, but please update the commit message to match the updated change. Comment at: clang/include/clang/AST/ASTContext.h:2177-2179 /// This can be different than the ABI alignment in cases where it is - /// beneficial for perfor

[PATCH] D86790: [FE] Use preferred alignment instead of ABI alignment for complete object when applicable

jyknight added inline comments. Comment at: clang/lib/CodeGen/TargetInfo.cpp:4539 CharUnits CCAlign = getParamTypeAlignment(Ty); CharUnits TyAlign = getContext().getTypeAlignInChars(Ty); efriedma wrote: > jyknight wrote: > > Xiangling_L wrote: > > > j

[PATCH] D88195: Remove stale assert.

jyknight added inline comments. Comment at: clang/test/Modules/Inputs/asm-goto/a.h:4-6 + asm goto("xor $0, $0\n\t" + "test $0, $0\n\t" + "jne $l1\n\t" An empty asm string will suffice for the test. Comment at: clang/test/Mo

[PATCH] D88195: Remove stale assert.

jyknight added inline comments. Comment at: clang/test/Modules/asm-goto.cpp:1 +// RUN: rm -rf %t +// RUN: %clang_cc1 -fmodules -fno-implicit-modules -x c++ -I%S/Inputs/asm-goto -emit-module %S/Inputs/asm-goto/module.modulemap -fmodule-name=a -o %t/a.pcm void wro

[PATCH] D88195: Remove stale assert.

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. In D88195#2293597 , @nickdesaulniers wrote: > In D88195#2293589 , @void wrote: > >> Clarify commit message

[PATCH] D82777: Clang Driver: Use Apple ld64's new @response-file support.

jyknight added a comment. BTW, to the apple folks here, it'd sure be awesome if this could be backported into XCode 12's clang. :) (c.f. FB7037642). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82777/new/ https://reviews.llvm.org/D82777

[PATCH] D86855: Convert __m64 intrinsics to unconditionally use SSE2 instead of MMX instructions.

jyknight created this revision. jyknight added reviewers: craig.topper, spatel, RKSimon. Herald added subscribers: cfe-commits, danielkiss. Herald added a project: clang. jyknight requested review of this revision. Preliminary patch, posted to go along with discussion on llvm-dev. 3DNow! intrinsi

[PATCH] D86790: [FE] Use preferred alignment instead of ABI alignment for complete object when applicable

jyknight added a comment. Do you have open questions on whether some callsites passing "false" here, should be switched to true? Given what's here, I would say that it definitely does not makes sense to add this parameter everywhere. So, for getting something committed: please send a new review

[PATCH] D91311: Add new 'preferred_name' attribute.

jyknight added inline comments. Comment at: clang/include/clang/Basic/Attr.td:2384 + let Spellings = [Clang<"preferred_name", /*AllowInC*/0>]; + let Subjects = SubjectList<[ClassTmpl]>; + let Args = [TypeArgument<"TypedefType">]; I wonder if this attribute oug

[PATCH] D92662: [Clang][Coroutine] Drop const attribute on pthread_self when coroutine is enabled

jyknight added a comment. I don't think we should change the meaning of `__attribute__((const))` to exclude depending on thread-id. However, if we do want to do so, and call the existing uses of `__attribute__((const))` in glibc invalid, we need to special case many more functions. Looking thr

[PATCH] D93072: Fix PR35902: incorrect alignment used for ubsan check.

jyknight created this revision. jyknight added reviewers: rsmith, rnk. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. UBSan was using the complete-object align rather than nv alignment when checking the "this" pointer of a method.

[PATCH] D91157: [AArch64] Out-of-line atomics (-moutline-atomics) implementation.

jyknight added inline comments. Comment at: llvm/docs/Atomics.rst:625 + +Libcalls: out-of-line atomics += I think this section needs to be put on the end of the section on `__sync_*`. These functions are effectively an aarch64-specifi

[PATCH] D91157: [AArch64] Out-of-line atomics (-moutline-atomics) implementation.

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. LG after fixing the minor nits. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:6377 +} else { + CmdArgs.push_back("-target-feature"); + CmdArgs.push_back

[PATCH] D88659: [FE]Split SuitableAlign into two parts

jyknight added a comment. Hm, to start with, the current state of this confuses me. In GCC, the preprocessor macro `__BIGGEST_ALIGNMENT__` was supposed to expose the alignment used by `__attribute__((aligned))` (no arg specified), as well the alignment used for alloca. However, this is no longe

[PATCH] D88659: [FE]Split SuitableAlign into two parts

jyknight added a comment. > As you mentioned, without this patch, `SuitableAlign` is used for the > predefined `__BIGGEST_ALIGNMENT__` and alignment for alloca. But on AIX, the > __BIGGEST_ALIGNMENT__ should be 8bytes, alloca and > `__attribute__((aligned))` should align to 16bytes considerin

[PATCH] D88659: [FE]Split SuitableAlign into two parts

jyknight added a comment. In D88659#2319636 , @hubert.reinterpretcast wrote: > In D88659#2318203 , @jyknight wrote: > >> It seems like on AIX, `__BIGGEST_ALIGNMENT__` should just be set to 16, >> then. I'm not sur

[PATCH] D88659: [FE]Split SuitableAlign into two parts

jyknight added a comment. In D88659#2339357 , @Xiangling_L wrote: > Hi @jyknight , are you okay with us changing the "definition" of > SuitableAlign without sending a note to the mailing list? Yes, I think that it is fine to adjust the comment just in th

[PATCH] D71726: Let clang atomic builtins fetch add/sub support floating point types

jyknight added a comment. In D71726#2207700 , @yaxunl wrote: > clang does not always emit atomic instructions for atomic builtins. Clang may > emit lib calls for atomic builtins. Basically clang checks target info about > max atomic inline width and if t

[PATCH] D93922: Mangle `__alignof__` differently than `alignof`.

jyknight updated this revision to Diff 318277. jyknight marked 8 inline comments as done. jyknight added a comment. Address comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93922/new/ https://reviews.llvm.org/D93922 Files: clang/lib/AST/I

[PATCH] D93922: Mangle `__alignof__` differently than `alignof`.

jyknight added inline comments. Comment at: clang/lib/AST/ItaniumMangle.cpp:4010 +if (Context.getASTContext().getLangOpts().getClangABICompat() >= +LangOptions::ClangABI::Ver11) { + Out << "u8__uuidof"; rsmith wrote: > Should this be `>= Ver12` /

[PATCH] D93922: Itanium Mangling: Mangle `__alignof__` differently than `alignof`.

jyknight updated this revision to Diff 319422. jyknight retitled this revision from "Mangle `__alignof__` differently than `alignof`." to "Itanium Mangling: Mangle `__alignof__` differently than `alignof`.". jyknight added a comment. Minor updates. Repository: rG LLVM Github Monorepo CHANGE

[PATCH] D95487: Itanium Mangling: Fix handling of in .

jyknight created this revision. Herald added a subscriber: kristof.beyls. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Previously, we were emitting an extraneous X .. E in around an if the template argument was constructed fro

[PATCH] D95488: Itanium Mangling: In 'enable_if', omit X/E around .

jyknight created this revision. jyknight added reviewers: rsmith, rjmccall. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. The Clang enable_if extension is mangled as an , which is supposed to contain . However, we were unconditio

[PATCH] D93922: Itanium Mangling: Mangle `__alignof__` differently than `alignof`.

jyknight added a comment. OK, I've posted two follow-up changes now. https://reviews.llvm.org/D95487 fixes the issue with mangleTemplateArg given expressions -- this turned out to be a larged-scoped problem than I had thought, affecting manglings other than just that used the matrix extension.

[PATCH] D95487: Itanium Mangling: Fix handling of in .

jyknight added inline comments. Comment at: clang/lib/AST/ItaniumMangle.cpp:3912 +IsPrimaryExpr = false; + }; + rjmccall wrote: > I think it might be more reasonable to just check for the relatively small > number of primary-expression cases in `mangleTempl

[PATCH] D95488: Itanium Mangling: In 'enable_if', omit X/E around .

jyknight updated this revision to Diff 319578. jyknight added a comment. Add neglected clang-abi-compat.cpp change. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D95488/new/ https://reviews.llvm.org/D95488 Files: clang/lib/AST/ItaniumMangle.cpp

[PATCH] D95487: Itanium Mangling: Fix handling of in .

jyknight added inline comments. Comment at: clang/lib/AST/ItaniumMangle.cpp:3912 +IsPrimaryExpr = false; + }; + jyknight wrote: > rjmccall wrote: > > I think it might be more reasonable to just check for the relatively small > > number of primary-expression

[PATCH] D95487: Itanium Mangling: Fix handling of in .

jyknight added inline comments. Comment at: clang/lib/AST/ItaniumMangle.cpp:5145 + ASTContext &Ctx = Context.getASTContext(); + if (Ctx.getLangOpts().getClangABICompat() > LangOptions::ClangABI::Ver11) { +mangleExpression(E, UnknownArity, /*AsTemplateArg=*/true); --

[PATCH] D93922: Itanium Mangling: Mangle `__alignof__` differently than `alignof`.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG9c7aeaebb3ac: Itanium Mangling: Mangle `__alignof__` differently than `alignof`. (authored by jyknight). Repository: rG LLVM Github Monorepo CHAN

[PATCH] D95487: Itanium Mangling: Fix handling of in .

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG8ca33605ff0c: Itanium Mangling: Fix handling of in . (authored by jyknight). Changed prior to commit: https://reviews

[PATCH] D95488: Itanium Mangling: In 'enable_if', omit X/E around .

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGa7246ba02a89: Itanium Mangling: In 'enable_if', omit X/E around . (authored by jyknight). Repository: rG LLVM Github Monorepo CHANG

[PATCH] D71726: Let clang atomic builtins fetch add/sub support floating point types

jyknight added a comment. I still have the same fundamental objection as before to the parts of this patch for prohibiting FP add/sub on some targets. If a particular LLVM target cannot handle transforming an FP add/sub (or any other RMW operations!) into the correct cmpxchg or LL/SC loop, that

[PATCH] D71726: Let clang atomic builtins fetch add/sub support floating point types

jyknight added a comment. My concern is that this is treating a backend _bug_ as if it were just an optional feature. But it's not the case that it might be reasonable to either implement or not implement this in a backend -- it should be implemented, and those that don't are buggy. I'd be hap

[PATCH] D71726: Let clang atomic builtins fetch add/sub support floating point types

jyknight added a comment. In D71726#2537101 , @yaxunl wrote: > For amdgpu target, we do need diagnose unsupported atomics (not limited to fp > atomics) since we do not support libcall due to ISA level linking not > supported. This is something we cannot

[PATCH] D96044: DebugInfo: Emit "LocalToUnit" flag on local member function decls.

jyknight created this revision. jyknight added a reviewer: dblaikie. Herald added a subscriber: inglorion. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Previously, the definition was so-marked, but the declaration was not. This

[PATCH] D92808: [ObjC][ARC] Use operand bundle 'clang.arc.attachedcall' instead of explicitly emitting retainRV or claimRV calls in the IR

jyknight added a comment. > I ended up reverting the changes I made to llvm/lib/IR/AutoUpgrade.cpp as the > file was including llvm/Analysis/ObjCARCUtil.h, which was violating layering. It looks like it was not actually reverted in the version ultimately submitted. I've pushed commit 3c06676de1

[PATCH] D97223: Add Alignment argument to IRBuilder CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight created this revision. jyknight added reviewers: gchatelet, jfb, rjmccall. Herald added subscribers: teijeong, dexonsmith, rdzhabarov, tatianashp, msifontes, jurahul, Kayjukh, grosul1, Joonsoo, liufengdb, aartbik, lucyrfox, mgester, arpith-jacob, antiagainst, shauheen, rriddle, mehdi_ami

[PATCH] D97224: Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight created this revision. jyknight added reviewers: gchatelet, jfb, rjmccall. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Following the LLVM change to add an alignment argument to the IRBuilder calls, switch Clang's CGBui

[PATCH] D94213: Clang: Remove support for 3DNow!, both intrinsics and builtins.

jyknight added a comment. Herald added a subscriber: jansvoboda11. Ping. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D94213/new/ https://reviews.llvm.org/D94213 ___ cfe-commits mailing list cfe-commits@

[PATCH] D94252: Delete (most) of the MMX builtin functions from Clang.

jyknight added a comment. Ping. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D94252/new/ https://reviews.llvm.org/D94252 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi

[PATCH] D86855: Convert __m64 intrinsics to unconditionally use SSE2 instead of MMX instructions.

jyknight added a comment. Ping. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86855/new/ https://reviews.llvm.org/D86855 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi

[PATCH] D96044: DebugInfo: Emit "LocalToUnit" flag on local member function decls.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGfe2dcd89acfd: DebugInfo: Emit "LocalToUnit" flag on local member function decls. (authored by jyknight). Repository: rG LLVM Github Monorepo CHAN

[PATCH] D97223: Add Alignment argument to IRBuilder CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight added a comment. In D97223#2581126 , @rjmccall wrote: > Looks like you didn't update the .bc reader/writer and the .ll printer/parser. The instructions already had alignment support added to the type constructor and IR/BC in prior changes by gch

[PATCH] D97324: [NFC] Make TrailingObjects non-copyable/non-movable

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. I can imagine there being some cases where these could theoretically be useful. But if you've tested this change and it doesn't cause build failures with any existing uses of TrailingObjec

[PATCH] D103495: [static initializers] Emit global_ctors and global_dtors in reverse order when init_array is not used.

jyknight added a comment. Won't this change cause weird effects with LTO, when you're merging multiple TUs' global_ctors arrays before emitting? Won't this end up reversing the order of the files, as well as the order of the functions within a single file? That does not seem likely to be expect

[PATCH] D103987: Start tracking Clang's C implementation status

jyknight accepted this revision. jyknight added a comment. This revision is now accepted and ready to land. Sounds like a great plan to me. I might suggest adding some text about the page being incomplete, so that people don't wonder if the blank sections for pre-C2x are a bug. Repository: r

[PATCH] D97224: Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight added a comment. Ping. I think this is correct, and would like to commit. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97224/new/ https://reviews.llvm.org/D97224 ___ cfe-commits mailing list cf

[PATCH] D106577: [clang] Define __STDC_ISO_10646__

jyknight added a comment. In D106577#2904960 , @rsmith wrote: >> One specific example I'd like to be considered: >> Suppose the C standard library implementation's mbstowcs converts a certain >> multi-byte character C to somewhere in the Unicode private

[PATCH] D58514: Avoid needlessly copying blocks that initialize or are assigned to local auto variables to the heap

jyknight added a comment. It appears as though this commit was reverted in Apple's XCode Clang fork -- the behavior currently in XCode matches the behavior of upstream Clang prior to this patch. Presuming that's correct, I think we should revert this upstream as well. There doesn't seem to be a

[PATCH] D108243: Revert "Avoid needlessly copying a block to the heap when a block literal"

jyknight created this revision. jyknight added reviewers: ahatanak, erik.pilkington, rjmccall. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. It has been reverted in Apple's Clang fork for quite some time, possibly ever since it w

[PATCH] D58514: Avoid needlessly copying blocks that initialize or are assigned to local auto variables to the heap

jyknight added a comment. I've gone ahead and created a revert review: https://reviews.llvm.org/D108243 Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58514/new/ https://reviews.llvm.org/D58514 ___ cfe-commits mailing l

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

jyknight added a comment. This code doesn't handle multiple alternatives in a constraint. E.g. `"={eax}{ebx}"` or `"={eax}{ebx},m"`. See the GCC docs for the C-level syntax https://gcc.gnu.org/onlinedocs/gcc/Multi-Alternative.html#Multi-Alternative and LLVM IR docs for the IR syntax: https://llv

[PATCH] D104500: [clang] Apply P1825 as Defect Report from C++11 up to C++20.

jyknight added a comment. This commit seems to have broken libc++ in C++98 mode, as it appears to have depended upon the implicit-move extension. Reproduction is simple. Build this with `-stdlib=libc++ -std=c++98`: #include void foo (std::set *s) { s->insert(5); } (https://godbolt.

[PATCH] D103465: [OpaquePtr] Track pointee types in Clang

jyknight added inline comments. Comment at: clang/lib/CodeGen/Address.h:26 llvm::Value *Pointer; + llvm::Type *PointeeType; CharUnits Alignment; erichkeane wrote: > I think this will still end up being a problem when we try to look into the > type for mul

[PATCH] D112400: [clang][compiler-rt][atomics] Add `__c11_atomic_fetch_nand` builtin and support `__atomic_fetch_nand` libcall

jyknight added inline comments. Comment at: compiler-rt/lib/builtins/atomic.c:339 +#define ATOMIC_RMW_NAND(n, lockfree, type) \ + type __atomic_fetch_nand_##n(type *ptr, type val, int model) { \ Same as ATOMI

[PATCH] D113517: Correct handling of the 'throw()' exception specifier in C++17.

jyknight created this revision. jyknight added a reviewer: aaron.ballman. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Per C++17 [except.spec], 'throw()' has become equivalent to 'noexcept', and should therefore call std::termin

[PATCH] D113517: Correct handling of the 'throw()' exception specifier in C++17.

jyknight added a comment. In D113517#3120030 , @rsmith wrote: > What's the motivation for this change? I believe the current behavior is > still conforming: `set_unexpected` is no longer (officially) part of the > standard library (though it still exist

[PATCH] D113517: Correct handling of the 'throw()' exception specifier in C++17.

jyknight added a comment. In D113517#3122217 , @rsmith wrote: > In D113517#3121455 , @jyknight > wrote: > >> This change allows those future optimizations to apply to throw() as well, >> in C++17 mode, which is

[PATCH] D113517: Correct handling of the 'throw()' exception specifier in C++17.

This revision was automatically updated to reflect the committed changes. Closed by commit rGfddc4e41164e: Correct handling of the 'throw()' exception specifier in C++17. (authored by jyknight). Changed prior to commit: https://reviews.llvm.org/D113517?vs=385971&id=386326#toc Repository: rG

[PATCH] D97223: Add Alignment argument to IRBuilder CreateAtomicRMW and CreateAtomicCmpXchg.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG24539f1ef247: Add Alignment argument to IRBuilder CreateAtomicRMW and CreateAtomicCmpXchg. (authored by jyknight). Herald added a subscriber: cota.

[PATCH] D97223: Add Alignment argument to IRBuilder CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight added inline comments. Comment at: llvm/lib/CodeGen/AtomicExpandPass.cpp:1037 + assert(AddrAlign >= ResultTy->getPrimitiveSizeInBits() / 8 && + "Expected at least natural alignment at this point."); jrtc27 wrote: > Doesn't this introduce anoth

[PATCH] D97224: Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight updated this revision to Diff 328219. jyknight marked 2 inline comments as done. jyknight added a comment. Address review comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97224/new/ https://reviews.llvm.org/D97224 Files: clang/li

[PATCH] D97224: Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight added a comment. In D97224#2596410 , @rjmccall wrote: > Do we really consider the existing atomic intrinsics to not impose added > alignment restrictions? I'm somewhat concerned that we're going to produce > IR here that's either really subopti

[PATCH] D97224: Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight added a comment. > The idea here is not to "ignore type alignment". `EmitPointerWithAlignment` > will sometimes return an alignment for a pointer that's less than the > alignment of the pointee type, e.g. because you're taking the address of a > packed struct field. The critical ques

[PATCH] D86855: Convert __m64 intrinsics to unconditionally use SSE2 instead of MMX instructions.

jyknight added a comment. Ping, thanks! Or, if you have suggestions on how to make it easier to review, I'd be open to that. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86855/new/ https://reviews.llvm.org/D86855 ___

[PATCH] D97224: Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight updated this revision to Diff 330088. jyknight added a comment. Use natural alignment for `_Interlocked*` intrinsics. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97224/new/ https://reviews.llvm.org/D97224 Files: clang/lib/CodeGen/CGAt

[PATCH] D97224: Use Address for CGBuilder's CreateAtomicRMW and CreateAtomicCmpXchg.

jyknight added a comment. In D97224#2621328 , @rjmccall wrote: > In D97224#2604537 , @jyknight wrote: > >>> I'm less certain about what to do with the `__atomic_*` builtins >> >> The `__atomic` builtins have already

[PATCH] D100879: [Clang] Propagate guaranteed alignment for malloc and others

jyknight added a comment. I think this patch was wrong -- we should not be assuming 16-byte alignment for an allocation smaller than 16 bytes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100879/new/ https://reviews.llvm.org/D100879

[PATCH] D136707: [clang][Toolchains][Gnu] pass -gdwarf-* through to assembler

jyknight added a comment. This change has caused `clang -Wall -fdebug-default-version=5 -c -xc /dev/null -o /dev/null` to print the following warning, because it has moved the read of the argument into a conditional. `clang: warning: argument unused during compilation: '-fdebug-default-version=

[PATCH] D129833: Use @llvm.threadlocal.address intrinsic to access TLS

jyknight added a comment. Note that this change caused LLVM to no longer be aware that a TLS variable cannot be NULL. Thus, code like: __thread int x; int main() { int* y = &x; return *y; } built with `clang -O -fsanitize=null` emits a null-pointer check, when it wouldn't previou

[PATCH] D134550: [Clang] Make Clang driver suggest '-Xclang' for CC1 options passed to the driver

jyknight added a comment. I //really// don't think we should have this behavior. The cc1 options are supposed to be an internal implementation detail. It's already a problem that the option name doesn't shout "hey I'm an internal interface with no stability guarantees! Don't use me!". Having cl

[PATCH] D134550: [Clang] Make Clang driver suggest '-Xclang' for CC1 options passed to the driver

jyknight added a comment. In D134550#3813269 , @aaron.ballman wrote: > Alternatively, perhaps those experimental options should be exposed from the > driver instead of being a cc1-only flag? IMO: yes. If we want end-users to use a particular flag, we s

[PATCH] D142925: [Clang] Improve error message for violations of -fmodules-decluse.

jyknight created this revision. jyknight added a reviewer: ChuanqiXu. Herald added a project: All. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Now it reports the name of the indirectly-used module which is missing. Repository

[PATCH] D142925: [Clang] Improve error message for violations of -fmodules-decluse.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGab0116e2f05c: [Clang] Improve error message for violations of -fmodules-decluse. (authored by jyknight). Repository: rG LLVM Github Monorepo CHAN

[PATCH] D127545: Remove Itanium EH ABI workaround to allow modifying a pointer caught by-reference.

jyknight created this revision. jyknight added reviewers: rjmccall, nikic. Herald added a project: All. jyknight requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Pointers will now always be caught by-value. The workaround was originally add

[PATCH] D127545: Remove Itanium EH ABI workaround to allow modifying a pointer caught by-reference.

jyknight added a comment. (Note: if folks agree with this direction, I'll file a new bug for the newly broken behavior -- even though we probably cannot actually fix it -- and link it from the commit.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/

[PATCH] D125814: Improve the strict prototype diagnostic behavior

jyknight added a comment. Good improvement, but an additional change to wording for just the zero-arg non-prototype function declaration case could help a lot. The fact that zero-arg it's only being warned about because of the "...because of" note isn't particularly clear -- especially when the

[PATCH] D126324: [clang] Allow const variables with weak attribute to be overridden

jyknight added a comment. In D126324#3536785 , @aaron.ballman wrote: > The changes so far look sensible, but I think we should add some more tests > for a few situations. 1) Using a const weak symbol as a valid initializer > should be diagnosed (with a

[PATCH] D125814: Improve the strict prototype diagnostic behavior

jyknight accepted this revision. jyknight added inline comments. This revision is now accepted and ready to land. Comment at: clang/lib/Sema/SemaDecl.cpp:3959 + // it's a user-visible declaration. There is one exception to this: + // when the new declaration is

[PATCH] D126170: C++ DR2394: Const-default-constructible for members.

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG997b072e10d2: C++ DR2394: Const-default-constructible for members. (authored by jyknight). Changed prior to commit: https://reviews.llvm.org/D1261

[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable (1/3)

jyknight added a comment. So, I've been spending some significant time looking into this. I found that I couldn't really review this change for correctness, because I find it basically impossible to figure out whether the intrinsic calls have actually been added to all the right places in Clang

[PATCH] D125919: Drop qualifiers from return types in C (DR423)

jyknight added a comment. In D125919#3556754 , @rsmith wrote: > That assumption does not hold. Given `struct A { char c[3]; };`, `struct A` > has size 3 and align 1, but `_Atomic struct A` has size 4 and align 4 across > many (perhaps all?) of our targe

[PATCH] D153156: [Clang] CWG1473: do not err on the lack of space after operator""

jyknight reopened this revision. jyknight added a comment. This revision is now accepted and ready to land. Reopening the review since it ended up reverted, but I do think we DO want to have at least some of the changes proposed here (and/or from the pending D158372

[PATCH] D156565: Diagnose use of VLAs in C++ by default

jyknight added a comment. Overall looks good, just a few nits from looking things over. Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:143 +def ext_vla_cxx : ExtWarn< + "variable length arrays are a Clang extension">, InGroup; +def ext_vla_cxx_in_gnu_mode : Exten

<    1   2   3   4   5   >