similar to: [LLVMdev] [cfe-dev] x86_64-pc-win32 ABI var arg code gen bug? Is the bitcode correct? Or is it the code gen?

Here's a new version of a patch that fixes a problem with MSVC2105 update2, but it doesn't disable any optimization, so the resulting encoding performance should be almost unaffected by this workaround. MSVC compiles abs_residual_partition_sums[partition] = (FLAC__uint32)_mm_cvtsi128_si32(mm_sum); into this: movq QWORD PTR [rsi], xmm2 while it should be movd

Objects compiled for the MS-ABI don't conform to it! Data types beyond 64 bit MUST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t

Erik de Castro Lopo wrote: > Ok, I'll take the original patch as it is. DO you have a link to a > bug report on this problem? It would be nice to put it in a comment > above the workaround. :sigh: I hoped that somebody else will find what's wrong and will create a bugreport... Well, here is the link:

Hi all, I believe I've found a bug in the encoding of the movd instruction on x64. Here's some IR code to reproduce it: external global i8*, align 1 ; <i8**>:0 [#uses=1] external global i8*, align 16 ; <i8**>:1 [#uses=1] declare void @abort() define internal void @2() { %1 = load i8** @0, align 1 ; <i8*> [#uses=1] %2 =

On Mon, May 23, 2016 at 2:44 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > Hi, > > I found a mismatch between assembler & disassembler of X86: I assembled an > instruction, then disassembled the output, but the result is not the same > as the first original code: "add qword ptr [205163983024656], 1" vs " add > qword ptr [1985229328], 1" > >

Hi all, Some background: I'm working on a project to replace a custom VM with various components of llvm. We have everything running just peachy keen with one recent exception, one of our executables crashes when attempting run a JIT'd function. We have llvm building and running on 64 bit Windows and Linux, using Visual Studio 2008 on Windows and gcc on Linux, and we have the llvm

Reported https://bugs.llvm.org/show_bug.cgi?id=38911 Thanks, Leslie Zhai 在 2018年09月11日 16:55, Dimitry Andric 写道: > Hi Leslie, > > The problem really lies in the OpenJDK code, as it is attempting to > write to a const object. If this seems to work with certain compiler(s) > and optimization settings, it is just luck. :-) > > Here is a reduced example, which shows the

Hi, I found a mismatch between assembler & disassembler of X86: I assembled an instruction, then disassembled the output, but the result is not the same as the first original code: "add qword ptr [205163983024656], 1" vs " add qword ptr [1985229328], 1" Anybody knows what is wrong? Thanks. $ echo "ADD QWORD PTR [0xba9876543210], 0x1"|llvm-mc -assemble

> > > >>>>> On 10/16/2016 11:16 PM, Pierre Jaury wrote: > > > >>>>>> Hello, > > > >>>>>> > > > >>>>>> I am using a dict proxy for my sieve extdata plugin to access some > > > >>>>>> fields from an SQLite database (autoreply text and other > > >

Hello, I am using a dict proxy for my sieve extdata plugin to access some fields from an SQLite database (autoreply text and other database-configured items). All tests are performed against version 2.2.25. $ dovecot --version 2.2.25 (7be1766) My configuration looks like: dict { sieve = sqlite:/etc/dovecot/pigeonhole-sieve.dict } [...] sieve_extdata_dict_uri = proxy::sieve I

While trying to isolate properly and reproduce, I was able to trigger the same bug with the following code: struct dict *dict; char* dict_uri = "proxy::sieve"; char* key = "priv/key"; char* username = "admin at domain.tld"; char* value, error; dict_drivers_register_builtin(); dict_init(dict_uri, DICT_DATA_TYPE_STRING, username,

Hi! This does sound like a bug, we'll have look. Aki On 17.10.2016 01:26, Pierre Jaury wrote: > I dived a little bit further into the rabbit hole, up to the point where > debugging has become unpracticle but I still haven't found the root > cause for sure. > > I read most of the code for "p_strdup" based on datastack memory pools > (which are used for

Hi everyone! I've faced a strange problem after updating to Windows 8 Consumer Preview recently. It seems that LLVM inserts 4 calls to the same function at the start of generated code. The function's disassembly (taken from nearby computer with Windows 7) is: 00000000773A0DD0 sub rsp,10h 00000000773A0DD4 mov qword ptr [rsp],r10 00000000773A0DD8 mov qword ptr

Compiling a simple automaton created by GNU bison with -O1 or -O2 resulted in the following machine code: 1300 /*-----------------------------. 1301 | yyreduce -- Do a reduction. | 1302 `-----------------------------*/ 1303 yyreduce: 1304 /* yyn is the number of a rule to reduce with. */ 1305 yylen = yyr2[yyn]; 0x0000000000400c14 <rpcalc_parse+628>: mov

On Sat, Mar 19, 2011 at 1:44 AM, Csaba Raduly <rcsaba at gmail.com> wrote: > Compiling a simple automaton created by GNU bison with -O1 or -O2 > resulted in the following machine code: > > 1300    /*-----------------------------. > 1301    | yyreduce -- Do a reduction.  | > 1302    `-----------------------------*/ > 1303    yyreduce: > 1304      /* yyn is the number

Oh duh, it used datastack pool. Try again with the attached patch? Please remember to clear the previous one out before trying. Aki > > The trace is missing some symbols, I will debug tomorrow and see where > the call comes from exactly. > > Regards, > > > On 10/17/2016 06:23 PM, Aki Tuomi wrote: > > Hi! > > > > Looking at the code, I think the bug

Hi, I have a concern about the portability of offloading the new VIRTIO packed ring format to hardware. According to the PCIe rev 2.0, paragraph 2.4.2. Update Ordering and Granularity Observed by a Read Transaction" " if a host CPU writes a QWORD to host memory, a Requester reading that QWORD from host memory may observe a portion of the QWORD updated and another portion of it

On Oct 26, 2011, at 1:18 PM, Nicolas Capens wrote: > On 24/10/2011 9:50 PM, Bill Wendling wrote: >> On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: >> >>> Hi all, >>> >>> I'm working on a graphics project which uses LLVM for dynamic code >>> generation, and I noticed a major performance regression when upgrading >>> from LLVM

Hi! I have discovered a problem with LLVM's interpretation of the Win64 calling convention w.r.t. passing of aggregates as arguments. The following code is part of my host application that is compiled with Visual Studio 2005 in 64-bit debug mode. noise4 expects a structure of four floats as its first and only argument, which is - in accordance with the specs of the Win64 calling convention -

Update: I have been working on this all day, and I finally got it working more or less with the pattern instruction selector... However, the generated code is not very good, and I haven't implemented the expand to calls if the target does not support these FP instructions. As an example, in the following function the sub abs and compare compiles to 13 instructions! Also it has changed the