similar to: [LLVMdev] Removing Warning Message

I may sound stupid but can someone tell me that after applying optimization sequences randomly whether we can surely say that the final output is correct? I mean if we apply 12 options in random sequence provided by 'opt' command is the output is always correct (i.e. program does the same thing and results are same as expected) ? Is it Yes by implemention of LLVM or we have to check

On Wed, Jul 19, 2006 at 03:09:44AM +0800, deveshti at comp.nus.edu.sg wrote: > I may sound stupid but can someone tell me that after applying > optimization sequences randomly whether we can surely say that the > final output is correct? Answering this question is equivalent to solving the Halting Problem. > I mean if we apply 12 options in random sequence provided by 'opt'

On Sun, 2004-12-19 at 20:20, Adam Warner wrote: > Hi all, Hi Adam, > > I learned of LLVM a couple of days ago: > <http://groups.google.co.nz/groups?selm=pan.2004.12.18.11.29.33.33249%40consulting.net.nz> > <http://groups.google.co.nz/groups?th=608e6e38e496f09d> > (I posted a tail call followup which is missing from the archive) > Jestingly, LLVM developers

On 10 March 2010 16:57, 琬菁楊 <ching1119.cs96 at g2.nctu.edu.tw> wrote: > I think the main issue is that EFI C dialect is not ANSI-C compliant: the > size of pointer is determined at the run-time and therefore the layout of > the structure is not static. Does LLVM support this model? Hi Ching, The LLVM IR doesn't care about the size of your pointers, and this is why you have the

Hello all, I am highly interestd in implementing C compiler for EFI Byte Code in LLVM and participate in Google Summer Code. EFI is a much larger, more complex,OS-like replacement for the older BIOS firmware interface present in all IBM PC-compatible personal computers. and the EFI specification provides for a processor-independent device driver environment(like virtualmachine), called EFI Byte

Hi, Chris Lattner wrote: > All the non-vastart calls can be anywhere. va_end in particular codegens > to a noop on all targets llvm currently supports, fwiw. > Things go well, except for the following (pathological?) C program: int va_double_sum(int count,...){ int i,sum=0; va_list ap; va_start(ap,count); for(i=0;i<count;i++){ sum+=va_arg(ap,int); } va_end(ap);

Hi all, I learned of LLVM a couple of days ago: <http://groups.google.co.nz/groups?selm=pan.2004.12.18.11.29.33.33249%40consulting.net.nz> <http://groups.google.co.nz/groups?th=608e6e38e496f09d> (I posted a tail call followup which is missing from the archive) Jestingly, LLVM developers appear intent upon nothing short of world domination. Not only have you done an end run around

On Thursday 10 February 2005 21:47, Markus F.X.J. Oberhumer wrote: > In order to get more familiar with the llvm sources I've recently > decided to try to add support for the always_inline and noline function > attributes. I believe it is better to let the compiler decide when or not to inline a function. Most of the times a developer goes overboard with inlining and ends up with a

Robert Mykland wrote: > Dear Chris and Reid: Hi Robert. > > Some other random ideas I've had as I've been sifting through the new > bytecode format. Please let me know what you think. > > 1) ANSI C allows for char to default to unsigned char. This is I guess > not how it normally is in GCC. If char defaulted to unsigned char > several things would be

Dear Chris and Reid: Some other random ideas I've had as I've been sifting through the new bytecode format. Please let me know what you think. 1) ANSI C allows for char to default to unsigned char. This is I guess not how it normally is in GCC. If char defaulted to unsigned char several things would be possible. Single char constants that are defined would be almost always stored

I'm trying to build the 1.4.0 development version of R for Windows. I'll be posting problems as they arise, until I give up (or succeed), or someone asks me to stop. 1. I don't have zlib, the compression library. The source file gnuwin32/unzip/WHERE says to get it from ftp://ftp.info-zip.org/pub/infozip/zlib/zlib.html; that web site says it has been closed and redirects me to

From: Randy Dunlap <randy.dunlap at oracle.com> Fix sparse warning for non-ANSI function declaration: arch/x86/xen/irq.c:129:30: warning: non-ANSI function declaration of function 'xen_init_irq_ops' Signed-off-by: Randy Dunlap <randy.dunlap at oracle.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge at citrix.com> --- arch/x86/xen/irq.c | 2 +- 1 file changed, 1

From: Randy Dunlap <randy.dunlap at oracle.com> Fix sparse warning for non-ANSI function declaration: arch/x86/xen/irq.c:129:30: warning: non-ANSI function declaration of function 'xen_init_irq_ops' Signed-off-by: Randy Dunlap <randy.dunlap at oracle.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge at citrix.com> --- arch/x86/xen/irq.c | 2 +- 1 file changed, 1

From: Randy Dunlap <randy.dunlap at oracle.com> Fix sparse warning for non-ANSI function declaration: arch/x86/xen/irq.c:129:30: warning: non-ANSI function declaration of function 'xen_init_irq_ops' Signed-off-by: Randy Dunlap <randy.dunlap at oracle.com> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge at citrix.com> --- arch/x86/xen/irq.c | 2 +- 1 file changed, 1

On Tue, 2007-05-08 at 22:45 -0700, Bill Wendling wrote: > On May 8, 2007, at 10:05 PM, Mohd-Hanafiah Abdullah wrote: > > > On Tue, 2007-05-08 at 11:58 -0700, Bill wrote: > >> On 5/8/07, Mohd-Hanafiah Abdullah <napi at axiomsol.com> wrote: > >>> How does the C back-end of LLVM differ from the one in gcc2c > >>> developed > >>> by SUN

On May 8, 2007, at 10:05 PM, Mohd-Hanafiah Abdullah wrote: > On Tue, 2007-05-08 at 11:58 -0700, Bill wrote: >> On 5/8/07, Mohd-Hanafiah Abdullah <napi at axiomsol.com> wrote: >>> How does the C back-end of LLVM differ from the one in gcc2c >>> developed >>> by SUN several years ago? >>> >> Hi Napi, >> >> For one, it converts

On Tue, 2007-05-08 at 11:58 -0700, Bill wrote: > On 5/8/07, Mohd-Hanafiah Abdullah <napi at axiomsol.com> wrote: > > How does the C back-end of LLVM differ from the one in gcc2c developed > > by SUN several years ago? > > > Hi Napi, > > For one, it converts LLVM's bytecode to C instead of GCC's RTL. It's > also under a different license. Hi

On Sat, 2006-11-04 at 21:06 -0800, Reid Spencer wrote: > Hi Napi, > > On Sun, 2006-11-05 at 12:40 +0800, Mohd-Hanafiah Abdullah wrote: > > Hi: > > > > I'm interested in using llvm to convert C++ code to C code. > > I used the following command to do this: > > > > % llvm-g++ -c foo.cpp -o - | llc -march=c -o foo.cbe.c > > Yup, that'll

Mohd-Hanafiah Abdullah wrote: >After converting a piece of C++ code to C one of the functions that are >generated is this: >_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc > > This is a method/function from the standard C++ library. You can link it in at the bytecode level with: llvm-g++ -o output.bc <yourfile.bc> -lstdc++ You might also be able to do: llvm-g++

Hi, I want to use R_qsort_int_I() in my C function, but getting the following error. It looks like there is a conflict between Rmath.h, which I use to generate random numbers, and R_ext/Boolean.h I would appreciate any help to fix this problem. gcc -ansi -g -o Gibbs gibbs.c subroutines.o rand.o vector.o -lm -lRmath -llapack -lblas -lfrtbegin -lg2c -lm -shared-libgcc In file included from