[PATCH] D91944: OpenMP 5.0 metadirective

davezarzycki added a comment. Also, when this lands again, please ensure that all the tests don't accidentally dump build artifacts into the source directory. Specifically, the following test was missing `-o -`: clang/test/OpenMP/metadirective_messages.cpp Repository: rG LLVM Github

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

davezarzycki added a comment. Yes, Fedora 34 (x86-64). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99949/new/ https://reviews.llvm.org/D99949 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

davezarzycki added a comment. It's still failing but I can disable HSA on this machine for now. FYI -- FAILED: tools/clang/tools/amdgpu-arch/CMakeFiles/amdgpu-arch.dir/AMDGPUArch.cpp.o /p/tllvm/bin/clang++ -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

davezarzycki added a comment. I removed all HSA/ROCM via the package manager and everything is fine now. Have you considered using __has_include() instead of CMake? It seems to be supported by all contemporary compilers, even MSVC. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

davezarzycki added a comment. In D99949#2709785 , @JonChesterfield wrote: > It's not obvious to me why any of those stages would get a different result > for the search for rocr. Do you do things with chroot/jails to ensure > isolation for some of

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

davezarzycki added a comment. In D99949#2709673 , @JonChesterfield wrote: > That's interesting. The various permutations I have on disk are also all > path/include/hsa/hsa.h. The existing in tree use of hsa.h is the amdgpu > plugin, which uses

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

davezarzycki added a comment. And if it helps: $ sudo find / -xdev -name hsa.h /usr/include/hsa/hsa.h /opt/rocm-3.10.0/include/hsa/hsa.h /opt/rocm-4.0.0/include/hsa/hsa.h Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99949/new/

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

davezarzycki added a comment. In D99949#2709497 , @JonChesterfield wrote: > In D99949#2709297 , @davezarzycki > wrote: > >> This change broke multi-stage builds (even if AMDGPU is disabled as a >> target). The

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

davezarzycki added a comment. This change broke multi-stage builds (even if AMDGPU is disabled as a target). The problem is that clang/tools/amdgpu-arch/AMDGPUArch.cpp can't find hsa.h. Is there a quick fix? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

davezarzycki added inline comments. Comment at: clang/lib/CodeGen/CGValue.h:18 #include "clang/AST/ASTContext.h" +#include "clang/Sema/Sema.h" #include "clang/AST/Type.h" aaron.ballman wrote: > davezarzycki wrote: > > aaron.ballman wrote: > > > davezarzycki

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

davezarzycki added inline comments. Comment at: clang/lib/CodeGen/CGValue.h:18 #include "clang/AST/ASTContext.h" +#include "clang/Sema/Sema.h" #include "clang/AST/Type.h" aaron.ballman wrote: > davezarzycki wrote: > > aaron.ballman wrote: > > > rnk wrote: > >

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

davezarzycki added inline comments. Comment at: clang/lib/CodeGen/CGValue.h:18 #include "clang/AST/ASTContext.h" +#include "clang/Sema/Sema.h" #include "clang/AST/Type.h" aaron.ballman wrote: > rnk wrote: > > This includes Sema.h into every codegen file that

[PATCH] D93594: [X86] Pass to transform amx intrinsics to scalar operation.

davezarzycki added a comment. In D93594#2606157 , @RKSimon wrote: > @yubing I've reverted this as it was failing on a lot of buildbots: > http://lab.llvm.org:8011/#/builders/109/builds/9867 Thanks – I was just about to point out this broke downstream

[PATCH] D95877: [analyzer] Fix static_cast on pointer-to-member handling

davezarzycki added a comment. The test seems to be broken on Fedora 33 (x86-64 with clang-11): XPASS: Clang :: Analysis/reinterpret-cast-pointer-to-member.cpp (6531 of 74360) TEST 'Clang :: Analysis/reinterpret-cast-pointer-to-member.cpp' FAILED

[PATCH] D91488: Consider reference, pointer, and pointer-to-membber TemplateArguments to be different if they have different types.

