Page MenuHomePhabricator

davezarzycki (David Zarzycki)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 28 2017, 11:01 AM (111 w, 2 d)

Recent Activity

Today

davezarzycki created D69111: [X86] Emit KTEST when possible.
Thu, Oct 17, 8:17 AM · Restricted Project

Yesterday

davezarzycki added a comment to D69003: cmake/modules/AddLLVM.cmake: pass '-latomic' to the linker if necessary.

This seems reasonable to me but I'm not an expert at LLVM's CMake setup.

Wed, Oct 16, 12:21 PM · Restricted Project
davezarzycki created D69044: [X86] Allow up to 4 loads per inline memcmp().
Wed, Oct 16, 8:36 AM · Restricted Project

Tue, Oct 15

davezarzycki added a comment to rG59390efef259: [X86] Make memcmp() use PTEST if possible and also enable AVX1.

https://reviews.llvm.org/D68632

Tue, Oct 15, 11:26 AM
davezarzycki closed D68632: [X86] Make memcmp() use PTEST if possible and also enable AVX1.

r374922

Tue, Oct 15, 11:26 AM · Restricted Project
davezarzycki committed rG59390efef259: [X86] Make memcmp() use PTEST if possible and also enable AVX1 (authored by davezarzycki).
[X86] Make memcmp() use PTEST if possible and also enable AVX1
Tue, Oct 15, 10:39 AM
davezarzycki committed rL374922: [X86] Make memcmp() use PTEST if possible and also enable AVX1.
[X86] Make memcmp() use PTEST if possible and also enable AVX1
Tue, Oct 15, 10:39 AM
davezarzycki updated the diff for D68632: [X86] Make memcmp() use PTEST if possible and also enable AVX1.

Now using DAG.getAllOnesConstant()

Tue, Oct 15, 7:02 AM · Restricted Project
davezarzycki added a comment to D68632: [X86] Make memcmp() use PTEST if possible and also enable AVX1.

Hi @craig.topper – Ping. Is this ready to land? Any other requests?

Tue, Oct 15, 3:58 AM · Restricted Project

Sat, Oct 12

davezarzycki added a comment to D68879: P1152R4: Fix deprecation warnings in libc++ testsuite and in uses of is_invocable that would internally conjure up a deprecated function type..

Is there an ETA for this fix? Without it, stage two testing fails:

Sat, Oct 12, 2:26 AM · Restricted Project

Fri, Oct 11

davezarzycki updated the diff for D68632: [X86] Make memcmp() use PTEST if possible and also enable AVX1.

I believe I've incorporated all of the feedback so far.

Fri, Oct 11, 5:08 AM · Restricted Project

Thu, Oct 10

davezarzycki updated the diff for D68632: [X86] Make memcmp() use PTEST if possible and also enable AVX1.

Incorporated PTEST feedback.

Thu, Oct 10, 7:25 AM · Restricted Project
davezarzycki added inline comments to D68632: [X86] Make memcmp() use PTEST if possible and also enable AVX1.
Thu, Oct 10, 6:57 AM · Restricted Project

Tue, Oct 8

davezarzycki created D68632: [X86] Make memcmp() use PTEST if possible and also enable AVX1.
Tue, Oct 8, 4:14 AM · Restricted Project

Sun, Oct 6

davezarzycki committed rG7653ff398d28: [X86] Enable AVX512BW for memcmp() (authored by davezarzycki).
[X86] Enable AVX512BW for memcmp()
Sun, Oct 6, 3:25 AM
davezarzycki committed rL373845: [X86] Enable AVX512BW for memcmp().
[X86] Enable AVX512BW for memcmp()
Sun, Oct 6, 3:24 AM
davezarzycki closed D68457: [X86] Enable AVX512BW for memcmp.

r373845

Sun, Oct 6, 3:24 AM · Restricted Project

Sat, Oct 5

davezarzycki added a comment to D68457: [X86] Enable AVX512BW for memcmp.

Is this patch ready to land then?

Sat, Oct 5, 4:43 AM · Restricted Project
davezarzycki updated the diff for D68457: [X86] Enable AVX512BW for memcmp.

Simplified to just enabling AVX512BW for 512 and let 128/256 keep using AVX/AVX2.

Sat, Oct 5, 1:01 AM · Restricted Project

