similar to: [LLVMdev] gfortran: array constructor problems

On Tue, 5 Sep 2006, Michael McCracken wrote: > Hi, in order to get a handle on the questions in Chris's previous > email, I rebuilt LLVM with debugging info, and then rebuilt gcc4 with > CHECKING_ENABLED. > > In the process, I ran into an assertion error when compiling the first > part of libgfortran: ok. > ../../src/gcc/llvm-convert.cpp:3871: failed assertion >

On 9/6/06, Chris Lattner <sabre at nondot.org> wrote: > On Tue, 5 Sep 2006, Michael McCracken wrote: [snip] > > ../../src/gcc/llvm-convert.cpp:3871: failed assertion > > `(TREE_CONSTANT(exp) || TREE_CODE(exp) == STRING_CST) && "Isn't a > > constant!"' > > > > In this case, TreeConstantToLLVM::Convert() is getting a constant to >

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

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  

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

Anton, With regard to the gfortran test cases which don't fail on x86_64 Linux, these are the exact gfortran.log entries for them under i686 Darwin9... > FAIL: gfortran.dg/array_constructor_12.f90 -O0 (internal compiler error) > FAIL: gfortran.dg/array_constructor_12.f90 -O0 (test for excess errors) Executing on host:

On Sat, Apr 09, 2011 at 08:56:49AM -0600, Marcus G. Daniels wrote: > On 4/9/2011 6:09 AM, Duncan Sands wrote: > > Hi Jack, thanks for the numbers. Any chance of analysing why gcc does better on > > those where it does much better than dragonegg? > > > > Ciao, Duncan. > Also, does -fplugin-arg-dragonegg-enable-gcc-optzns get Dragonegg to > match GCC performance

Hello, Duncan. > 3-fortran.diff > Get fortran to compile: use the common stubs and rip out > the incomplete collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const

On Monday 05 January 2009 12:42:16 Bill Wendling wrote: > I did mark it as TREE_CONSTANT. Is that enough? No idea - if it works I guess it was enough :) I was actually thinking of TREE_STATIC: /* In a VAR_DECL, nonzero means allocate static storage. In a FUNCTION_DECL, nonzero if function has been defined. In a CONSTRUCTOR, nonzero means allocate static storage. ??? This is also

Hi Chris, > I think this change is fine and should go into the normal apple GCC as > well. Setting TREE_READONLY means that it can go into the "constant" > section of the executable, go in ROM, etc. This is the same as the > llvm constant bit on globals. for this I think it has to be static as well as readonly. Ciao, Duncan.

llvm itself compiles fine. gcc frontend has the error, see below. I applied the attached patch, since the name of architecture on FreeBSD is sparc64, not sparc. There is also one more replacement sparc -> spaarc64 was made in gcc/Makefile in llvm-gcc. FreeBSD -8.0-STABLE gcc-4.5.0 sunblade 100 Yuri gmake[2]: Leaving directory `/tmp/llvm-build/2.7/llvm-gcc-4.2-objects/libdecnumber'

Hello > I applied the attached patch, since the name of architecture on FreeBSD is > sparc64, not sparc. There is also one more replacement sparc -> spaarc64 was > made in gcc/Makefile in llvm-gcc. The patch is incorrect and the problems you're seeing are caused by your patch, since sparc != sparc64. In LLVM sense "sparc" means "sparc with ILP32 architecture

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

I did mark it as TREE_CONSTANT. Is that enough? -bw On Jan 5, 2009, at 2:03 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Chris, > >> I think this change is fine and should go into the normal apple GCC >> as >> well. Setting TREE_READONLY means that it can go into the "constant" >> section of the executable, go in ROM, etc. This is the same

Vladimir Prus wrote: > So, it looks either the snapshot is not in stable state, or there's > something seriously wrong with type name handling. At this point I gave up > on quickly fixing this, so I've applied the third attached patch to LLVM, > which "fixes" this issue completely. Ah, hell, as soon as I've send this email I've updated from CVS to find that

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

Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const

Please review this patch for PR3510 (and <rdar://problem/6564697>). The bug is a failure to handle a "hole" inside an initialized structure, where the hole may be induced by a designated initializer or by alignment: http://llvm.org/bugs/show_bug.cgi?id=3510 The original code was greatly simplified by using FieldNo to index the LLVM fields and the initializer in

Hi, I have a first quick patch and a question. The patch links f951 with g++ when LLVM is enabled. It's at the end of this email. I wanted to know if I should submit patches with comments around them like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to the tree. I'd like to make it as easy as possible to apply these, so let me know any rules I should be following.