davezarzycki added a comment. Thanks. I just verified that reverting this change fixes the second stage regression and was about to commit the revert. @rsmith – If you need help testing a fix, please let me know. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D91488: Consider reference, pointer, and pointer-to-membber TemplateArguments to be different if they have different types.

davezarzycki added a comment. This change is causing second stage build failures on Fedora 33 (x86-64). I'll probably revert this soon, but in the mean time, here is a snippet of the build output: FAILED: lib/ExecutionEngine/JITLink/CMakeFiles/LLVMJITLink.dir/JITLinkGeneric.cpp.o

[PATCH] D92028: Fix driver test from e16c0a9a689719

davezarzycki added a comment. This is breaking building on Fedora 33 (x86-64). Can we revert this or get a quick fix? -- Exit Code: 1 Command Output (stdout): -- "/tmp/_update_lc/r/bin/ld64.lld" "-demangle" "-dynamic" "-arch" "i386" "-macosx_version_min" "10.5.0" "-o"

[PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

davezarzycki added a comment. I think I fixed it. Please verify: 87f6de72bcd346bbbf468e9f9a0e9d1bbf0630a9 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89500/new/ https://reviews.llvm.org/D89500 ___

[PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

davezarzycki added a comment. A git bisect run blamed this patch for breaking the ability to build with a read-only source tree. Can we revert this or make a quick fix? FAIL: Clang :: CodeGen/basic-block-sections.c (3385 of 26774) TEST 'Clang ::

[PATCH] D84013: Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)

davezarzycki added a comment. Not fighting with how `lit`, `FileCheck`, and shell input/output work would help here: FAIL: Clang :: Modules/ModuleDebugInfoDwoId.cpp (1 of 1) TEST 'Clang :: Modules/ModuleDebugInfoDwoId.cpp' FAILED Script: -- :

[PATCH] D84013: Correctly emit dwoIDs after ASTFileSignature refactoring (D81347)

davezarzycki added a comment. I have an auto-bisecting cron job that has identified the "reland" as breaking the test suite on Fedora 32 (x86). Is there a quick fix or can we revert the reland? FAIL: Clang :: Modules/ModuleDebugInfoDwoId.cpp (12657 of 68968) TEST

[PATCH] D82822: [OpenMP][FIX] Consistently use OpenMPIRBuilder if requested

davezarzycki added a comment. Hello, I have a twice-daily auto-bisecting multi-stage cron job running on Fedora 32 (x86-64) that has identified this commit as failing my first stage test (release + no asserts). Is this expected? Can we get a quick fix or revert this? FAIL: Clang ::

[PATCH] D81728: [InstCombine] Add target-specific inst combining

davezarzycki added a comment. I have a multi-stage, auto-git-bisecting bot that has identifying this commit as the source of a regression on Fedora 32 (x86-64). This commit broke my first stage test (release, no asserts). Might a quick fix happen or do we need to revert this? FAIL: Clang ::

[PATCH] D82085: [TRE] allow TRE for non-capturing calls.

davezarzycki added a comment. Hello. I have an auto-bisecting multi-stage bot that is failing on two after this change. Can we please revert this or commit a quick fix? FAIL: Clang :: CXX/class/class.compare/class.spaceship/p1.cpp (6232 of 64222) TEST 'Clang ::

[PATCH] D82259: Deprecate error prone temporary directory APIs

davezarzycki abandoned this revision. davezarzycki added a comment. Now that my core concern is addressed (moving clang's default module cache out of /tmp), I don't have the time to push for this deprecation. Sorry. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D82362: Move default module cache from system temporary directory

This revision was automatically updated to reflect the committed changes. Closed by commit rGbb26838ceffb: [clang driver] Move default module cache from system temporary directory (authored by davezarzycki). Changed prior to commit: https://reviews.llvm.org/D82362?vs=272655=273674#toc

[PATCH] D82362: Move default module cache from system temporary directory

davezarzycki marked an inline comment as done. davezarzycki added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:3253 + CmdArgs.push_back(Args.MakeArgString(Path)); +} } sammccall wrote: > what happens in the else case? No module