Fri, Oct 4

davezarzycki added a comment to D68075: Do not #error if no OS is #defined.

I kinda like the suggestion. I'm pretty confident we don't support compilers that don't implement __has_include anyway (maybe we technically do, but I'm sure nothing good happens in that case).

However, even your suggestion doesn't answer the question of what's the purpose of setting -DLIBCXX_ENABLE_THREADS=OFF if we detect it automatically in the headers anyway. If we go down your route, I'd drop -DLIBCXX_ENABLE_THREADS completely from CMake (but that suggests a broader direction from the project where the headers should be usable without any configuration option).

Fri, Oct 4, 12:32 PM · Restricted Project, Restricted Project
davezarzycki added a comment to D68457: [X86] Enable AVX512BW for memcmp.

That's a reasonable point. From my perspective:

Fri, Oct 4, 11:51 AM · Restricted Project
davezarzycki created D68457: [X86] Enable AVX512BW for memcmp.
Fri, Oct 4, 4:37 AM · Restricted Project
davezarzycki committed rG03b216d85472: [X86] Enable inline memcmp() to use AVX512 (authored by davezarzycki).
[X86] Enable inline memcmp() to use AVX512
Fri, Oct 4, 12:47 AM
davezarzycki committed rL373706: [X86] Enable inline memcmp() to use AVX512.
[X86] Enable inline memcmp() to use AVX512
Fri, Oct 4, 12:47 AM
davezarzycki closed D68445: Enable AVX512 memcmp().

r373706

Fri, Oct 4, 12:47 AM · Restricted Project

Thu, Oct 3

davezarzycki created D68445: Enable AVX512 memcmp().
Thu, Oct 3, 11:49 PM · Restricted Project
davezarzycki added a comment to D68075: Do not #error if no OS is #defined.

Hi @mclow.lists – Ping. Any thoughts on the simplification you requested?

Thu, Oct 3, 11:49 PM · Restricted Project, Restricted Project

Tue, Oct 1

davezarzycki added a comment to D68085: [yaml2obj/obj2yaml] - Add support for SHT_HASH sections..

What platform was this tested on? This seems to be failing on my Fedora 31 x86_64 box:

Tue, Oct 1, 3:56 AM · Restricted Project

Thu, Sep 26

davezarzycki added a comment to D68075: Do not #error if no OS is #defined.

The two tests:

Thu, Sep 26, 9:07 PM · Restricted Project, Restricted Project
davezarzycki added a comment to D68075: Do not #error if no OS is #defined.

I think trying to work out of the box with zero tuning in common scenarios and minimal tuning with uncommon scenarios is the right approach. If it were up to me, I’d flip the test: If windows then set the Windows define, otherwise pthreads.h exists, assume pthreads. If somebody is compiling “freestanding” like myself, then a link error about missing pthreads is expected behavior.

Thu, Sep 26, 7:38 AM · Restricted Project, Restricted Project
davezarzycki added a comment to D68075: Do not #error if no OS is #defined.

Hi @ldionne – That's a good question and I don't know the answer. If it's okay with you, I'd like to keep this change request narrowly focused on getting libcxx to work at all with freestanding environments.

Thu, Sep 26, 7:12 AM · Restricted Project, Restricted Project
davezarzycki committed rG7568899b35cf: [Testing] unbreak after r372963 (authored by davezarzycki).
[Testing] unbreak after r372963
Thu, Sep 26, 4:34 AM
davezarzycki committed rL372967: [Testing] unbreak after r372963.
[Testing] unbreak after r372963
Thu, Sep 26, 4:33 AM
davezarzycki committed rGa0686015106c: [libcxx] Do not implicitly #include assert.h (authored by davezarzycki).
[libcxx] Do not implicitly #include assert.h
Thu, Sep 26, 4:13 AM
davezarzycki committed rL372963: [libcxx] Do not implicitly #include assert.h.
[libcxx] Do not implicitly #include assert.h
Thu, Sep 26, 4:12 AM
davezarzycki committed rGb6c80623d137: [Testing] Workaround libcxx bug when OS is "none" (authored by davezarzycki).
[Testing] Workaround libcxx bug when OS is "none"
Thu, Sep 26, 1:23 AM
davezarzycki committed rL372949: [Testing] Workaround libcxx bug when OS is "none".
[Testing] Workaround libcxx bug when OS is "none"
Thu, Sep 26, 1:23 AM
davezarzycki created D68075: Do not #error if no OS is #defined.
Thu, Sep 26, 12:58 AM · Restricted Project, Restricted Project

