similar to: Dynamic array debugging

With a struct that is {T* ptr; size_t length} e.g. https://github.com/ldc-developers/ldc/blob/master/gen/dibuilder.cpp#L531 (only difference is that our dynamic arrays are length then pointer) On 22 Feb 2018, at 12:46 pm, Peter McKinna via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi, Does anyone have any hints as to how one might generate

Hi Tim, Thanks for the hint. I tried the following, (it's a C interface since that's what I need it for) where a and b are the top and bottom halves of the 128 bit value, LLVMValueRef TestConst(LLVMContextRef C, uint64_t a, uint64_t b) { Type *ty = Type::getFP128Ty(*unwrap(C)); ArrayRef<uint64_t> ar[2] = {a,b}; APInt ai(128,*ar); APFloat quad(APFloat::IEEEquad(), ai);

Hi, One of my test cases is throwing a segv on x86_64 linux using llvm 3.7. I cant see what is wrong unless its an alignment problem causing stack corruption. Its a simple naive absolute value calculation inside a loop which crashes after about 500000 iterations. Here is the IR. ; Function Attrs: nounwind uwtable define void @Main__TestProb() #0 { entry: %i = alloca i64, align 8 %j =

Hi all, As part of my compute work I'm trying to get some TGSI compute code to work. The code from mesa/src/gallium/tests/trivial.c works. So now I'm trying to get a "native" tgsi kernel to run via clover, I'm using Francisco's nbody.c example for this: https://fedorapeople.org/~jwrdegoede/nbody.c Which does not work, at first I thought there was an issue with the

Hi, Just wondering if it's possible to construct a 128 bit quad precision floating point constant without converting the value back to a string. Cheers Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/a527f240/attachment.html>

I'm not someone who thinks VLAs are automatically bad and unlike Linux kernel code they can sometimes be used safely in userspace. However for an internet exposed server there is an argument that they might cause some kind of exploitable situation especially if the code is compiled without other stack hardening features. Also in highly multithreaded code with limited stack sizes (as nbdkit

Also, where's the exit op? Perhaps what's happening is that you don't have an exit and it just goes off executing into the ether? On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > A few things that stand out: > > 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) > > wtf is that 0x0000000000000 thing doing there? Was it a %rX which got

Hi! I like to submit some updates to the LLVM website regarding the LDC compiler. All links are currently out-of-date. The following pages need updates: On page http://www.llvm.org/Users.html, please replace the existing entry "LLVM D Compiler" in section "Open Source Projects" with: <tr> <td><a href="http://wiki.dlang.org/LDC/">

Can you send a patch? On 2 December 2013 06:44, Kai Nacke <kai at redstar.de> wrote: > Hi! > > I like to submit some updates to the LLVM website regarding the LDC > compiler. All links are currently out-of-date. The following pages need > updates: > > On page http://www.llvm.org/Users.html, please replace the existing entry > "LLVM D Compiler" in section

Duncan Sands wrote: >> As noted in the GEP FAQ, GEPs don't support variable-length arrays; > > that's not quite right. The problem is only with arrays of variable length > arrays, and more generally with arrays where the element type has variable > size (this occurs with Ada, which has all kinds of funky variable sized types, > for example). You're right, though

I believe that your problem is this: /*01a0*/ LD R8, [R8]; /* 0x8000000000821c85 */ That needs to be LD.E (and your ST's need to be ST.E). You're using a 32-bit gmem address, but you need to be using a 64-bit one. I believe the 32-bit ones work on fermi, but afaik not on Kepler. Cheers, -ilia On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede

Hi Rafael, is there a repository with the static pages or should I simply produce a diff between the 2 versions? Regards, Kai On 03.12.2013 14:30, Rafael Espíndola wrote: > Can you send a patch? > > On 2 December 2013 06:44, Kai Nacke <kai at redstar.de> wrote: >> Hi! >> >> I like to submit some updates to the LLVM website regarding the LDC >> compiler.

Hi, for a few months already I have been asking around for opinions on how people could best work together on Khronos' SPIR-V <-> LLVM-IR converter and some consensus seems to have formed. Most of the people I talked to favored having the converter become an external tool within the LLVM project, similar to libclc. I think that the LLVM project's processes, infrastructure and

Hi Preston, >>> As noted in the GEP FAQ, GEPs don't support variable-length arrays; >> >> that's not quite right. The problem is only with arrays of variable length >> arrays, and more generally with arrays where the element type has variable >> size (this occurs with Ada, which has all kinds of funky variable sized types, >> for example). > >

Hello everyone, I just thought I would let people here know that ldc (llvm backend for the D Programming Language) is getting pretty usable (a few larger libraries compile) and it now has x86-64 support added. I decided to run some timings on some D and C++ code to compare ldc to dmd (the mainline compiler), gdc (the gcc based D compiler) and g++. I used a ray tracing program found in this

Hello, While trying to find out why the LDC compiler refuses to generate object code for MSP430 targets (but generates MSP430 assembly or LLVM IR/bitcode), I came across the following apparent inconsistency. This works: $ clang --target=msp430 -c test.c This doesn't work: $ clang --target=msp430 -S -emit-llvm test.c $ llc -filetype=obj test.ll /opt/msp430/bin/llc: target does not support

On Oct 27, 2008, at 11:03 PM, Kelly W wrote: > Hello everyone, > > I just thought I would let people here know that ldc (llvm backend > for the D Programming Language) is getting pretty usable (a few > larger libraries compile) and it now has x86-64 support added. I > decided to run some timings on some D and C++ code to compare ldc to > dmd (the mainline compiler),

At the moment llvm-config outputs "2.6svn" if llvm is build from trunk $ llvm-config --version 2.6svn Some external projects (built out-of-tree) need to know which revision of llvm is installed. LDC currently asks llvm-config --src-root for the source directory and then parses svn info's output to get the revision number. This requires the user to keep the llvm source tree

On Thu, Jul 6, 2017 at 2:19 AM, Tim Northover <t.p.northover at gmail.com> wrote: > On 5 July 2017 at 17:51, Luís Marques via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Cool. When I did that on macOS, LDC generated a lot of complaints, > possibly > > because it is assuming mach-o files. I tried changing from > -mtriple=msp430 > > to

Benjamin Kramer wrote: > At the moment llvm-config outputs "2.6svn" if llvm is build from trunk > > $ llvm-config --version > 2.6svn > > Some external projects (built out-of-tree) need to know which revision > of llvm is installed. LDC currently asks llvm-config --src-root for the > source directory and then parses svn info's output to get the revision