[PATCH] D82362: Move default module cache from system temporary directory

davezarzycki created this revision. davezarzycki added reviewers: compnerd, aprantl, jakehehrlich, espindola, respindola, ilya-biryukov, pcc, sammccall. davezarzycki added projects: clang, LLVM. Herald added a subscriber: hiraditya. 1. Shared writable directories like /tmp are a security

[PATCH] D82259: Deprecate error prone temporary directory APIs

davezarzycki updated this revision to Diff 272661. davezarzycki added a comment. Herald added a project: LLDB. Herald added a subscriber: lldb-commits. Moved clang specific changes to: https://reviews.llvm.org/D82362 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D82259: Deprecate error prone temporary directory APIs

davezarzycki updated this revision to Diff 272434. davezarzycki added a comment. 1. Respect Darwin and XDG cache directories. 2. Drop atypical reverse DNS in the path. 3. Make clang more robust if the default module path cannot be determined. Repository: rG LLVM Github Monorepo CHANGES SINCE

[PATCH] D82259: Deprecate error prone temporary directory APIs

davezarzycki added a comment. Sure, we can honor XDG_CACHE_DIR. Maybe as a followup, somebody can wire up Darwin's cache directory (which is retrievable via a BSD specific `confstr()` API with `_CS_DARWIN_USER_CACHE_DIR`). I'm not sure about other platforms. I'll wait for more feedback before

[PATCH] D82259: Deprecate error prone temporary directory APIs

davezarzycki created this revision. davezarzycki added reviewers: compnerd, aprantl, jakehehrlich, espindola, respindola, ilya-biryukov, pcc, sammccall. davezarzycki added a project: LLVM. Herald added subscribers: cfe-commits, hiraditya. Herald added a project: clang. Naive usage of shared

[PATCH] D79673: Allow 32-bit pointer extensions to be used without -fms-extensions

davezarzycki abandoned this revision. davezarzycki added a comment. I'm going to abandon this change for now. The problem is that the MS extensions are not as pervasive through the language as I wanted. For example, I'd really like them to work on aggregate types. This would allow all of the

[PATCH] D79673: Allow 32-bit pointer extensions to be used without -fms-extensions

davezarzycki added a comment. In D79673#2028204 , @rnk wrote: > Needs a test. > > I believe these are only implemented for x86 in LLVM. What happens if you try > to use this on non-x86? I wouldn't be surprised if we crash, but we should > probably

[PATCH] D79673: Allow 32-bit pointer extensions to be used without -fms-extensions

davezarzycki created this revision. davezarzycki added reviewers: akhuang, rnk, rsmith. davezarzycki added a project: clang. Herald added a reviewer: aaron.ballman. One should not need to use `-fms-extensions` in order to use 32-bit pointers on 64-bit platforms. Repository: rG LLVM Github

[PATCH] D75068: libclang: Add static build support for Windows

davezarzycki added a comment. In D75068#2004885 , @cristian.adam wrote: > In D75068#2004072 , @davezarzycki > wrote: > > > Rather than wholly reverting this, I committed a fix: > >

[PATCH] D75068: libclang: Add static build support for Windows

davezarzycki added a comment. Rather than wholly reverting this, I committed a fix: 665471907a5c072c6653a38c35f35e5d54cef220 The problem is that "NOT LIBCLANG_BUILD_STATIC" does not imply PIC, so there is no point in trying

[PATCH] D75068: libclang: Add static build support for Windows

davezarzycki added a comment. This breaks building libclang on Fedora 32 with clang 10.0 and lld 10.0. Do you mind if I revert this tomorrow if a quick fix cannot be found? Here is the relevant diagnostics: FAILED: lib64/libclang.so.11 : && /usr/bin/clang++ -fPIC -Werror=switch -stdlib=libc++

[PATCH] D74298: Honor -finline-functions and -finline-hint-functions at -O0