Tue, Sep 24

davezarzycki removed a reviewer for D58675: [clang] Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps: davezarzycki.
Tue, Sep 24, 5:40 AM · Restricted Project, Restricted Project

Sun, Sep 22

davezarzycki committed rGa7a515cb7738: Prefer AVX512 memcpy when applicable (authored by davezarzycki).
Prefer AVX512 memcpy when applicable
Sun, Sep 22, 10:03 PM
davezarzycki closed D67874: Prefer AVX512 memcpy when applicable.

r372540

Sun, Sep 22, 10:03 PM · Restricted Project
davezarzycki committed rL372540: Prefer AVX512 memcpy when applicable.
Prefer AVX512 memcpy when applicable
Sun, Sep 22, 9:59 PM
davezarzycki updated the diff for D67874: Prefer AVX512 memcpy when applicable.

This patch has now been run through update_llc_test_checks.

Sun, Sep 22, 12:48 PM · Restricted Project
davezarzycki added inline comments to D67875: [X86] X86DAGToDAGISel::matchBEXTRFromAndImm(): if can't use BEXTR, fallback to BZHI (PR43381).
Sun, Sep 22, 12:05 PM · Restricted Project
davezarzycki added inline comments to D67874: Prefer AVX512 memcpy when applicable.
Sun, Sep 22, 11:26 AM · Restricted Project
davezarzycki updated the diff for D67874: Prefer AVX512 memcpy when applicable.

Hi @craig.topper – Thanks for writing the memset tests. I've expanded the non-zero one to also handle different preferred vector sizes.

Sun, Sep 22, 8:00 AM · Restricted Project

Sat, Sep 21

davezarzycki added a comment to D67874: Prefer AVX512 memcpy when applicable.

Do we have a similar test for memset that should be updated?

Sat, Sep 21, 12:30 PM · Restricted Project
davezarzycki updated the diff for D67874: Prefer AVX512 memcpy when applicable.

The patch no longer depends on the AVX512 vector length extension.

Sat, Sep 21, 11:51 AM · Restricted Project
davezarzycki accepted D67875: [X86] X86DAGToDAGISel::matchBEXTRFromAndImm(): if can't use BEXTR, fallback to BZHI (PR43381).

Thanks for doing this work! I'm not an expert in this source code, so please wait for somebody else to approve it.

Sat, Sep 21, 11:06 AM · Restricted Project
davezarzycki added a comment to D67875: [X86] X86DAGToDAGISel::matchBEXTRFromAndImm(): if can't use BEXTR, fallback to BZHI (PR43381).

Neat! If you have the time, the BZHI bits-to-preserve operand only needs MOVB for initialization. That being said, MOVL probably avoids partial register update stalls, so maybe that’s why you’re seeing a performance gain.

Sat, Sep 21, 8:32 AM · Restricted Project
davezarzycki created D67874: Prefer AVX512 memcpy when applicable.
Sat, Sep 21, 3:12 AM · Restricted Project

Fri, Sep 20

davezarzycki committed rG4fff87d2eea1: [Testing] Python 3 requires `print` to use parens (authored by davezarzycki).
[Testing] Python 3 requires `print` to use parens
Fri, Sep 20, 6:54 AM
davezarzycki committed rL372392: [Testing] Python 3 requires `print` to use parens.
[Testing] Python 3 requires `print` to use parens
Fri, Sep 20, 6:54 AM

Sep 16 2019

davezarzycki accepted D67171: LLVM_COMPILE_FLAGS also applies to C files.

r371173 and r371521

Sep 16 2019, 10:31 PM · Restricted Project
davezarzycki closed D67171: LLVM_COMPILE_FLAGS also applies to C files.
Sep 16 2019, 10:31 PM · Restricted Project
davezarzycki committed rG73f2dbb7d24d: [git-llvm] Do not reinvent `@{upstream}` (take 2) (authored by davezarzycki).
[git-llvm] Do not reinvent `@{upstream}` (take 2)
Sep 16 2019, 9:46 PM
davezarzycki closed D67389: [git-llvm] Do not reinvent `@{upstream}` (take 2).

