similar to: [LLVMdev] Fwd: help with llvm-convert

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: ../../src/gcc/llvm-convert.cpp:3871: failed assertion `(TREE_CONSTANT(exp) || TREE_CODE(exp) == STRING_CST) && "Isn't a

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

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

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'

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

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 =