search for: programmerjake

...name Product: Portable OpenSSH Version: -current Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: scp Assignee: unassigned-bugs at mindrot.org Reporter: programmerjake at gmail.com I first found this on Termux on AArch64 Android, but am able to replicate on x86-64 Ubuntu 20.04. running: touch ????????????????????????????????????????????????????????????????.txt scp ????????????????????????????????????????????????????????????????.txt jacob at 192.168.1.141: give...

On Thu, Feb 7, 2019, 09:21 Simon Moll <moll at cs.uni-saarland.de> wrote: > > On 2/7/19 6:08 PM, David Greene wrote: > > Jacob Lifshay <programmerjake at gmail.com> writes: > > > >> So it would be handy for the vector length on evl intrinsics to be in > >> units of the mask length so we don't have to pattern match a division > >> in the backend. We could have 2 variants of the vector length > >> ar...

Hi, I've cross-posted this to freedesktop@, as the xdg@ list is only used for actual specification development. On Mon, 22 Oct 2018 at 00:36, Jacob Lifshay <programmerjake at gmail.com> wrote: > Hi, we were thinking of asking if freedesktop would host Kazan (https://github.com/kazan-3d/kazan) for us, however some of our community members have objections with how freedesktop's Code of Conduct is currently written. Would it be acceptable for a project on free...

Jacob Lifshay <programmerjake at gmail.com> writes: > So it would be handy for the vector length on evl intrinsics to be in > units of the mask length so we don't have to pattern match a division > in the backend. We could have 2 variants of the vector length > argument, one in terms of the data vector and o...

...On Thu, Jan 31, 2019 at 11:53 PM Luke Kenneth Casson Leighton via > llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > --- > > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > > On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay <programmerjake at gmail.com> > wrote: > > > > > > We're in-progress designing a RISC-V extension ( > http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) > that would have variable-length vectors of short vectors (1 to 4): > > > <VL x <4...

--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Jan 31, 2019 at 10:22 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > We're in-progress designing a RISC-V extension (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) that would have variable-length vectors of short vectors (1 to 4): > <VL x <4 x float>> > where each predicate bit...

+cfe-dev at lists.llvm.org On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > Stash a lookup table from integers to strings in Context and dynamically allocate integers for new strings. You can then keep integers in most of the code, writing/displaying strings for the integers with an entry in the table when writing to files or displaying. &...

On Thu, Jan 30, 2020, 10:22 Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I want to restart this discussion. There seemed to be support for this, > but we got held up trying to decide on the appropriate set of tags to > use to classify issues. > > I propose that we move forward with this proposal and disable creation of > new bugs in

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

I've posted two patches on Phabricator to add support for VScale in LLVM. A brief recap on `vscale`: The scalable vector type in LLVM IR is defined as `<vscale x n x m>`, to create types such as `<vscale x 16 x i8>` for a scalable vector with at least 16 bytes. In the definition of the scalable type, `vscale` is specified as a positive constant of type integer that will only be

On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote: > On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I've posted two patches on Phabricator to add support for VScale in LLVM. Excellent! > > > > A brief recap on `vscale`:...

Hello, We would like to propose a way for improving the diagnostics for address_space by being able to pass strings as an argument to it instead of just an integer. This was initially proposed before (http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html) but did not focus on it at the time. Reasoning: Clang's __attribute__((address_space(...))) feature uses an arbitrary integer as

Hi All, The general initializer support patch has landed (see 85fb997659b plus follow up fixes). Some quick background: Until now ORC, like MCJIT, has handled static initializer discovery by searching for llvm.global_ctors and llvm.global_dtors arrays in the IR added to the JIT. This approach suffers from several drawbacks: 1) It provides no built-in support for other program representations:

On Mon, 4 Feb 2019 at 22:04, Simon Moll <moll at cs.uni-saarland.de> wrote: > On 2/4/19 9:18 PM, Robin Kruppe wrote: > > > > On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Simon Moll <moll at cs.uni-saarland.de> writes: >> >> > You are referring to the sub-vector sizes, if i am

Hi, There is now an RFC for a roadmap to native vector predication support in LLVM and a prototype implementation:   https://reviews.llvm.org/D57504 The prototype demonstrates: -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set