r372070

Sep 16 2019, 9:43 PM · Restricted Project
davezarzycki committed rL372070: [git-llvm] Do not reinvent `@{upstream}` (take 2).
[git-llvm] Do not reinvent `@{upstream}` (take 2)
Sep 16 2019, 9:42 PM

Sep 13 2019

davezarzycki added a comment to D66775: [libclang] Expose abort()-ing fatal error handler.

This breaks one of the clang unit tests on Fedora 30 (x86_64). Can we revert or fix this?

FAIL: Clang-Unit :: libclang/CrashTests/./libclangCrashTests/LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler (19745 of 51413)
******************** TEST 'Clang-Unit :: libclang/CrashTests/./libclangCrashTests/LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler' FAILED ********************
Note: Google Test filter = LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from LibclangParseTest
[ RUN      ] LibclangParseTest.UninstallAbortingLLVMFatalErrorHandler
LLVM ERROR: #pragma clang __debug llvm_fatal_error
Sep 13 2019, 2:29 AM · Restricted Project

Sep 12 2019

davezarzycki added a comment to D67389: [git-llvm] Do not reinvent `@{upstream}` (take 2).

Works for me, but let's confirm with @thakis

Sep 12 2019, 1:02 AM · Restricted Project

Sep 11 2019

davezarzycki committed rGc167402183aa: [WebAssembly] Add REQUIRES to test (authored by davezarzycki).
[WebAssembly] Add REQUIRES to test
Sep 11 2019, 11:52 PM
davezarzycki committed rL371710: [WebAssembly] Add REQUIRES to test.
[WebAssembly] Add REQUIRES to test
Sep 11 2019, 11:51 PM
davezarzycki committed rGb250d5ff5e7c: [LLDB] Do not try to canonicalize gethostname() result (authored by davezarzycki).
[LLDB] Do not try to canonicalize gethostname() result
Sep 11 2019, 1:33 AM
davezarzycki committed rL371596: [LLDB] Do not try to canonicalize gethostname() result.
[LLDB] Do not try to canonicalize gethostname() result
Sep 11 2019, 1:33 AM
davezarzycki added a comment to D67230: Remove call to obsolete gethostbyname, using getaddrinfo.

Great. See: r371596

Sep 11 2019, 1:33 AM · Restricted Project, Restricted Project

Sep 10 2019

davezarzycki added a comment to D67262: [git-llvm] Do not reinvent `@{upstream}`.

I don't know what the long-term plans for this script are.

The only way for us to enforce linear history on GitHub at the moment is to mandate the use of the script unfortunately.

