similar to: [RFC] Adding a char set converter to Support library

My understanding is that dynamically linking should pose no problem, but I am no lawyer. On Linux, glibc is also under LGPL license, and LLVM usually links against it. (There is really no need for us to depend on libiconv. If it is deemed to risky, then I can dropped it.) From: Anton Korobeynikov <anton at korobeynikov.info> To: Kai Peter Nacke <kai.nacke at de.ibm.com> Cc:

Hi! Implementing the Memory::allocateMappedMemory() function on z/OS, I see a failure in the AArch64 COFF test case. The test case has 3 sections. For each section, Memory::allocateMappedMemory() is called to reserve memory. If the distance between the pointers gets too large, then the test case fails. It can be reliable produced with a distance of 1MB between the pointers. An easy way to

As part of IBM’s ongoing efforts to improve the z/OS ecosystem, our current plans involve adding support for the z/OS platform to LLVM and Clang. Our goal is to have a viable C and C++ LLVM compiler and runtime library that generates code for, and runs on z/OS. Long term, we expect to have a compiler and library that supports the platform more fully. We intend to support the native character

Hubert Tong <hubert.reinterpretcast at gmail.com> wrote on 10.06.2020 23:51:54: > From: Hubert Tong <hubert.reinterpretcast at gmail.com> > To: Kai Peter Nacke <kai.nacke at de.ibm.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Date: 10.06.2020 23:52 > Subject: [EXTERNAL] Re: [llvm-dev] RFC: Adding support for the z/OS > platform to LLVM and clang

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Kai Peter Nacke > via llvm-dev > Sent: Tuesday, June 16, 2020 8:51 AM > To: Corentin <corentin.jabot at gmail.com> > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] RFC: Adding support for the z/OS platform to LLVM and > clang > > > > 2) Add

Open Letter to Developers, Is there any way you can cut through the mob scene at Homeland Defense with a powerful new encryption/decryption formula? The government cryptography bunch are stuck in symmetry and asymmetry and are deaf/dumb/blind to supersymmetry. When it's so easy to line up a supersymmetrical hypercube fractal-to-fractal, pair-to-pair, quantum-to-quantum and slice through

Hello, I've made changes to the prologue to not spill callee saved gprs to the stack but rather spill them to unused vector registers. I'm not sure how to handle this in the cfi directives. Originally, we would use cfi_offset to give an offset of where it is saved on the stack. I tried to instead use the cfi_restore directive. As the docs say ".cfi_restore says that the rule

Can I make another suggestion: create an intrinsic for memory equality, e.g. llvm.memcmp_eq.p0i8.p0i8.i64(i8*a, i8*b, i64 len). This intrinsic would return zero if the memory regions are equal, and nonzero otherwise. However, it does NOT return any notion of "greater" or "less". Many applications require only determining equality, rather than a total ordering. Given that

With the intrinsic support for ‘memcpy’ and ‘memset’ the operands also have associated alignment operands. I think that ‘memcmp’ should also provide the alignment information for each of the source operands (when statically known). In some cases this will lead to more optimal alignment aware lowering, and for targets for which unaligned access is costly or fatal, it can be lowered safely.

Currently on PowerPC, calls to memcmp are not expanded and are left as library calls. In certain conditions, expansion can improve performance rather than calling the library function as done for functions like memcpy, memmove, etc. This patch (https://reviews.llvm.org/D28163) is an initial implementation for PowerPC to expand memcmp when the size is an 8 byte multiple. The approach currently

Improving lowering for memcmp is definitely something we should do for all targets. Doing it in a target specific way is decidedly non-ideal. It looks like we already have some code in SelectionDAGBuilder which tries to optimize the lowering for the memcpy library call. I am a bit confused by the problem you are trying to solve. Are you specifically interested in lowering for constant

Hello, as of Jul 9, the LNT build bot on SystemZ shows red. The problem occurs in the "setup lit" test, which fails due to: Processing dependencies for LNT==0.4.2.dev0 Searching for typing Reading https://pypi.org/simple/typing/ Downloading

Hello, as discussed here in more detail: https://reviews.llvm.org/D81583 the introduction of the C++20 [[no_unique_address]] attribute exposes an ABI issue on platforms that require special handling for structs/classes that are "equivalent" to a single floating-point member (or in some cases, a "homogeneous" set of floating-point members). This is because we can now for the

Hi, I've a question regarding the openvz driver. I noticed that the virsh dumpxml output does not contain the memory settings. E.g.: <domain type='openvz'> <name>104</name> <uuid>ad2e9d0b-d242-482a-8640-5102e49d0f9b</uuid> <memory unit='KiB'>0</memory> <currentMemory unit='KiB'>0</currentMemory> <vcpu

With samba-2.2.5, cups-1.1.14, and printcap=cups, I find that I have to explicitly clean up old print data files in /var/spool/samba with a cron job. With a traditional LPR, we use -r to tell lpr to remove the file for us after the file is spooled. With cups, we send it over ipp, and I think we should then unlink the data file ourselves. Does this seem right? --- print_cups.c~ Thu May

On 11 December 2013 05:41, Kai Nacke <kai.nacke at redstar.de> wrote: > Maybe we should also change the stack probing code. I think ___chkstk_ms is > used since gcc 4.6. It simplifies the prologue generation code a bit. I just checked gcc 4.6 and looks like you are right, it uses ___chkstk_ms. LGTM. We should probably commit this first, since it is common for gcc 4.6 and newer.

Hi, PR17975 was caused by r191059 which was reverted on the 3.4 branch in r196521. However, the problem still occurs with trunk (confirmed as of r206186). >From a thread on cfe-commits I see that Kai Nacke (the author of r191059) was working on a patch to fix PR17975, but the conversation ends: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131202/197968.html So my question

Hi David, >>Ah, so this is a commercially backed project? Initially it wasn’t. I started to do this in my own free time and after I got something which I could demonstrate I can be much better than what we currently have with GCC it became part of my day to day job. >>But relatively small? (are you the only engineer working on this?) Yes I’m the only one working on this.

Hi all! On x86_64, segment prefix fs: is in address space 257 and gs: in address space 256. (BTW: are there constants for these magic values?) How can I use this in IR? I want to express this assembler code in IR: mov RAX, 8; mov RAX, GS:[RAX]; ret; I tried the following: define i64 @getStackBottom(i64 %addr) { entry: %ptr = inttoptr

Hi David, Thank for very much for your reply! I got a reply on the clang mailing list in April from Dmitri: http://lists.llvm.org/pipermail/cfe-dev/2020-April/065115.html and following his advice “attaching pragmas as attributes to functions” I managed to do it, it was actually quite easy. >>Compatibility with an existing compiler is usually compelling - are the compilers you're