davezarzycki abandoned this revision. davezarzycki added a comment. I'm abandoning this due to lack of time and the problem being more involved than I thought. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74298/new/

[PATCH] D74298: Honor -finline-functions and -finline-hint-functions at -O0

davezarzycki added a comment. Hi @MaskRay – I was just looking at the source history. I didn't test the old way. As it turns out there isn't a regression, but just some unexplained code in the current clang option parsing. And the `-disable-O0-optnone` is a useful hint. Thanks! I've been

[PATCH] D74298: Honor -finline-functions and -finline-hint-functions at -O0

davezarzycki added a comment. Hi @lebedev.ri – Before I add a small new test file, is there an existing one that you know of that would be good to extend? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D74298/new/ https://reviews.llvm.org/D74298

[PATCH] D74298: Honor -finline-functions and -finline-hint-functions at -O0

davezarzycki created this revision. davezarzycki added a reviewer: chandlerc. davezarzycki added a project: clang. This fixes a regression introduced (over three years ago!) by fcd33149b48885ab8e4ca4ffb6977bce5be2e623. Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D74298

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

This revision was automatically updated to reflect the committed changes. Closed by commit rG0d61cd25a692: Verify that clangs max alignment is = LLVMs max alignment (authored by davezarzycki). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73363/new/

[PATCH] D73363: Verify that clang's max alignment is <= LLVM's max alignment

davezarzycki created this revision. davezarzycki added a reviewer: lebedev.ri. davezarzycki added projects: LLVM, clang. Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D73363 Files: clang/include/clang/Sema/Sema.h clang/lib/CodeGen/CGValue.h Index:

[PATCH] D72998: [IR] Attribute/AttrBuilder: use Value::MaximumAlignment magic constant

davezarzycki added a comment. I understand not wanting to have trivial dependencies on IR for values like this, but what about creating `llvm/Support/InternalLimits.h` to hold values like this, and then *either* have `llvm::Value::MaximumAlignment` derive from the constant in the new file, or

[PATCH] D71154: Driver: Don't look for libc++ headers in the install directory on Android.

davezarzycki added a comment. Sorry, I had to revert this for breaking things. Please ping me when you have a new patch. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71154/new/ https://reviews.llvm.org/D71154

[PATCH] D71154: Driver: Don't look for libc++ headers in the install directory on Android.

davezarzycki added a comment. Can we revert this? It doesn't seem to work on my Fedora 31 box: FAIL: Clang :: Driver/android-no-installed-libcxx.cpp (9249 of 59761) TEST 'Clang :: Driver/android-no-installed-libcxx.cpp' FAILED Script: -- :

[PATCH] D70157: Align branches within 32-Byte boundary

davezarzycki added a comment. In D70157#1772227 , @annita.zhang wrote: > > > > > >>> Third, I have not see a justification for why complexity for instruction > >>> prefix padding is necessary. All the effected CPUs support multi-byte > >>> nops, so

[PATCH] D70157: Align branches within 32-Byte boundary

davezarzycki added a comment. In D70157#1747640 , @jyknight wrote: > In D70157#1747551 , @davezarzycki > wrote: > > > In D70157#1747510 , @xbolva00 > > wrote: > > > > > >

[PATCH] D70157: Align branches within 32-Byte boundary

davezarzycki added a comment. In D70157#1746793 , @MaskRay wrote: > On x86, the preferred function alignment is 16 > (https://github.com/llvm/llvm-project/blob/arcpatch-D70157/llvm/lib/Target/X86/X86ISelLowering.cpp#L1893), > which is the default

[PATCH] D70157: Align branches within 32-Byte boundary

davezarzycki added a comment. In D70157#1747510 , @xbolva00 wrote: > > Even though core2 isn't affected by the erratum, core2 code can run on CPUs > > that do have the bug (and core2 is a popular target for code that needs to > > run "everywhere"),

[PATCH] D69292: Proposal to add -Wtautological-compare to -Wall

davezarzycki added a comment. Let's just fix the bug: 1d55c9e59ebf3f3ff572d42da433b2f72f1ce900 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69292/new/

