search for: gimplify

...GNMENT (DECL_INITIAL (decl), align); > #endif > } Not sure I'm getting it, is this Bar itself or the constructed C.0 that's getting realigned? > By setting the DECL_USER_ALIGN field, we can get the correct > alignment. > > Comments? > > -bw > > Index: gimplify.c > =================================================================== > --- gimplify.c (revision 43658) > +++ gimplify.c (working copy) > @@ -2756,7 +2756,8 @@ > TREE_STATIC (new) = 1; > TREE_READONLY (new) = 1; > DECL_INITIAL...

...); #endif #ifdef CONSTANT_ALIGNMENT => if (DECL_INITIAL (decl) != 0 && DECL_INITIAL (decl) != error_mark_node) align = CONSTANT_ALIGNMENT (DECL_INITIAL (decl), align); #endif } By setting the DECL_USER_ALIGN field, we can get the correct alignment. Comments? -bw Index: gimplify.c =================================================================== --- gimplify.c (revision 43658) +++ gimplify.c (working copy) @@ -2756,7 +2756,8 @@ TREE_STATIC (new) = 1; TREE_READONLY (new) = 1; DECL_INITIAL (new) = ctor; - if (...

Index: gcc/gimplify.c =================================================================== --- gcc/gimplify.c (revision 39923) +++ gcc/gimplify.c (working copy) @@ -179,8 +179,10 @@ /* LLVM LOCAL begin */ #ifndef ENABLE_LLVM /* LLVM wants to know about gimple formal temps. */ - for (t = gimplify_ctxp-...

I'm trying to get the Ada gcc front-end to work with LLVM. This series of patches gets things to the point where the Ada compiler builds, though it fails to build itself or the runtime. While I was there I resurrected fortran and java: as with Ada, the compilers build but not the runtimes. Also, I've replaced the gcc 4.0 Ada front-end with a back-port of the Ada front-end from FSF gcc

Duncan, It would be useful to know what motivated this work -- in particular, is some organization (company, open source project team, research group, any other kind) interested in having an Ada front-end? Thanks, --Vikram ---------------------------------------------------------------------- VIKRAM S. ADVE Associate Professor, Computer Science E-MAIL: vadve at cs.uiuc.edu Siebel

Am Dienstag, 9. August 2005 18:22 schrieb Chris Lattner: > > It's a pretty significant job. You could try to merging in new bits from > GCC mainline, but it's a nasty job: debugging failures requires pretty > strong understanding of how GCC works. Easier would be to patch the > llvm-gcc X86 configuration stuff to accept and ignore that switch. I looked at those files.

...k.o java/except.o java/verify-glue.o java/verify-impl.o java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o java/mangle_name.o java/builtins.o java/ resource.o java/jcf-write.o java/buffer.o java/check-init.o java/jcf- depend.o java/jcf-path.o java/boehm.o java/java-gimplify.o main.o libbackend.a ../libcpp/libcpp.a attribs.o stub-objc.o stub-c.o -L../ zlib -lz ../libcpp/libcpp.a ../libiberty/libiberty.a ../ libdecnumber/libdecnumber.a /home/kchan/llvm-gcc4.2-2.1.source/host-x86_64-unknown-linux-gnu/prev- gcc/xgcc -B/home/kchan/llvm-gcc4.2-2.1.source/host-x86_...

...preprocessing : 0.02 ( 6%) usr 0.01 ( 6%) sys 0.04 ( 8%) wall 285 kB ( 6%) ggc lexical analysis : 0.01 ( 3%) usr 0.10 (59%) sys 0.08 (16%) wall 0 kB ( 0%) ggc parser : 0.06 (19%) usr 0.04 (24%) sys 0.13 (26%) wall 2756 kB (56%) ggc tree gimplify : 0.01 ( 3%) usr 0.00 ( 0%) sys 0.02 ( 4%) wall 424 kB ( 9%) ggc llvm backend functions: 0.03 ( 9%) usr 0.00 ( 0%) sys 0.03 ( 6%) wall 1 kB ( 0%) ggc llvm backend globals : 0.01 ( 3%) usr 0.00 ( 0%) sys 0.01 ( 2%) wall 0 kB ( 0%) ggc llvm backend per fi...

