similar to: [LLVMdev] LLVM BUG for x86 code generation ?

Hi Sebastian, > when I compiled attached .ll file with llc 2.8 as follows: > > llc -O0 -march=x86 llvmfails.ll -o llvmfails.s > gcc -m32 llvmfails.s -o llvmfails > ./llvmfails > > the executable exits with the expected message: "SUCCESS", whereas if I use -O1 instead of -O0 for LLC, it prints out FAILS. > > llc -O0 -march=x86 llvmfails.ll -o llvmfails.s >

Hi Duncan, I've patched LLVM 2.8 source tree, and it doesn't fix the problem on my side. Did you checked that your patch fixes the problem ? Best Regards Seb -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands Sent: Thursday, November 18, 2010 12:48 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LLVM BUG

Hi Sebastien, > I've patched LLVM 2.8 source tree, and it doesn't fix the problem on my side. Are you sure you tested using the newly built llc? > Did you checked that your patch fixes the problem ? I did: Before: $ llc -O1 -march=x86 llvmfails.ll -o llvmfails.s $ gcc -m32 llvmfails.s -o llvmfails && ./llvmfails FAILS After: $ ~/LLVM/llvm-objects/Debug+Asserts/bin/llc

Hi Duncan, I think, I found my problem, I've patch 2.8 source tree, I guess I need to patch dev source tree right ? Anyway, thanks for the time you spend on this problem. Best Regards Seb -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thursday, November 18, 2010 2:18 PM To: Sebastien DELDON-GNB Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LLVM BUG

>> Can someone else try to reproduce this? I tried gcc.c from http://people.csail.mit.edu/smcc/projects/single-file-programs/ and the difference is a bit more noticeable: -O0 -mno-relax-all real 0m13.182s user 0m12.690s sys 0m0.450s -O0 gcc.o is 10932968 bytes. real 0m12.969s user 0m12.520s sys 0m0.410s gcc.o is 11410552 bytes IMHO it would still be reasonable to switch to

On Feb 25, 2011, at 11:38 AM, Rafael Avila de Espindola wrote: >>> Can someone else try to reproduce this? > > I tried gcc.c from > http://people.csail.mit.edu/smcc/projects/single-file-programs/ and the > difference is a bit more noticeable: > > -O0 -mno-relax-all > > real 0m13.182s > user 0m12.690s > sys 0m0.450s > > -O0 > > gcc.o is

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Was just working with the latest 3.54, and find that the Makefile in the menu directory didn't work until I added the /include/syslinux to the file. < CFLAGS = $(M32) -mregparm=3 -DREGPARM=3 -W -Wall - march=i386 -Os -fomit-frame-pointer -I$(LUDIR)/include - I$(COM32DIR)/include -I$(COM32DIR)/include/syslinux -Ilibmenu - D__COM32__ -

Hi. I've decided to do a regression test in order to find out what's wrong with Dreamfall (see AppDB), and that involves comparing releases 0.9.61 and 1.1.12 (reports have been "garbage" ever since 1.0.0, but with errors different from mine). However, when building for the first time, this error occurs: Code: ccache gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__

Trying to install rails/fcgi/apache2. Following these instructions: http://xmlareas.com/ruby-rails-howto.html Using Fedora Core 4. I installed ruby and ruby-devel using apt-get. Everything under Adding FastCGI (optional) works fine up to the gem install fcgi part. Here is what happens: [root@paulbarry fcgi-2.4.0]# gem install fcgi -r -- -with-fcgi-lib=/usr/local/fcgi/lib

I thought of another work around. The FSF gcc driver can implicitly add -no_compact_unwind to the link line. This tells the linker to not produce compact unwind information from the dwarf unwind info in .o files. Then at runtime the darwin unwinder will fallback and use the slow dwarf unwind info. -Nick On Sep 18, 2009, at 2:27 PM, Nick Kledzik wrote: > I dug into this. Based on

I wish to assure you that I have not forgotten this task, nor failed to start on it, but I cannot give even a rough estimate on when it will be completed. It occurs to me that all declarations of a function pointer, and all bitcasts to a function pointer, could possibly refer to a function whose signature must be altered by this fix. Is the function signature relevant to the SelectionDAG

Hello, I'm making a compiler utilizing LLVM. Because I want the compiler to support 128bit floating-point operations, I added the code for 128bit floating-point operations and tested these operations in i686, x86_64, SPARCv8 and SPARCv9 machines. Generated codes by LLVM operated normally when using x86_64, SPARCv8 and SPARCv9 machines, but generated codes in a x86 machine produce wrong

I got the following compiler error with Wine 1.2-GIT (up-to-date checkout): Code: make[1]: Entering directory `/home/quix0r/git/wine/dlls/user32' ccache gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g

On Sep 20, 2009, at 11:36 AM, Kenneth Uildriks wrote: > I wish to assure you that I have not forgotten this task, nor failed > to start on it, but I cannot give even a rough estimate on when it > will be completed. Ok, that's fine. Thanks for keeping me up to date. > It occurs to me that all declarations of a function pointer, and all > bitcasts to a function pointer, could

> On May 17, 2016, at 1:33 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > Let me ask a LTO simple question again. For the llvm LTO example in the link:http://llvm.org/docs/LinkTimeOptimization.html <http://llvm.org/docs/LinkTimeOptimization.html>, I use below build commands to generate three different optimization level binary: -O0, -O1, -O2.

Hi Umesh, Thank you for the suggestion. I can use the "Brute force method " to narrow down the LTO wrong instructions here and there, but I still don't know why these wrong instructions are generated, and how to let Clang LTO don't generate those wrong instructions. I suspect the wrong code is caused by some LTO wrong optimization pass, so I hope to disable all optimizations in

Hi all, I currently use LLVM 3.0 clang to compile my source code to bitcode (on a X86-64 machine) before it is later processed by a pass, like this: $ clang -m32 -O3 -S foo.c -emit-llvm -o foo.ll However, for some reason the the resulting module contains 128-bit instructions, e.g.: %6 = load i8* %arrayidx.1.i, align 1, !tbaa !0 %7 = zext i8 %6 to i128 %8 = shl nuw nsw i128 %7, 8 which the

Hi Tim, Thanks for your message! It turns out that the infrastructure (an outdated one) that I am working on is using gcc+dragonegg to generate llvm code: gcc -m32 -S -c -O0 -fplugin=$(DRAGONEGG_SO) -fplugin-arg-dragonegg-emit-ir $< -o $@.tmp It directly generates llvm code with fadd, etc. I'm not familiar with dragonegg plugin... Thanks, XIaochu On Wed, Mar 16, 2016 at 12:00 PM,

Hi Martin, Yes, the patch only changes the format of line information. There will be more work needed for fully implementing it across all tools. Here your concern still stands---more focus on debug information for VLIW architectures would be welcome. I was only pointing out that the necessary capacity of the debug information to carry this data does in fact exist, and that at least one step

Hi all, I'm using trunk version of LLVM/CLANG. When I compile attached files on my 64-bit Ubuntu 10.04 LTS system as follows: clang -O2 -g check.c main.c -o check64 When I do gdb check64 and set a breakpoint to the check routine and executes to the breakpoint, I've got: Breakpoint 1, check (result=0x601110, expect=0x601020, n=53) at check.c:7 7 { As you can see I can inspect