[PATCH] D69292: Proposal to add -Wtautological-compare to -Wall

davezarzycki added subscribers: libcxx-commits, davezarzycki. davezarzycki added a comment. This broke the libcxx test suite: FAIL: libc++ :: libcxx/debug/containers/db_sequence_container_iterators.multithread.pass.cpp (50769 of 59296) TEST 'libc++ ::

[PATCH] D69841: Target Ivy bridge on macOS Mojave and later

davezarzycki abandoned this revision. davezarzycki added a comment. Okay. I'm going to abandon this patch on the assumption that Apple has an internal bug tracking this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69841/new/

[PATCH] D69841: Target Ivy bridge on macOS Mojave and later

davezarzycki added a comment. @bob.wilson – Ping. While Ivy Bridge (or really, Sandy Bridge) has AVX1, which enables faster memcpy, memset, and even memcmp (for common scenarios). If there is something I'm missing? If you can't explain why, that's okay. :-) Repository: rG LLVM Github

[PATCH] D69841: Target Ivy bridge on macOS Mojave and later

davezarzycki added a comment. Hi @bob.wilson – Am I missing something here? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69841/new/ https://reviews.llvm.org/D69841 ___ cfe-commits mailing list

[PATCH] D69841: Target Ivy bridge on macOS Mojave and later

davezarzycki created this revision. davezarzycki added a reviewer: bob.wilson. davezarzycki added a project: clang. Ivy Bridge is required by macOS 10.14 (Mojave) and later. Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D69841 Files: clang/lib/Driver/ToolChains/Arch/X86.cpp

[PATCH] D69786: [X86] Add support for -mvzeroupper and -mno-vzeroupper to match gcc.

davezarzycki added a comment. Actually, wait, what does it mean for a CPU without AVX to have `FeatureInsertVZEROUPPER`? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69786/new/ https://reviews.llvm.org/D69786

[PATCH] D69786: [X86] Add support for -mvzeroupper and -mno-vzeroupper to match gcc.

davezarzycki accepted this revision. davezarzycki added a comment. This revision is now accepted and ready to land. LGTM. Thanks! I'll close my differential proposal then. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69786/new/

[PATCH] D69518: [Diagnostics] Warn for std::is_constant_evaluated in constexpr mode

davezarzycki added a comment. Hi @xbolva00 – Thanks. That does make the libcxx test suite pass. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69518/new/ https://reviews.llvm.org/D69518 ___ cfe-commits

[PATCH] D69518: [Diagnostics] Warn for std::is_constant_evaluated in constexpr mode

davezarzycki added a comment. This broke two stage builds of libc++. Can we revert this until a fix is ready? FAIL: libc++ :: std/utilities/meta/meta.const.eval/is_constant_evaluated.fail.cpp (55845 of 59103) TEST 'libc++ ::

[PATCH] D66700: [Wdocumentation] improve wording of a warning message

davezarzycki added a comment. Works for me. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66700/new/ https://reviews.llvm.org/D66700 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D64696: Adds a warning when an inline Doxygen comment has no argument

davezarzycki added a comment. I don't think anybody is running doxygen over the Swift source right now, so I'll just escape the @ sign. That being said, can we improve this diagnostic? "command does not have an argument" is confusing when a given command does have an argument, just a malformed

[PATCH] D64696: Adds a warning when an inline Doxygen comment has no argument