On Mon, 11 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am trying to build llvm-gcc4 on a amd64. I had to add the attached > patch to get the build system to select the correct library. Now the Applied. > build fails while compiling a code that has __builtin_va_copy. The > attached test.i fails with: > > cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* >

Interestingly, in the .i file there are 2 __builtin_alloca, and EmitBuiltinAlloca is only being called once. Andrew On 2/16/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > libcpp/charset.c:631 turns into: > > %tmp16 = tail call i64 @strlen( i8* %to ) nounwind readonly > ; <i64> [#uses=1] > %tmp18 = tail call i64 @strlen( i8* %from ) nounwind

I am trying to build llvm-gcc4 on a amd64. I had to add the attached patch to get the build system to select the correct library. Now the build fails while compiling a code that has __builtin_va_copy. The attached test.i fails with: cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion `(isAggregateType(((exp)->common.type)) == (DestLoc

...ers ./c-decl.o differs ./c-dump.o differs ./cfganal.o differs ./cfgbuild.o differs ./cfgcleanup.o differs ./cfgexpand.o differs ./cfghooks.o differs ./cfglayout.o differs ./cfgloopanal.o differs ./cfgloopmanip.o differs ./cfgloop.o differs ./cfg.o differs ./cfgrtl.o differs ./c-format.o differs ./c-gimplify.o differs ./cgraph.o differs ./cgraphunit.o differs ./c-incpath.o differs ./c-lex.o differs ./c-objc-common.o differs ./collect2.o differs ./combine.o differs ./conflict.o differs ./convert.o differs ./c-opts.o differs ./coverage.o differs ./c-parse.o differs ./c-pch.o differs ./c-pragma.o differs...

Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV().

On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: > Hi all, > > This patch is to fix a problem on PPC64 where an unaligned memcpy is > generated. The testcase is this: > > $ cat testcase.c > void Qux() { > char Bar[11] = {0}; > } > > What happens is that we produce LLVM code like this: > > call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11

...DHAVE_CO\ NFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-de\ cl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \ c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o\ c-pch.o c-parser.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checks\ um.o \ llvm-main.o tree-browser.o libbackend.a ../libcpp/libcpp.a /home/eric/llvm/l\ lvm-objects/Release/lib/libLLVMBitReader.a /home/eric/llvm/llvm-objects/Release/lib/li\ bLLVMipo.a /home/eric/llvm/llvm-objects/Release/lib/libLL...

On alpha, I am seeing a problem with Emiting va_copy.  valists are structs and allocated by alloca, unlike x86.  EmitBuiltinVACopy is therefore using the second branch of the if (~llvm-convert.cpp:6538) to emit the second argument.  The second argument is the result of an alloca.  TreeToLLVM::Emit is hitting the first assertion (~929). The exp being passed is:  <var_decl 0x20000b44240 ap  

On Tue, 9 Aug 2005, Stephan Wienczny wrote: > I found the problem. The gcc sources are older than those on my system. I've > got some CFLAGS that the old gcc does not know, eg. -march=pentium-m. Are > these flags filtered out everything works fine ;-) Ok, great! > What are the differences between the cfrontends.tar.gz and the corresponding > gcc release? It's a pretty big

2010/1/10 Aaron Gray <aaronngray.lists at googlemail.com> > 2010/1/10 Duncan Sands <baldrick at free.fr> > > Hi Aaron, >> >> >> Thanks, okay heres the results :- >>> >>> LLVM type size doesn't match GCC type size! >>> >>> <real_type 0x7ff80b40 long double sizes-gimplified XF size <integer_cst >>>

On Nov 6, 2007, at 6:07 PM, Dale Johannesen wrote: > > On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: >> $ more testcase.c.t03.generic >> Qux () >> { >> static char C.0[11] = {0}; >> char Bar[11]; >> >> Bar = C.0; >> } >> >> Anyway, it turns out that the gimplifier was generating the correct >> alignment, but it was

Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call