search for: gimplifier

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 being overridden in assemble_variable(): > > /* On some machines, it is good to increase alignment sometimes. */ > if (! DECL_USER_ALIGN (decl)) > { > #ifdef DATA_ALIGNMENT > align = DATA_ALIGNMENT (TREE_TYPE (de...

...an 8-byte alignment. However, the Bar variable has 1-byte alignment, because it's being placed into the "redzone". The generic code for the function is: $ 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 being overridden in assemble_variable(): /* On some machines, it is good to increase alignment sometimes. */ if (! DECL_USER_ALIGN (decl)) { #ifdef DATA_ALIGNMENT align = DATA_ALIGNMENT (TREE_TYPE (decl), align); #endif #ifdef CONSTAN...

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->temps; t ; t = TREE_CHAIN (t)) - DECL_GIMPLE_FORMAL_TEMP_P (t) = 0; + if

...ation level is 2, until a better solution is found. 13-optabs.diff Remove all uses of optabs by Ada. These seem to be left-over from older gcc versions: while optabs are initialized, they are not actually used. 14-decl_rtl.diff Use the LLVM version of make_decl_rtl when compiling for LLVM. 15-gimplifier.diff Backport some gimplifier fixes from 4.3. These almost certainly will have no effect on languages other than Ada. With these patches, the Ada build dies at this point: Unhandled expression! <floor_mod_expr 0x40310c08... The Ada bootstrap dies at this point: <view_convert_expr 0x403c...

...t; > 13-optabs.diff > Remove all uses of optabs by Ada. These seem to be left-over from > older gcc versions: while optabs are initialized, they are not > actually > used. > > 14-decl_rtl.diff > Use the LLVM version of make_decl_rtl when compiling for LLVM. > > 15-gimplifier.diff > Backport some gimplifier fixes from 4.3. These almost certainly > will have no effect on languages other than Ada. > > With these patches, the Ada build dies at this point: > Unhandled expression! > <floor_mod_expr 0x40310c08... > > The Ada bootstrap dies at thi...

...inline, 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. Where did you integrate LLVM into GCC? Did you change the gimplifier to produce LLVM code or make LLVM a GCC backend? > > If it's any consolation, it seems fairly likely that there will be a new > llvm-gcc in development in the next couple of months, based on GCC > mainline. > > -Chris Nice to hear that. -------------- next part ------------...

>> Dear All, I have been trying for days but still cannot break this barrier. May I get your help? I have compiled llvm-2.1 successfully and make install. When I proceed with llvm-gcc-4.2-2.1, however, I keep getting linking error as attached. Some functions with totally different content conflict with each other in linking process. That is a Linux box (Debian, with 2.6.23-1

Andrew Lenharth wrote: > Interestingly, in the .i file there are 2 __builtin_alloca, and > EmitBuiltinAlloca is only being called once. > > Hmm, here EmitBuiltinAlloca gets called twice, but it looks like validate_arglist is rejecting the args both times. I have 2 calls to alloca generated: $ grep alloca x.bc|grep call %tmp21 = call i8* @alloca( i64 %tmp20 ) nounwind

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

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the

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().

...byte alignment, because it's being placed into the "redzone". The > generic code for the function is: > > $ 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 being overridden in assemble_variable(): > > /* On some machines, it is good to increase alignment sometimes. */ > if (! DECL_USER_ALIGN (decl)) > { > #ifdef DATA_ALIGNMENT > align = DATA_ALIGNMENT (TREE_TYPE (decl),...

Thanks for the suggestion, Andre. I downloaded GNAT GPL 2007, and followed the directions on your web page. Now I get a lot of C++ errors. In fact, the output I captured to a log file is over six megabytes just from the start of the problem command to the termination of the make. I'm obviously not going to include it all here, but the command and the first few errors are copied below.

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 >>>

...le 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 being overridden in assemble_variable(): >> >> /* On some machines, it is good to increase alignment >> sometimes. */ >> if (! DECL_USER_ALIGN (decl)) >> { >> #ifdef DATA_ALIGNMENT >>...

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