davezarzycki added a comment. From the Swift language source (http://github.com/apple/swift): include/swift/AST/Attr.h:/// A limited variant of \c @objc that's used for classes with generic ancestry. include/swift/AST/Decl.h: /// \c @usableFromInline attribute are treated as public. This is

[PATCH] D62445: [test] Fix plugin tests

davezarzycki added a comment. In D62445#1616218 , @davezarzycki wrote: > Just FYI – Having LLVM_ENABLE_PLUGINS_default depend on LLVM_ENABLE_PIC is a > hack that should go away someday. Doing so requires that plugin dependencies > either always build

[PATCH] D62445: [test] Fix plugin tests

davezarzycki added a comment. Just FYI – Having LLVM_ENABLE_PLUGINS_default depend on LLVM_ENABLE_PIC is a hack that should go away someday. Doing so requires that plugin dependencies either always build PIC (and therefore ignore LLVM_ENABLE_PIC), or are linked into the executables that load

[PATCH] D64696: Adds a warning when an inline Doxygen comment has no argument

davezarzycki added a comment. Hello – This change seems to have exposed a bug in -Wdocumentation argument parsing. For example, this warns when it shouldn't(?): /// \c @foobar Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64696/new/

[PATCH] D62445: [test] Fix plugin tests

davezarzycki added a comment. This broke non-PIC builds. Fixed: r362399 Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62445/new/ https://reviews.llvm.org/D62445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D62174: [Analysis] Link library dependencies to Analysis plugins

davezarzycki added a comment. Fixed: r361399 Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62174/new/ https://reviews.llvm.org/D62174 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D62174: [Analysis] Link library dependencies to Analysis plugins

davezarzycki added a comment. This breaks non-PIC builds. Was this planned or expected? Can we revert this until a fix is found? Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62174/new/ https://reviews.llvm.org/D62174

[PATCH] D58216: Support attribute used in member funcs of class templates II

davezarzycki added a comment. https://bugs.llvm.org/show_bug.cgi?id=41016 Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58216/new/ https://reviews.llvm.org/D58216 ___ cfe-commits mailing list

[PATCH] D58216: Support attribute used in member funcs of class templates II

davezarzycki added a comment. I've got a patch pending for Swift. That being said, the clang diagnostics leave something to be desired. If `__attribute__((used))` on definitions is sloppy at best or wrong at worst, then that should have a warning/error. Want a bug report? Or does one exist

[PATCH] D58216: Support attribute used in member funcs of class templates II

davezarzycki added a subscriber: bob.wilson. davezarzycki added a comment. I can't get Swift top-of-tree to build with gcc (8.3.1 20190223 (Red Hat 8.3.1-2)), and I doubt that it is supported, but I could be wrong. In any case, the requested change to the Swift compiler source sounds

[PATCH] D58418: [clang][DirectoryWatcher] Upstream DirectoryWatcher

davezarzycki added a comment. Can we please revert this code? One cannot use dynamic_cast on a char *. Did you mean reinterpret_cast? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58418/new/ https://reviews.llvm.org/D58418 ___ cfe-commits

[PATCH] D58107: [MinGW] Add the profiling library when necessary

davezarzycki added a comment. This change breaks building/testing the compiler with `CLANG_DEFAULT_LINKER` set to `lld`. Was this intentional? What should people do if they want to use `CLANG_DEFAULT_LINKER` and run the test suite? Repository: rL LLVM CHANGES SINCE LAST ACTION

[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

davezarzycki added a comment. Hot fix: r352996 Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57592/new/ https://reviews.llvm.org/D57592 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D56928: Support attribute used in member funcs of class templates

davezarzycki added a comment. This change broke building Swift on my Linux box. The compiler confusingly complains about the *same* template being both explicitly specialized and implicitly instantiated: /home/dave/s/u/swift/stdlib/public/runtime/ProtocolConformance.cpp:34:38: error:

[PATCH] D55085: Avoid emitting redundant or unusable directories in DIFile metadata entries

davezarzycki added a comment. Hello @aprantl, This change broke the test suite when building in /tmp (tmpfs) on Linux: FAIL: Clang :: CodeGen/debug-info-abspath.c (5676 of 44360) - TEST 'Clang :: CodeGen/debug-info-abspath.c' FAILED Script: --- : 'RUN: at line 1';

[PATCH] D53219: Update hexagon driver tests

davezarzycki added a comment. Tested and verified with `-DCLANG_DEFAULT_LINKER=lld` Repository: rC Clang https://reviews.llvm.org/D53219 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D53038: [Hexagon] Use GetLinkerPath method instead of hard-coded linker name.

davezarzycki added a comment. A bisect revealed this change as the source of test failures on my Red Hat Fedora 28 Linux box. How was/is this tested? Command Output (stderr): /home/dave/s/lc/tools/clang/test/Driver/linux-ld.c:882:19: error: CHECK-HEXAGON: expected

[PATCH] D49457: DR330: when determining whether a cast casts away constness, consider qualifiers from all levels matching a multidimensional array

davezarzycki added a comment. Hi @rsmith – I've verified this patch fixes the original issue. Thanks for the quick fix! Repository: rC Clang https://reviews.llvm.org/D49457 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D45777: [UnitTests] NFC/build-perf: Break up nontrivial compile jobs

davezarzycki closed this revision. davezarzycki added a comment. Thanks @thakis! Committed as r330353 Repository: rC Clang https://reviews.llvm.org/D45777 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D45777: [UnitTests] NFC/build-perf: Break up nontrivial compile jobs

davezarzycki added a comment. Ping. Any review feedback would be appreciated. Thanks! Repository: rC Clang https://reviews.llvm.org/D45777 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D45777: [UnitTests] NFC/build-perf: Break up nontrivial compile jobs

davezarzycki created this revision. davezarzycki added reviewers: arphaman, sberg, delesley, james.dennett, jdennett, klimek. Herald added a subscriber: mgorny. RecursiveASTVisitorTest.cpp is one of the longest compile jobs and a build bottleneck on many-core machines. This patch breaks that

[PATCH] D43578: -ftime-report switch support in Clang

davezarzycki added a comment. It wasn't my suggestion. @thakis wrote: "We probably should have a separate bool in clang and key this off that and make -ftime-report set both." https://reviews.llvm.org/D43578 ___ cfe-commits mailing list

[PATCH] D43578: -ftime-report switch support in Clang

davezarzycki added a comment. Hi @efriedma – Sorry about that. I haven't directly used `svn` in years thanks to the `git svn` bridge. Repository: rL LLVM https://reviews.llvm.org/D43578 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D43578: -ftime-report switch support in Clang

davezarzycki added a comment. A revert in practice just means undoing the changes. For example, while both `git` and `svn` have `revert` subcommands, you can also just take the original diff/patch, pipe it into `patch -R`, and if there are no conflicts, commit the result. Repository: rL

[PATCH] D45488: [X86] Disable SGX for Skylake Server - CPP test

davezarzycki added a comment. I don't think this change is correct. To the best of my knowledge, SKL does support SGX but SKX does not. Repository: rC Clang https://reviews.llvm.org/D45488 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D45058: [X86] Disable SGX for Skylake Server

davezarzycki added a comment. I think this change is incomplete. The following clang test fails on my SKX machine: `Preprocessor/predefined-arch-macros.c` Line 895: `// CHECK_SKX_M32: #define __SGX__ 1` Repository: rL LLVM https://reviews.llvm.org/D45058

[PATCH] D45485: [CMake] Unbreak BUILD_SHARED_LIBS workflow

davezarzycki added a comment. Great! I'll revisit this patch in a week and see if it is still needed. Hopefully the author of https://reviews.llvm.org/D43578 will make this patch unnecessary by then. Repository: rC Clang https://reviews.llvm.org/D45485

[PATCH] D45485: [CMake] Unbreak BUILD_SHARED_LIBS workflow

davezarzycki added a comment. I haven't proven that r329684 is the source of the regression, but it is the only timer related change in the last 24 hours as far as I can tell. Repository: rC Clang https://reviews.llvm.org/D45485 ___ cfe-commits

[PATCH] D45485: [CMake] Unbreak BUILD_SHARED_LIBS workflow

davezarzycki created this revision. davezarzycki added reviewers: mspertus, beanz, gottesmm. Herald added a subscriber: mgorny. Due to recent timer changes, we need to add LLVM's `Core` library to avoid undefined symbol errors at link time (`llvm::TimePassesIsEnabled`) when using LLVM's