Sep 10 2019, 11:04 PM · Restricted Project
davezarzycki committed rGfef1cb1c971e: [CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compiler (authored by davezarzycki).
[CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compiler
Sep 10 2019, 7:20 AM
davezarzycki added a comment to D67171: LLVM_COMPILE_FLAGS also applies to C files.

Hi @uabelho – Try r371521

Sep 10 2019, 7:18 AM · Restricted Project
davezarzycki committed rL371521: [CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compiler.
[CMake] Don't pass all LLVM_COMPILE_FLAGS to the C compiler
Sep 10 2019, 7:18 AM
davezarzycki added a comment to D67262: [git-llvm] Do not reinvent `@{upstream}`.

Upon re-reading this sounds a bit accusatory. That's not how I meant this, apologies for that! I understand you're solving a problem you're having and that's a fine thing to do of course. I'm just trying to say that this particular approach (unintentionally!) caused a problem for me, and I imagine for many people using the monorepo.

I'm trying to brainstorm ways forward that solve your problem without breaking me.

Sep 10 2019, 7:02 AM · Restricted Project
davezarzycki created D67389: [git-llvm] Do not reinvent `@{upstream}` (take 2).
Sep 10 2019, 1:44 AM · Restricted Project
davezarzycki added a comment to D67262: [git-llvm] Do not reinvent `@{upstream}`.

I took the responsibility of reverting in r371480, since I approved this revision without anticipating the behavior change.

To add some more words, previously we could git checkout -b foo, hack a bit commit, and run this script. Now this requires additional, long flags. I don't think making a corner case work that nobody noticed being broken for many months is worth making everything more inconvenient for everyone.

This is a very good point. How do we move forward though?
With the migration to GitHub around the corner, I think it'll be important to have git llvm behaves as much as possible as thin wrapper on top of git (in case you don't know git llvm push will be mandatory to push to LLVM on GitHub, as far as I know).

Sep 10 2019, 12:38 AM · Restricted Project

Sep 8 2019

davezarzycki added a comment to D67262: [git-llvm] Do not reinvent `@{upstream}`.

The script doesn't have the ability to specify the name of the remote server. That being said, the script is only designed to work with one backend server due to how it hides SVN and in the future how it will hide GitHub status check magic.

Sep 8 2019, 8:50 PM · Restricted Project
davezarzycki closed D67262: [git-llvm] Do not reinvent `@{upstream}`.
  1. Working with and configuring upstream branches is fundamental to using git.
  2. It was a mistake for the git-llvm script to assume that the remote named "origin" is the official LLVM repository. For many people, "origin" is probably correct, but for many others, and the remote named origin depends on which repository was cloned first.
  3. Your local branch isn't setup correctly. You can fix that with git branch --set-upstream-to=origin/master (assuming that origin is the correct name of the remote server in your git repository).
  4. When you use git branch or git checkout, please remember to use --track if that is what you want/need.
Sep 8 2019, 4:10 AM · Restricted Project

Sep 6 2019

davezarzycki committed rG7faffd544b16: [git-llvm] Do not reinvent `@{upstream}` (authored by davezarzycki).
[git-llvm] Do not reinvent `@{upstream}`
Sep 6 2019, 11:47 PM
davezarzycki committed rL371290: [git-llvm] Do not reinvent `@{upstream}`.
[git-llvm] Do not reinvent `@{upstream}`
Sep 6 2019, 11:47 PM
davezarzycki added a comment to D67230: Remove call to obsolete gethostbyname, using getaddrinfo.

This code is trying too hard and failing. Either the result of gethostname() is canonical or it is not. If it is not, then trying to canonicalize it is – for various reasons – a lost cause. For example, a given machine might have multiple network interfaces with multiple addresses per interface, each with a different canonical name. Separably, the result of HostInfoPosix::GetHostname() and latency thereof shouldn't depend on whether networking is up or down or what network the machine happened to be attached to at any given moment (like a laptop that travels between work and home).

Sep 6 2019, 5:36 AM · Restricted Project, Restricted Project
davezarzycki added a comment to D65884: [ARM] MVE Tail Predication.

I think this might have caused a regression (my git-bisect is nearly complete):

FAIL: LLVM :: CodeGen/ARM/O3-pipeline.ll (24373 of 51236)
******************** TEST 'LLVM :: CodeGen/ARM/O3-pipeline.ll' FAILED ********************
Script:
--
: 'RUN: at line 1';   /tmp/_update_lc/t/bin/llc -mtriple=arm -O3 -debug-pass=Structure < /home/dave/s/lp/llvm/test/CodeGen/ARM/O3-pipeline.ll -o /dev/null 2>&1 | grep -v "Verify generated machine code" | /tmp/_update_lc/t/bin/FileCheck /home/dave/s/lp/llvm/test/CodeGen/ARM/O3-pipeline.ll
--
Exit Code: 1
Sep 6 2019, 2:19 AM · Restricted Project
davezarzycki created D67262: [git-llvm] Do not reinvent `@{upstream}`.
Sep 6 2019, 1:20 AM · Restricted Project
davezarzycki committed rG412a8d7a8310: [CMake] LLVM_COMPILE_FLAGS also applies to C files (authored by davezarzycki).
[CMake] LLVM_COMPILE_FLAGS also applies to C files
Sep 6 2019, 12:15 AM
davezarzycki committed rL371173: [CMake] LLVM_COMPILE_FLAGS also applies to C files.
[CMake] LLVM_COMPILE_FLAGS also applies to C files
Sep 6 2019, 12:11 AM

Sep 4 2019

davezarzycki updated the diff for D67171: LLVM_COMPILE_FLAGS also applies to C files.
Sep 4 2019, 7:33 AM · Restricted Project
davezarzycki created D67171: LLVM_COMPILE_FLAGS also applies to C files.
Sep 4 2019, 7:17 AM · Restricted Project
davezarzycki committed rL370846: Add myself and sort the list.
Add myself and sort the list
Sep 4 2019, 12:54 AM

Aug 24 2019

davezarzycki accepted D66700: [Wdocumentation] improve wording of a warning message.
Aug 24 2019, 4:07 AM · Restricted Project, Restricted Project
davezarzycki added a comment to D66700: [Wdocumentation] improve wording of a warning message.

Works for me. Thanks!

Aug 24 2019, 4:07 AM · Restricted Project, Restricted Project
davezarzycki committed rG98bcf690ae03: [Testing] Unbreak r369830 (authored by davezarzycki).
[Testing] Unbreak r369830
Aug 24 2019, 1:14 AM
davezarzycki committed rL369843: [Testing] Unbreak r369830.
[Testing] Unbreak r369830
Aug 24 2019, 1:14 AM

Aug 20 2019

davezarzycki committed rGb08884554f68: [PPC Docs] Remove duplicate info about __builtin_setrnd() (authored by davezarzycki).
[PPC Docs] Remove duplicate info about __builtin_setrnd()
Aug 20 2019, 11:50 PM
davezarzycki committed rL369496: [PPC Docs] Remove duplicate info about __builtin_setrnd().
[PPC Docs] Remove duplicate info about __builtin_setrnd()
Aug 20 2019, 11:49 PM

Aug 6 2019

davezarzycki added a comment to D64696: Adds a warning when an inline Doxygen comment has no argument.

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 one. What do you think about "command must precede a word"? At least that gives a hint that the argument is not a "word" according to doxygen.

Aug 6 2019, 11:47 PM · Restricted Project, Restricted Project
davezarzycki added a comment to D64696: Adds a warning when an inline Doxygen comment has no argument.

From the Swift language source (http://github.com/apple/swift):

Aug 6 2019, 12:57 AM · Restricted Project, Restricted Project

Aug 5 2019

davezarzycki added a comment to D62445: [test] Fix plugin tests.

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 them and the plugin knows how to find them in the executable. In the case of the latter and on Mach-O platforms, this requires passing -bundle_loader $PATH_TO_EXECUTABLE to the linker when creating the plugin (a.k.a. "bundle"), but on ELF platforms, I'm not sure what needs to be done.

Aug 5 2019, 11:30 PM · Restricted Project, Restricted Project
davezarzycki added a comment to D62445: [test] Fix plugin tests.

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 them and the plugin knows how to find them in the executable. In the case of the latter and on Mach-O platforms, this requires passing -bundle_loader $PATH_TO_EXECUTABLE to the linker when creating the plugin (a.k.a. "bundle"), but on ELF platforms, I'm not sure what needs to be done.

Aug 5 2019, 11:11 PM · Restricted Project, Restricted Project
davezarzycki added a comment to D64696: Adds a warning when an inline Doxygen comment has no argument.

Hello – This change seems to have exposed a bug in -Wdocumentation argument parsing. For example, this warns when it shouldn't(?):

Aug 5 2019, 3:19 AM · Restricted Project, Restricted Project

Jul 31 2019

davezarzycki committed rG4f1d893f9ec3: [Testing] Fix tests that break with read-only checkouts (authored by davezarzycki).
[Testing] Fix tests that break with read-only checkouts
Jul 31 2019, 11:42 PM
davezarzycki committed rL367519: [Testing] Fix tests that break with read-only checkouts.
[Testing] Fix tests that break with read-only checkouts
Jul 31 2019, 11:40 PM

Jul 15 2019

davezarzycki committed rG12400b97838d: [Testing] Add missing "REQUIRES: asserts" (authored by davezarzycki).
[Testing] Add missing "REQUIRES: asserts"
Jul 15 2019, 7:14 AM
davezarzycki committed rL366065: [Testing] Add missing "REQUIRES: asserts".
[Testing] Add missing "REQUIRES: asserts"
Jul 15 2019, 7:13 AM

Jul 4 2019

davezarzycki added a comment to D64200: [ELF] Allow placing non-string SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

I just did a quick test of this patch and now stage two testing works (Fedora 30, x86-64)

Jul 4 2019, 5:51 AM · Restricted Project